Among software developers, and perhaps all creative engineers, hard problems are festishized.
It’s a combination of the personality type that hungers for intellectual fulfilment, and the boredom that comes with the reality that most software development work is trivial and repetitive. Most projects are some kind of mutable list with some analysis on top.
Give the Boring Problems to the Boring Computers
For this reason I have long been an advocate of the idea of higher-level programming via 4GLs or “low-code” tools. Why waste money on smart people implementing trivial solutions? It is a waste, good developers resent working below their capability, and they inevitably make the problem interesting for themselves by introducing complexity that is not necessary but feeds their intellectual curiosity.
Photo by Glitch Lab App
I like the idea of these tools, although I’m not sure how pragmatic the available solutions are. They suffer from two clear failure modes. Firstly, by conflating programming with code they replace well-known, reusable coding skills with an equally complicated, non-transferable, bespoke graphical user interface based programming. It may be “low code” but it is just an inferior interface to creating abstract syntax trees. Secondly, such tools excel for certain low-complexity spaces, but fail spectacularly at higher complexity. Given that systems that survive tend to increase in complexity this creates a phenomenon where systems outgrow their low-code tool and have to be replaced. I’ll finish this tangent with an illustrative claim:
If your application is a set of lists with some reports on top then you are far better off with Foxpro or Access than with Angular and microservices
If we leave the easy stuff to the machines we can clarify the software developer’s role as being one of applying deep intellectual effort to genuinely hard problems.
The Dark Side of Hard Problems
Hard problems are hard.
They create fear and anxiety. They carry a genuine risk of failure and real consequences.
It is easy to crave an opportunity to work on something difficult, jump in full of ego, fail spectacularly, then quietly explain why it wasn’t our fault and can we please have another interesting challenge?
Just because an organisation is prepared to explore the boundaries of what is known and undertake speculative research projects that carry a risk of failure, doesn’t mean that failure is a good outcome, or one that will be rewarded.
Be scared of hard problems. Respect hard problems. Use that fear and respect to motivate extensive research, analytical decomposition of the problem, standing on the shoulders of giants, and doing absolutely everything you can to give yourself the best chance of success.
The Joy of Hard Problems
Hard problems offer the possibility of deep engagement and immersion. The work is deeply satisfying and presents the possibility of ecstatic success. To succeed at something difficult is to place a milestone in your career that once accomplished can never be taken away. To leave a trail of such achievements, perhaps interspersed with the odd forgotten failure, seems to me the most fulfilling career imaginable.
Photo by Nicholas Sampson