These are great points and I wanted to add a couple more I've found over the years.
Software development often has an almost infinite number of ways to accomplish the same task.
Maintainability is as much, if not more, about correctly predicting the future uses and requirements of the software as it is about the initial coding practices and design patterns.
Working on older systems that are being used in ways that they were not originally intended is often uncomfortable for a developer. All but the most junior developers tend to have some painful memories of battling legacy software.
These add up to a situation where it is incredibly difficult and vague to determine the correct path. Both because there are so many ways to accomplish the task and because there are so many unknown future contingencies that ultimately determine how maintainable the software will be. Combine that with the painful memories most developers have from nightmare projects and you have yourself a recipe for emotional disagreements all around.
The grand irony is that, very often, once a developer becomes fully aware of this concept, they lose that internal fire and vigilance required to constantly seek out better ways to solve problems and their skills wane.
> The grand irony is that, very often, once a developer becomes fully aware of this concept, they lose that internal fire and vigilance required to constantly seek out better ways to solve problems and their skills wane.
Any hints to guide one back to the path of passionate problem solving?
I do only partially qualify since I only lost-and-regained my passion for (software) problem solving after an early burnout, not because of an expansion of perspective.
What fuels my passion: I try to stick to languages and concepts that are puristic. I loved SmallTalk, which is pure OO (so much more than Java). I love Haskell, which encapsulates a particular style of functional programming quite well. I love LISP, since it represents and embraces metaprogramming quite well. The more a language deviates from these extremes, the less 'thrill' I feel using them.
I always try to solve problem with the purest form a paradigm has to offer.
In the real world, I am able and perfectly happy to choose whatever tool fits the need best and adapt to the team. But I will certainly voice my opinions ("This is a planning task - let's not reinvent the wheel - and waste time and fix unnecessary bugs - and just send the data to Prolog and translate the solution back into our program") tho and what I do in my free time is not bounded my industrial needs.
Every paradigm offers a different perspective on programming and is worth exploring. Thankfully I am not genious enough to run out of this particular motivation in my lifetime.
Accept that pragmatism, and not trying to solve tomorrows problems today, are great assets for any developer / technical lead.
My maxim is "make it as complex as it needs to be, but not one bit more".
There is great satisfaction to be had from productively solving problems rather than endlessly "architecting" in futile search of the "perfect design".
Work on bigger problems that are a lot harder to solve. You cant mitigate for reality, but what you can do is offset its shittyness but taking on a project/task that yields results that are big and great enough to justify dealing with shitty systems/ heuristics to begin with.
I concur. In other words try to be on the "edge" where you're not looking at the same old patterns you've seen before, but are always attacking something relatively unknown. In my experience, senior people who always target their domain and level of expertise are bitter and jaded.
You dont need vigilance to keep learning. You need to learn. So, read books and technical articles.
Also, take a break and do something that is not programming as a hobby. Demotivation is more of function of routine and lack of sensory input and less of practical realities.
Software development often has an almost infinite number of ways to accomplish the same task.
Maintainability is as much, if not more, about correctly predicting the future uses and requirements of the software as it is about the initial coding practices and design patterns.
Working on older systems that are being used in ways that they were not originally intended is often uncomfortable for a developer. All but the most junior developers tend to have some painful memories of battling legacy software.
These add up to a situation where it is incredibly difficult and vague to determine the correct path. Both because there are so many ways to accomplish the task and because there are so many unknown future contingencies that ultimately determine how maintainable the software will be. Combine that with the painful memories most developers have from nightmare projects and you have yourself a recipe for emotional disagreements all around.
The grand irony is that, very often, once a developer becomes fully aware of this concept, they lose that internal fire and vigilance required to constantly seek out better ways to solve problems and their skills wane.