What is pragmatic programming

Blog

We software developers at joocom devoted the book The Pragmatic Programmer by David Thomas and Andrew Hunt a few weeks ago. It is a book with practical tips and recommendations, far from specific programming languages ​​or design patterns. In this blog post I would like to pick out some aspects of the content and briefly describe them. So that maybe everyone starts to think a little more pragmatically.

The book has a lot to offer in terms of content. So I just want to go into the three things that I remember most.

Repetitions are bad

Okay, reruns of old cult films on television might be nice to watch every now and then. But in software development you don't want repetitions. This is especially true for the source code. You should never write or even copy the same thing twice. But it also applies to other areas such as documentation. If you have already documented something well in one place, you shouldn't do it in another place. Then it is better to have the documentation generated automatically from the source code, for example.

In software development, this procedure is called DRY - Don't Repeat Yourself.

Repetitions can arise when several developers are working on a project and may not know that a functionality already exists elsewhere. Or they arise because a developer you feel compelled to do so or you are too impatient because it seems faster to you.

Automate and optimize

As a pragmatic programmer, you should always strive to make your work as easy as possible. This includes using a good development environment that supports you in the best possible way with your tools, programming. This also includes processes that are frequently automated repeatedly by hand and manual processes to be avoided. This can mean the build process or administrative things.

fix error

There is no reason to make bad software. Software developers should always strive to do their job as well as possible. If you notice major errors or bad code while implementing it, you should fix it. Otherwise, bad code will result in more bad code being added over time. This can go so far that at some point the software can no longer be maintained.

The book mentions the broken window pane theory. This is a phenomenon: if a house has a broken window pane that cannot be repaired, more window panes are broken in a very short time, the house is smeared, rubbish is left behind. This does not happen in an intact house.

Hence, a pragmatic programmer needs to repair bugs.

Conclusion

At joocom, we thought the book was brilliant and we recommend it to be read!