Electricmonk

Ferry Boender

Programmer, DevOpper, Open Source enthusiast.

Blog

Two types of programmers

Friday, April 8th, 2005

The way I see it, there are two types of programmers*:

  • The practical programmer, and
  • The academic programmer

The practical programmer
The practical programmer knows his stuff. He is experienced and knows what will and won’t work. He’s been through the same training as every other software engineer and has learned the same things. When a problem rears its head in need of a solution, he takes his knowledge and applies the basics of many principles to solve the problem. All things are taken into account: Ease of use, speed, ease of coding, ease of maintenance, code complexity, etc.

His solutions are elegant. They do what they need to do. No more, no less. They’re transparent; one look and you can understand what is being done. They’re prepared for the future; their transparency makes them easily extendable, but they are not overly-prepared. The practical programmer understands that completely new problems need completely new solutions, lest they lose their transparency.

The practical programmer’s code applies the basics, the ideas, behind academic solutions where needed, but they aren’t overdone.

The academic programmer
The academic programmer’s been through education. He has learned a variety of solutions to a variety of problems, and can apply them. When a problem arises, in need of a solution, he takes the prefabricated solutions, always the same, and applies them to the problem.

His solutions are almost always over-prepared; they take in account all thought-of future modification, except the ones that matter. His solutions are not transparent but laden with academic concepts and solutions to problems that only occur because of those concepts. His solutions sacrifice speed, ease of coding, transparency and ease of maintenance in favor of The One Correct Solution (as it was taught to him). Of those sacrifices, only speed has a chance of being recovered; often requiring many ugly workarounds.

The academic programmer is baffled by problems that have no prefabricated solution. Creating a new solution requires massive amounts of time, for it must be The One Correct Solution to the problem. His programs take long to implement because the unnecessarily large One Correct Solution needs to be adapted to fit the problem. The size and scope of the solution makes it so that changing it is hard; its non-transparency hides the problem it is trying to solve.

The academic programmer believes the prefabricated solutions are always best. No thought goes into the solution. As it was taught, so it is applied.

Examples

  • Linux vs GNU/Herd/GNUMach
    The Hurd/Mach kernel is the epiphany of academic Kernel design. It is unfinished after having been in development for years. Terrible problems have plagued its completion time and time again.
    The Linux kernel is ‘finished’. It runs on sixteen different architectures. It does its thing on embedded appliances, servers, desktop machines and huge clusters. It offers practical solutions to many, many problems. Its following is huge, because it is practical.
  • C vs C++ / Java
    The C programming language has stood its ground for decades. Its initial design was practical, direct and powerful and remains largely unchanged to this day. It required no spin-offs but only minor tweaks because it is complete within itself.
    But it was not The One Correct Solution.
    Then came the academics and they envisioned C++. At first C++ offered practical solutions to ‘problems’. Object Oriented capabilities added more transparency by forcing correct design in C. But the academic’s fire had been lighted. Templates were added; vague concepts put in that no man could understand.. Even worse was the idea of adding Yet Another Layer to the idea of C++, resulting in Java.
    Where C is fast, easy to write and debug (though it has a somewhat high learning curve), C++ and Java are slow, non-transparent and hard to debug.
  • Forking vs multi-threading
    Forking is the process of creating children processes by forking off a copy of the current program where both keep running independently. The same memory is not shared by the different processes but rather copied. Communication is done through pipes. A clean, simple concept that hardly ever goes wrong. Management of the child process is left to the Operating System so that when the parent dies, the child can live on.
    Multi-threading on the other hand is contained within the parent program. Memory is shared between threads causing all kinds of read/write problems between threads, not to mention the horrors of correct locking. When the parent program dies, all threads die with it. It is, however, not the idea of threading that is the problem. I’m sure it can be put to good use, though I can’t think of any. What is the problem though is the use of threading where not needed. Why solve a problem using obfuscating threads when it can be done without?
  • Normalized database designs
    Database normalization is founded on good principles: No redundant data and safe-guarding data integrity. But when overdone causes great problems in databases. Again: speed, transparency and maintainability are sacrificed in the name of The One Correct Solution. Again: When the basics of normalization are applied, all is good. When fully applied as learned by the academic programmer, disasterous.

Conclusion
Academic programmers and solutions have their uses, as long as they stick to academic works. But please keep them out of the ‘real’ world. Their solutions form a good foundation for solving problems, but they shouldn’t be applied as-is in day-to-day programs.

And kids, remember: Just because they taught you to solve problem A with solution 1 in school doesn’t mean you should always solve every problem that looks like problem A with solution 1. Keep in mind that Real World problems have no One Correct Solution but rather a whole range of possible ones. Pick the best things from each and apply them pragmatically. Don’t build a prefab house in a tornado area.

* There are actually more types. There are also the hackers, drag-and-drop-monkeys, maintainers, etc. This way it sounds more dramatic.

The text of all posts on this blog, unless specificly mentioned otherwise, are licensed under this license.