It's alive and shines

A reflection on the real purpose of software development and why we so often forget this purpose.

I like writing code when I fully understand why it exists.

When I write for myself, it might be 'to learn how to use a new tool', 'to share my knowledge', 'to create a hobby project', or even 'just for fun'. When I write code at work, it might be 'to solve a user problem' or 'to simplify a process'.

Knowing why I'm writing a program helps me avoid wasting time and effort. If I am creating a project for a hobby or writing code for fun, I know I can spend as much time as I want learning different tools and techniques. While in a professional environment, I know it's worth striving for efficiency (what's the best way to solve this?).

However, programs are complex and complexity can be deceptive. There often seems to be an infinite number of tools and techniques that can be used to accomplish a task and an infinite number of ways to combine them. And working on difficult, complex tasks can feel like progress, even when it isn't.

This may be one of the reasons, if not the main reason, for over-engineering –

creating complex software can be satisfying in itself.

Navigating complexity can be joyful. But if the goal is to solve a user problem, then a multi-clustered, parallelized, auto-scalable, quantum architecture is just one way, maybe not the only way, to get there. Not the goal itself.

While interviewing engineers, I often hear many people have had to work in a small team where the Lead has broken the codebase into multiple Netflix- and Revolut-style microservices. Everyone else on the team may have found this architecture awkward to work with, but they couldn't change it. Not because it would take a lot of time and effort to rewrite it. But because it seemed to the manager that the complexity of the design was more important than its effectiveness, because the architecture was well thought out and beautiful.

The story of Deniska Dragunsky, who traded in the big, beautiful dump truck his father had given him for a humble firefly accidentally brings us back to the real priorities in the software development process. A small and modest project has more value in the eyes of the customer if it lives and fulfills its function - whether that's to alleviate boredom while waiting for mom or to heal the user’s plans.

Often the most powerful ideas don't require the creation of cumbersome and complicated systems. They can be expressed through simple but life-giving projects that are task-oriented and bring satisfaction along the way.

The success and magic of programming lies not in satisfying the architect's sense of self-importance, but in its ability to solve problems and shine for the benefit of those for whom it was created.

A thought so simple and obvious to many, yet so often forgotten in practice; a reminder that you shouldn't fall in love with your technology. A reminder to myself too.