What I Should Do, vs. What I Actually Do

Photo by Nick Scheerbart @nck on Unsplash

I’m a software developer. I’m a software developer looking out of the window on a bright summer Sunday in August. It’s quite frankly beautiful outside.

I’ve realised I need to study for a new job. I’m going through (basic) LeetCode questions so I can have some hope of getting through a first interview next week.

Who am I kidding? I’ve spent nearly an hour looking at Amazon. Now I’m writing an article.

This is the life of a developer. Instead of following a meticulously planned schedule, we are a mess of distractions and half-finished side-projects. Here’s a look at what I should be doing through my working week, as compared to how I actually spend our time

The Meeting Mirage

What I Should Be Doing

For each of those ceremonies, I should be attending and listening attentively. Contributing my experience and insights and helping boost productivity for the entire team.

What I Actually Do

Traditionally I attend and surf the web. I spent a good month looking at new monitors and then simply bought the cheapest one. I felt this was a waste of time (life is short after all) and decided to cram LeetCode in this time, but that degenerated into writing blog posts as The Secret Developer. I do feel a little better because at least I produce something with my time.

This is all enabled by switching off my camera and being on mute.

The Bug Fix Life

What I Should Be Doing

Each morning, I should show up to my desk and dive into the top-priority bug in the list. I should fire up the debugger, and methodically work through the bug until I can be sure I’ve fixed it. My work should avoid introducing new bugs or side-effects.

What I Actually Do

I log into my machine. After 30–40 seconds I make a coffee. Then I sit and check Slack and decide I need a new coffee before my next meeting. I repeat Slack-coffee in a look until the day is gone.

Code Review

What I Should Be Doing

I should be looking through other developers’ work to understand the context. If I’m unsure about something in the code I can give my fellow developer a call and make sure that the best possible code is pushed to production. 

What I Actually Do

I look at a pull request. There is no description of what has been done or why. I derive the ticket number from the branch name, but the ticket does not really describe what work should be done. I look at the code that does not conform to our naming conventions and has several bad coding practices embedded within it. I decide not to have an argument about the latter, can’t be bothered to pull the branch so “approve with suggestions” as is the culture in our company.

I feel like I did something and watch as my colleague spends half the day trying to get another review for their work. They get the second approval and push the change with the poor naming intact.

Conclusion

I try to project the persona of a productive developer at work. I’ve pushed one PR in the last month and keep getting away with it — and now is the time to move on — but LeetCode might be the only way in.

Since I’m writing this article you know exactly how this is going…