Programmers and Developers

It has become fashionable to call oneself a "software developer" instead of a programmer. A "developer" doesn't want to appear "narrow-minded" or an idiot savant. Instead everyone does something of everything. Division of labor is out, full stack vertical integration, baby! The "developers" now do "customer support", ticketing, accounting, UX, UI, planning new releases, maintaining the entire test automation service stack and more! And you'll also be able to polish your CV. Win, Win!

However this means the programming part of development is less and less in focus. Instead attention is put onto structures around the core activity. A good example for this is SCRUM, in which basically everything is ceremony, disguised as good practice. If you dance in the correct manner, rain will come. Do SCRUM and the software will be good.

The entire subject reminds me of trying out different Linux window managers for several days and never actually running any applications on top. At the end of the day the WM doesn't matter. I wonder then why there is so much focus on the bits which could be nice but are strictly speaking non-essential.

Serve it up thick

There is a clear move to more intangible "services". Many people believe this is due to concerns over cash flow, repeated income, making investors happy, dividends, guarding against catastrophic failure, etc. This is not wrong, it's just missing the mark. The origin of this attitude is exactly why there is so much emphasis on things around any core activity: Fear of that very same activity. Fear of Responsibility for the outcome of decisions taken. Keeping things abstract. Going into a committee, deciding together on a consensus. If everyone approved it, then everyone is responsible equally and if everyone is responsible, then no-one is responsible. The more abstract, the better. Don't sell concrete things, those will only land you in court having to defend yourself why the power charger you created shouldn't be used as a sex-toy. Sell consulting - if it doesn't work they probably did it wrong. No Refunds! The Fear of Loss. I have it good, why take the risk? Insurance against minor risk of damages I could easily pay out of my pocket book? Sign me up!

Code is real

Was it good for the general to split his troops? Was it good for him to leave the advantageous position of his hill? What about the stores of food, surely he had to move or he would run out of supplies? The sages had told him not to attack before the next full moon or disaster would strike. The debate about the pros and cons of a strategic decision can rage eternally and thus blame can be, if not totally avoided, softened. Clear blame will only be put onto a leader if the decisions are so catastrophic and obviously wrong that no-one can deny their poor performance.

Did the archer do what was needed to win the fight? His arrow missed the enemy horseman which proceeded to drive a lance through 5 peasants. In total 15 children which will now go unfed, shivering in the cold winter.

A strategic decision is harder to scrutinize than if a nail was properly hammered into a wooden block. There is some punishment even for the higher ups, but even this reprimand is more diffuse - a booing of a poorly performed burlesque show. On the lower (real) levels we have what I call "metricization" of modern "software-development". Metricization stems from a deep seated fear of being found out at your core responsibility, more akin to a safety blanket than any basis for strategic development. It's a lot safer to account 8 hours a day to meetings than to development of critical infrastructure on which the requirements are not completely understood and progress is not immediately evident. It makes sense why accounting 8 hours for strenuous labor in 10 different meetings is preferred to programming sending and receiving of Bluetooth Ethernet packets.

Code is something different. A for-loop not used correctly, an edge-case not properly investigated, 'git blame' finds the guilty party in half a second and the culprit has nowhere to hide. What do you mean, the software is too complex? It doesn't matter, you wrote this code, don't you see these programming guidelines? Tsk Tsk...

Working on real problems works

Can something be done about fear of doing actual work? On a large scale sadly no. The state of software reflects the culture of the society in which it's created. However some headway can be made by any individual programmer responsible for a piece of software. How so? By simply making things better by programming better stuff and leaving no stone unturned. Work until the software becomes better than it was previously. Sometimes this won't work, but failure is to be expected. Talking a lot and abstracting problems to be solved by someone else isn't going to change anything. Programming does something tangible, something that creates value to other people, if it does what those people want and more easily at that.