Why I'm Glad I Lack Passion to BE a Programmer

I used to consider myself a software developer. Technically, I still am; however, I personally don't make it a part of my identity. Instead, it's just an activity/job for me now – I just happen to develop software. The pedantic distinction between being something and doing something causes quite a drastic change in mentality and attitude.

I used to be passionate about becoming the best programmer I could be. Now, software development is simply one of the things I'm relatively capable of doing. The removal of the ego from the equation has yielded much more benefits than the passionate pursuit of being a programmer.

When I was a passionate software developer, it caused me to focus on myself rather than what truly matters: the problem at hand. I subconsciously tied my worth to my projects, because my projects defined who I sought to be. Any time we strive to be something, our ego interferes and dictates our feelings and decisions. After all, it's our ego which inspires the notion of being someone or something. Of course it would have the most influence, even if it's detrimental. When our ego doesn't adhere to its ideals, our self-worth takes a hit. We run away from potential dissatisfaction by distracting and eluding ourselves with methods that soothe and fulfil our ego.

With that mouthful rambling in mind, I'd feel mediocre for not constantly employing the "best practices" and design patterns, knowing all the algorithms, or embracing the latest, most delightfully delicious tech stack. Choosing old and boring technology meant being stuck in the past, being replaceable, being irrelevant. I'd react with "engineering" an SPA with all the bells and whistles that look great on the resume. Naturally, of course, the thing became an over-engineered, unmaintainable disaster. But I "architected" it! It took competency to develop so incompetently, and thus I was a competent developer, or so I thought.

I'd avoid PHP and jQuery simply because of the popularly negative opinion of them, and not because of any valid technical reasons. Rather than write a simple main() method which solves the problem, I'd "architect" code bases that adhere to the SOLID principles, with countless interfaces and factories that ensure flexibility. I'd write integration and unit tests striving for 100% coverage. It looked beautiful, it demonstrated my dedication and it fulfilled my pride. It adhered to the best principles, and thus it was great programming, and thus I was a great programmer.

It's of course a completely superficial mentality, even if it stemmed from a passion for being great. The problem is that when one is inexperienced, they listen to others for their judgement of what's great or not. Of course I'd listen to the vocal opinions and criticisms, even if it was all subconscious and unintentional, and even if the opinions and criticisms were flawed and biased. When that naivety went away with experience, I've stopped being impressionable and my technical choices had some sanity.

But I was still bound to my own self-perception about who I am and who I strive to be. I still had a passion to be a great programmer. As such, there was always a risk of dissatisfaction, and thus a fear of it. A fear of dissatisfaction resulted in, once again, distraction from what truly matters: the problem at hand.

Over time, I stopped striving to be a programmer. My passion didn't die; instead, it changed priorities. It was no longer about my identity of being a programmer, but rather about my activity of programming. My ideal for software development is to find the simplest solution to the practical problem. I focus on ensuring that I program in such way which adheres to my pillars for a great program: simplicity, maintainability and above all, value.

With this in mind, if PHP and jQuery solve the problem in the simplest way, I'll choose them even in this day and age. If a long procedural method solves the problem in the simplest way, I'll choose that over "engineering" a SOLID, fully covered code base. Of course, if an SPA with a SOLID code base better solves the problem, I'll go with that. What matters in the end is that I choose the right tool for the right job. I'm indifferent to how great or mediocre - or modern or outdated - it may make me as a programmer. My current or idealised identity shouldn't interfere with my technical decisions.

The death of my passion to be a programmer - and the birth of my passion to program - granted me much more satisfaction and happiness. It luckily improved ability to simply yet effectively solve problems. If the problem isn't solved well, I'll fix it rather than feel disappointed. Failure and success spark the same response: simply knowing what to do the next time, rather than anger or disappointment. It's quite liberating to strive for simple and boring, even if it may compromise the idealised (and flawed) image of a software developer.

My technical stacks are boring (psst, PHP and jQuery are among them despite their flaws). I've written web apps without a line of JavaScript – the complete antithesis of today's venerable SPAs. Indeed, they are completely server-side, and that confession may stir some judgement of my relevance as a developer. After all, there's a plethora of developers out there who will develop everything with much more responsiveness and modernity. My technical choices may be dismissed as legacy and obsolete.

But I don't mind anymore, because their simplicity is greater than the alternative, and future maintainers of my projects will hopefully agree that this was the right choice. And above all, the value I've brought to my clients and businesses - by actually solving their problems with effectiveness and velocity - matters to me much more. And that was mostly possible by focusing on programming a great solution, rather than being a great programmer. It's no longer about solving my identity crisis, but rather solving the problems of the world. It's about rationality and logic, which is what computer science in general strives to be.

Should a client need fully-fledged JavaScript SPA with all the design patterns, SOLID principles and modern libraries/frameworks, I'll go with it. But I'll do so only when it's the simplest and most maintainable solution to the problem, and not because I want to be the greatest of programmers in my or other people's eyes. That type of passion is a thing of the past, which is why I'm much more happy in life, and perhaps a bit more effective at solving problems.

That's why I'm glad I lack passion to be a programmer. The passion focuses strictly on the solution. It lets me be a bit more objective in a field that's prone to a lot of subjectivity and - like almost any field - pride and ego. I sure have a lot of it, hence this long post about myself, which I thank you for taking your time to read! I hope it'll help you if you face similar turmoils about your quality and value.