pancake

Many software engineers cannot design good code

At work, I have recently inherited a piece of software that was grown instead of designed. It is so bad you can feel it when you use it.

Its guts are horrifying. Sharing state by implicitly and repeatedly mutating global objects horrifying. Having multiple code paths for the same thing executing different code horrifying.

One would think we have learned something in the last thirty years. Apparently not. This code and its newest feature manages to hold itself somehow, but a single requirement change would be like a hand grenade.


My management is too proud to even listen to this, but it is a fact to be accepted:

Not everyone is a "new features" engineer.

A code that works does not imply it is a good code. Working code is just a prerequisite.

I almost never open a pull request with the first version of code I wrote. For the net new code, it is the third, fourth, fifth version of the same thing. I weight the options, try approaches, and aim for simplicity. Last week I spent ten minutes tweaking a documentation of a single method, because I know it will be read by another three dozen people in the next two decades.

It is not simple to write simple code. You have to reach a certain level of programming proficiency to internalize that. If you do not, you will keep asking yourself what the colleague's fuss was about.


Not everyone has to be new features engineer. There is so many alternatives and specializations: maintenance engineering, performance engineering, security.

I never found joy in performance, and I am not good at it. But I know it, and I keep my hands away.

I wish others would learn that as well.

#bad-code #software-engineering #work