Program better : 4 lessons from years of training

How can you program better? Two experts have developed a new teaching program at the University of Bamberg and are now taking stock – six years later. These are the four most important tips and insights. 

Good code is not only correct, it is also beautiful.

Among other things, beautiful means: It should be easy to test, readable and easy to expand. Nice code is also essential. He does what he says and says what he does – and doesn’t need comments. You could also say that with well-written code, form and function are one.

Why is programming at German universities so important when it comes to function, but not form or code quality?

Too late in professional life? Learn code quality from the start

That is exactly what Linus Dietz from the Technical University of Munich and Simon Harrer, Senior Consultant at the technology consultancy Innoq, claim.

A good ten years ago, the two doctoral students were at the University of Bamberg. You were asked to design two advanced practical programming courses. The idea was clear: You should of course also teach the basics of programming, but with a special focus on code quality.

Because especially young professionals in particular have no eye for it and have to laboriously acquire this knowledge later in advanced training courses. This is exactly where the University of Bamberg wanted to start. Young students should not only learn the basics of code, but also architecture.

After six years of programming training, Dietz and Harrer have now taken stock . These four lessons can be taken from their experience.

1. Beautiful programming is a must, not a free program

Dietz and Harrer are Java experts. Accordingly, her programming training at the University of Bamberg consisted of five to 15 Java classes, each with 2,000 lines of code and subsequent assessment.

It was important to them from the start that the code should not only be evaluated for correctness, but also for the architecture.

The focus was on an interactive code review. At the end of the course, the students completed an oral exam in which they were asked to explain and critically evaluate a code and to evaluate unknown code examples in their own code review.

What Dietz and Harrer quickly realized: Programming beautifully had previously been voluntary additional knowledge. Of course there was a lot of specialist literature in the library and the students were also encouraged to read it. But only the top students took advantage of the offer.

According to Dietz and Harrer, these were also much more successful in professional life. So it was not enough to recommend code quality as a voluntary reading. They had to integrate them into the course as mandatory.

The result: The discussion of the students was on a much higher level right from the start.

2. No learning effect without discussion

The interactive discussion in the courses was also particularly effective. The students assessed the work of their fellow students using a code review. The first step was teaching concepts. The second was the application and the third the interaction and discussion.

This meant that proposed solutions were examined in the plenum and debated until there were no further suggestions for improvement and all possible advantages and disadvantages had been discussed.

This intensive exchange is particularly important in order to suggest the quality of code to students, Dietz and Harrer said: “The discussions are essential not only to give the students a feeling for improvements, but also about expectations regarding code quality in programming tasks to put. “

3. Pair programming instead of static code analysis to program better

The two doctoral students experimented with different teaching methods, including static code analysis, in other words, with programs for automatic code error analysis.

They quickly found out that the programs primarily meant that the students were less concerned with the code and much more with the error messages. Many of these messages were also completely unnecessary and required very strange workarounds.

In the end, there were two results: Students followed the rules very stubbornly and without critical thinking, or they were mostly busy eradicating the error messages. Hardly anyone cared about the code itself.

Unfortunately, this also happens in many companies. Static code analysis can be helpful, but not if it is not questioned. It makes more sense to analyze the rules in a team and revise them if necessary.

For teaching, however, the lecturers had much more success with pair programming and mob programming. One student types the code while the others focus on the next steps. This not only avoids more mistakes, it also discusses more.

The discussion results in better and nicer solutions in the code. The students were also able to present better arguments for their code solutions in the exam.

4. Programming with foresight: creating a learning culture

However, the most important lesson that Linus Dietz and Simon Harrer have drawn from six years of training is that it is important to create a learning culture – one that goes beyond the university.

Because, and that’s probably an important lesson for programming overall, you never stop learning. The toolbox that you bring with you from your training is valuable, but far from full.

So if you really want to teach programming, you should do so with an eye to the future. Students should be clear that they should continuously expand their toolkits themselves in the long term with code workshops, hackathons, mentoring and other training measures.

Because beautiful code is not something that you learn once. It is rather a process that you work on every day.

Shortlink:

Posted by Asif Paracha on July 31, 2020. Filed under Articles, IT, Software. You can follow any responses to this entry through the RSS 2.0. You can skip to the end and leave a response. Pinging is currently not allowed.