Why We Program / The Love of the Craft

I’ve been a professional software developer for 20 years.

I’ve built embedded software, beginning with a TSR IRQ-driven remote management solution for a single-board computer (to allow us to securely control it on-demand over a modem), to a QNX-based RTOS monitoring and control platform. I’ve designed and constructed data processing and aggregation solutions as Windows services, Linux daemons, and duct-taped batch processes. I’ve built Win32  and Win64 applications (native and managed), DCOM/COM/COM+ tiered solutions — remember when n-tier was the price of entry to professionalism? — CORBA and microservices. I’ve been a Microsoft guy, a Delphi guy, a C# guy, a database guy, a Linux guy, a security guy, a web application guy, and a high performance big data processing guy. I’ve even been a domainologist.

I’ve built mobile applications and mobile targeting platforms on iOS and Android, and Windows CE years ago.

I’ve slung considerable C, C++, (Object) Pascal, Go, Java, and C# professionally. I’ve toyed with countless others. I’ve designed and managed enormous systems and databases, including for a couple of Canada’s biggest corporations.

I’ve been involved with a variety of styles of teams, in various levels of structure and rigidity. In a banking group with absolutely draconian process and hierarchy. In an agile financial upstart essentially rolling with whatever fits, gnashing around to find a process that works. In a telecom company somewhere in between.

I’ve been a team leader, a vice president of a medium sized organization, a software architect, a “junior” and “senior” software developer (hilariously I got the latter title about two years into this profession, denoting the ridiculously shallow career path many firms have in the hands-on realm).

None of this is a brag, given that it is hardly brag-worthy: I have no silicon valley experience, being the sort that generally stays within some radius of his birthplace (currently about 200km). I have no starred github projects. I have never worked on shrinkwrap software, or a triple-A game. I don’t have an inbox full of recruiter solicitations. I’ve never written a book (though I have authored magazine articles, for what that’s worth).

The vast majority of my work has been for companies around the edge, and for a lot of my career I have been “a big fish in a little pond”. My solutions are critically important for the people I work for, but not that important for society at large.

None of that was intending to be aggrandizing, and there are countless far more impressive developers in this field.

Instead the purpose of those paragraphs is to say that I’ve had a lot of varied experiences in this business, from starting as a junior tasked with doing the grunt work (where being a lazy worker I automated a manual process into a solution that grew into substantial business for the company), to guiding the implementation and technology for a pretty large team, including laying the blueprints in code.

Over my career I’ve had many paths out of programming. Options to move to pure management, or to architecture management (which unfortunately doesn’t include much actual software architecture). Even a CTO offer for a mid-sized company, albeit one that used technology in a periphery sense, and where it mostly meant doing boring vendor comparisons and meet and greets.

I turned them all down. I remained a programmer, or in a mixed position where my day to day still included at least 50% hands on. During periods this meant going solo and pitching consulting to all takers, particularly when our children were young and the demands of the family were many, essentially taking a sabbatical with occasional engagements to pay the bills.

I of course weighed the pros and cons, and on the pro side of moving more to management is that the requirements are so much more fuzzy and abstract, versus the technical paths where many unenlightened shops are asking for a laundry list of very specific technologies.

I love solving problems. I love the craft that we ply. The raw, voice-squeaking joy when a rashly implemented solution using some cool (ergo fun) new language or framework or technology actual works and solves some problem remains a reality of my world. I couldn’t stand moving too far from it. My eldest son is now going down the same path, and from day to day he has gone from Unity and C# to Java, nodejs, and most recently Python, enjoying the challenge and excitement of being exposed to new ideas and patterns.

I didn’t and don’t want to move to pure management.

To a lot of people, this is hard to understand. One of the root causes of ageism in this field, I suspect, is that a lot of people really don’t or didn’t like doing it: If it feels like a burdensome chore, then why in the world would someone want to do it when they’re further in their career? I remember being in my 20s and having these discussions with full of themselves peers who were sure that they would be managers by 30, VPs by 40, CTOs by 50, and so on, following the traditional path of the 1950s man. There was a prevailing notion, and it’s still evident, that any who haven’t ascended in such a manner had obviously failed during the climb.

It is the manual labor mentality applied inappropriately to a field of intellectual excellence. You start in the mail room, and then…

An architect is still an architect. A doctor is still a doctor. A researcher still a researcher. An artist is still an artist and a musician is still a musician.

So why then do programmers have to ascend into managers?