Navigating the Balance: What Software Developers Do vs. What They Should Do
Written on
Chapter 1: The Developer's Dilemma
As a software developer, I often find myself gazing out the window on a stunning summer Sunday in August. The weather is simply delightful. However, I am aware that I need to prepare for a new position. Currently, I am tackling some basic LeetCode questions to increase my chances of succeeding in an upcoming interview.
Yet, who am I kidding? I have spent nearly an hour browsing Amazon instead. And now, here I am, penning an article.
This illustrates the typical life of a developer: rather than adhering to a carefully structured schedule, we often become sidetracked by various distractions and incomplete side projects. Below, I’ll compare my ideal tasks for the week against how I truly spend my time.
Section 1.1: The Meeting Mirage
What I Should Be Doing
In each of these meetings, I ought to be present and actively engaged, sharing my knowledge and insights to enhance the productivity of the entire team.
What I Actually Do
Instead, I find myself attending meetings while browsing the web. I once dedicated an entire month to researching new monitors, eventually opting for the least expensive model. After realizing this was a waste of time—considering how short life is—I aimed to use this time for LeetCode practice, but that quickly devolved into writing blog posts as "The Secret Developer." At least I feel a bit more productive this way.
This behavior is facilitated by keeping my camera off and remaining on mute.
Subsection 1.1.1: The Bug Fix Life
What I Should Be Doing
Every morning, I should arrive at my desk and immediately tackle the highest priority bug on my list. I should engage the debugger and systematically resolve the issue, ensuring no new bugs or side effects are introduced.
What I Actually Do
Instead, I log into my computer, make a coffee after about 30-40 seconds, and then check Slack. I often find myself needing another coffee before my next meeting. This cycle continues until the day slips away.
Section 1.2: Code Review Challenges
What I Should Be Doing
I should thoroughly review my colleagues’ code to understand the context better. If I have any uncertainties, I should reach out to them to ensure we deploy the best possible code to production.
What I Actually Do
I glance at a pull request, only to find it lacks a description of the changes made or the reasons behind them. I deduce the ticket number from the branch name, but the ticket itself offers little clarity on the intended work. The code often deviates from our naming conventions and includes multiple bad practices. Rather than engaging in a debate about these issues, I choose to “approve with suggestions,” as is customary in our company culture.
I feel a sense of accomplishment, watching as my colleague spends half the day seeking another review for their work. They eventually receive the second approval and proceed to push the changes, including the poor naming conventions.
Conclusion
I strive to present myself as a productive developer at work. Despite pushing only one pull request in the last month, I seem to get away with it—yet now feels like the time to transition. However, I realize that honing my LeetCode skills may be my only pathway forward.
Given that I am composing this article, you can guess how my productivity is truly faring.
About The Author
The professional software developer known as “The Secret Developer” can be found on Twitter @TheSDeveloper and frequently shares articles on Medium.com. It appears that writing blogs has taken precedence over engaging in more constructive tasks.
Chapter 2: Balancing Responsibilities
This video titled "Doing What You Want To Do vs What You Need To Do" discusses the challenge of balancing personal desires with professional responsibilities, making it a relevant complement to the themes explored in this article.
Another video, "Should do vs want to do vs have to do," further delves into the intricacies of prioritization in the life of a software developer, aligning perfectly with the content presented here.