Code days are good days

I’m not sure if it’s because I’ve had a lot of non-coding days recently but I’ve been thinking about this idea that code days are good days (usually). What do I mean by this?

As a software engineer, the days that I get to write code, test code, and ship code (can be same day or over multiple days) are good days. I feel energized, I enjoy my work and my “tank” is filled up.

“Write code, test code, ship code”

Why not every day?

So if code days are good days why not just have code days every day? Especially as a software engineer who gets paid to literally write code, why don’t I just make sure I’m writing code every day to keep myself energized?

When you’re just starting out as a junior engineer most of your day is likely coding. Outside of a few small meetings, juniors are usually figuring out how to write the code and learning the craft of software engineer best practices. They are also learning the build tools, potentially the programming language, as well as learning the coding standards of the team/company. More likely than not they are being introduced to product concerns, UI/UX considerations, and various other non-coding things that arise.

Out of necessity and moving up

But as you move up to more senior positions this isn’t the case. You’re expected to do everything faster, more reliably, and with higher-quality code. This is largely because you’ve seen a lot of patterns, you’re very fluent in the build tools, and you know your way around the code base and the general lay of the land.

As you get more experienced it’s not uncommon to be asked to design the systems themselves. You are needed more to do this than just write the code because there are usually junior/mid level engineers who can build your vision but likely they will not be as fast or as fault tolerant in designing the system due to limited experience. You also might be tasked with finding out if something is even feasible at all, if there are any major blockers or tradeoffs, and if you can get some very specific piece of information from an external API, etc.

Role expectations

Depending on your company the dev role can include project management, project tracking, and like the previous point it can also be part of your role to design the system and plan it out but not necessarily to write any of the code.

In a recent feature I helped design, lead, and launch I did get to write some of the code, but I’d say 70-80% of my efforts were geared towards making sure the engineers on my team were not blocked, had clear tasks with accurate acceptance criteria, and were making the necessary progress to hit the launch deadline. I spent a decent amount of time writing out testing plans, getting security sign off, as well as making sure the feature met certain operational standards like having adequate logging, metrics, and alarms.

Even though not every day can be a code day for me, the other parts of the job have interesting side quests and make it so there’s never a dull moment.

Caveats

Not every type of code day is enjoyable. Occasionally there’s a complicated refactor which involves dredging through a lot of code and for some reason I don’t enjoy those days nearly as much.

Then there’s the complicated/or sneaky bug I’m trying to fix. Even though I’m in the code it can be exhausting as I’m hit with error upon error. So maybe the coding days that I enjoy the most are largely new feature and ones that involve writing increasingly passing tests? Or bugs that I can fix within a “reasonable” about of time?

And I’d be remiss to not mention the AI coding requirement that most companies are expecting from their devs. Using AI to solve my problems and even write the majority of the code isn’t quite as enjoyable for me personally. Maybe not as bad as the previous two caveats but when I spend time researching, finding a potential solution, and then go and try it out, it feels a lot more rewarding than prompting an AI agent to iterate on it for me.

Yesterday was a code day and I’m hoping today is as well.

-Jesse