The root cause of writing unnecessary code is the way the work day and compensatory systems of the modern workplace are structured. Employed software and infrastructure engineers are not paid to just drop in the simplest, most appropriate solution, do the minor customizations/reconfigurations that may be needed, and get out. They're paid to be in butt-in-chair for at least 8 hours per day, and the presumption is that they're engineering that whole time. In reality, places often must make up tasks to keep their employees busy, and using the most efficient solution is disincentivized, because you have to say you're doing something for those 8 hours.
I think the fact that we have the white-collar workforce organized after the assembly line pattern is the primary cause of unnecessary, borderline intentional complication, which includes mixing in unstable/untested components. If we could find a way to compensate engineers fairly without monopolizing their time, we'd be much better off, because the need to continually invent additional work for oneself would go away.
The bliss of a stable, low-maintenance project can be had through side projects, which often work fine for years with minimal modifications. It's really rewarding to go back to the same utility that you've written and know that the comparatively little quantity of time you spent on it is still paying dividends years later. There's an awesome sense of pride attached to that.
Yes, that. I always feel managers are pressured to make sure devs are worked 8 hours a day, necessarily or not. As for side projects, it is really hard to keep a flow doing that knowing that at any time you may be given a "real task" or a maintenance issue to work on. Maybe contractors have a different work day since they are paid by the hour to do specific things, but full time always have the issue of nothing to do but not being allowed to go home or work on something to enhance knowledge.
In reality, places often must make up tasks to keep their employees busy, and using the most efficient solution is disincentivized, because you have to say you're doing something for those 8 hours.
This does not match my experience. Slow times are for experimenting with things and catching up on less-urgent tasks.
You've led a charmed life. In my 25 years in this business, I've found that very little induces the same level of panic in management as "experimenting" with something, especially something that you can't put a solid "business case" behind and "estimate" down to the nearest half hour.
Which is only to be expected. Middle management is not about leadership but all about mitigating risk (Seth Godin explains this quite well in 'Tribes').
It's both a shame and moronic that often assembly line paradigms of management are applied to non-assembly line work (i.e. work that isn't the same for each iteration).
What's needed is to reframe work in terms of value instead of time wasted.
What's interesting is that if you look at history, there are different 'assembly line' paradigms of management, one which could be maybe be termed 'classic American' style (which could be argued necessitated the rise of old-school unions, leading to anti-productive standoffs between management and labor), and the 'Toyota style' which ironically was founded/seeded in Japan by Americans which could not get larger American car companies to listen at the time.
The 'Toyota style' could be argued as more responsive to worker initiative and fits better philosophically with software work. (And Agile is influenced by Toyota-way thinking too, though in a mutated form..)
The "Toyota style" has already played a substantial role in the philosophy of influential technology companies like Apple and Pixar. Steve Jobs was a known admirer of W. Edwards Deming, who created it.
I think the fact that we have the white-collar workforce organized after the assembly line pattern is the primary cause of unnecessary, borderline intentional complication, which includes mixing in unstable/untested components. If we could find a way to compensate engineers fairly without monopolizing their time, we'd be much better off, because the need to continually invent additional work for oneself would go away.
The bliss of a stable, low-maintenance project can be had through side projects, which often work fine for years with minimal modifications. It's really rewarding to go back to the same utility that you've written and know that the comparatively little quantity of time you spent on it is still paying dividends years later. There's an awesome sense of pride attached to that.