Programming better: 4 lessons from years of training

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

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

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

Why, then, does German universities attach so much importance to function when programming, but not to form or code quality?

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

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

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

Especially career starters usually have no eye for it and have to acquire this knowledge later in further 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 learned from their experience.

1. Programming beautifully must be mandatory, not freestyle

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 evaluation.

From the very beginning, however, it was important to them that the code was evaluated not only for correctness, but also for architecture.

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

What Dietz and Harrer quickly realized: Beautiful programming 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.

These, according to the experience of Dietz and Harrer, were also much more successful in professional life. So it wasn’t enough to recommend code quality as a voluntary read. They had to integrate them into the course as mandatory.

The result: The discussion of the students took place at a much higher level right from the start.

2. No learning effect without discussion

The interactive discussion in the courses was also particularly effective. By means of code review, the students evaluated the work of their fellow students. The first step was to teach concepts. Second, the application followed, and third, the interaction and discussion.

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

Dietz and Harrer said that this intensive exchange is particularly important in order to suggest the quality of code to students: “The discussions are essential not only to give students a feeling for improvements, but also to set expectations with regard to code quality in programming tasks.”

3. Pair programming instead of static code analysis

The two doctoral students experimented with different teaching methods, including static code analysis, i.e., to put it simply, with programs for automatic error analysis of codes.

They quickly realized that the programs led above all to the fact 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 reflection or they were mainly 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, if necessary, to revise them.

For teaching, on the other hand, 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 vision: Creating a learning culture

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

Because, and this is probably an important lesson for programming as a whole, you never stop learning. The toolbox you bring back from your training is valuable, but far from full.

So if you really want to teach programming, you should do so with a view to the future. Students should be aware that they should constantly expand their toolbox in the long term with code workshops, hackathons, mentoring and other training measures.

Because beautiful code is not something you learn once. Rather, it is a process that you work on every day.

Also interesting:

  1. Project Vivian: How Google wanted to prevent unions
  2. WhatsApp alternatives: What can the Signal offline messenger do?
  3. Apple must allow alternative payment methods
  4. When would you rather not become a programmer?
  5. Reading programming language has nothing to do with math or languages