I love developing, again

I'm writing this today to remind myself: I actually do love developing. I do love the moment of sitting in my editor, with a challenge or idea, and writing an elegant solution to it.

Running an app on production – is a different beast. A nearly joy-less scenario. Its all remedial! Its scaling, bug-finding, performance tuning, conflict merges, security audits, etc. It's a lot of work. All the benefits come from that software's near-invisibility to the customer who uses it.

Since 2020, this burden began to overshadow the part of my brain that liked to write code to solve problems.

In fact, one of my most pithy and popular Linked Posts is simply: ["Code is not art, code is paint."]

Code is the thing you use to make, not the thing you are making.

But, you can still enjoy working in the medium – unfortunately for me: I burnt out.

And when it comes to software, the fact is: I've seen too much. I've reviewed too many pull requests, refactored too many regrettable patterns, isolated too many legacy implementations, and had to justify addressing all of this to product managers, stakeholders, clients and my own teams.

To the point of it becoming my duty – my official role: to find the issues that code creates.

When I assess a codebase, a product development team, a cloud architecture or a business model, I see all the things that can go wrong. And yes, this is part of my value ! By identifying and eliminating that risk, I am serving the team, the business and my clients. Its the shortest definition of the codebase risk mitigation aspect of what I do as a Fractional CTO or a Technical Leader for my clients.

But when I go back in time to my teenage self, plugging away at HTML in notepad.exe and loading it up in Netscape Navigator 4 – what I see there is a joy of creation. I wasn't a good engineer, consultant or leader. I was just using creativity to problem solve and loving it. I was a developer.

I lost this joy for many years, but recently I found it again: thanks to the magic of AI coding assistants.

Fast forward to July 2024, today – I identified a new challenge and that would benefit by learning and using Instructor – a python library for structured output with LLMs.

Last year, I would have internally groaned to have to learn a third-party module's API, customize my IDE & linters and write the needed tests before I could deploy this idea.

Instead, I found myself thinking: "Great, I'll read up on the high-level concepts of the library, pass the API docs to an LLM so I can chat through any unknowns, and have VS Code's Copilot write the tests – I'll have a working POC within the hour."

And I did!

This "partnership" was a missing piece. As a solo consultant, and often the most senior on a particular problem, I'm often alone and isolated when working through technical solutions (unless I'm supporting a client's developer – in which case I'm the assistant & support team). Having a coding assistant is a renewal of energy and creativity.

Having the assistant suggest a bad tab completion isn't a problem, it activates my refactoring muscle and gets me to the next phase.

In 2023, I used a coding assistant to participate in a Game Jam, writing Lua for a Playdate game – neither of which I had ever done before.

And so, I'm doubling down. I've refound the joy and I want to hold it as long as I can. I'm finding that my love of development is resurfacing – and so I'm finding more and more opportunities to write code.

Does this mean more short-term projects? Small bets solo projects? Staff+ roles as opposed to engineering management or fractional CTO roles? Who knows!

For some, this my seem like a career regresssion but for me, its a return to form.

I love developing... again.