Upping Your Value as a Developer
Recently, as I was working to integrate our company’s new web platform with react, redux, and react router, I had an epiphany about how I can better create value at work.
I used to think the creation of value was all about how much you got done. Metrics for this could be the number of tasks completed, number of bugs fixed, or lines of legacy code eliminated through re-factoring in the code base. I spent a massive amount of time pushing myself to perform as many of these sub-routines as I could, and I ended up spinning my wheels and going nowhere.
I don’t think value in a business is determined in such quantitative terms, especially as an engineer. Although these statistics are a positive indicator of hard work, it seems that value creation as a software developer is about discovering and taking focused actions to directly push the project forward. If you take on too many auxiliary duties, you might miss core tasks that need to be done to accomplish business goals.
When I first started programming I would often be tasked with communication duties on top of my technical ones. This is probably because in Taiwan many people speak Chinese or English natively, but (almost) never both. Twice during my Taiwan start-up career I was asked to take on these duties, and I chose to try playing that role both times. I was excited to use my fluency in Chinese purposefully, and jumped to the task of ironing out the many difficulties in our communications pipeline.
However, after resolving many issues in other people’s work flow, I realized these extra duties sunk a lot of time I should have been using to apply myself to my own tasks and did not carry as much value as I thought they would.
Effectiveness vs Efficiency
Much in the same way that eliminating distractions caused by social media and cell phone notifications can increase your productivity, being able to prioritize and eliminate unnecessary tasks can push your programming game forward.
During my time facilitating communication, I kept falling into the trap of optimization for optimization’s sake and not focusing on what really needed to be done. I was efficient but painfully ineffective.
In The 4-Hour Workweek, Tim Ferris discusses the difference between effectiveness and efficiency.
Effectiveness is doing the things that get you closer to your goals.
Efficiency is performing a given task (whether important or not) in the most economical manner possible.
- Tim Ferris
Not just a work flow hack
As an engineer focused on productivity, I had always completely thought how to “improve my work flow.” Whether it be memorizing Vim shortcuts, learning to touch type, or even just automating certain processes during the day, I always strove to improve my ability to complete more work each day.
However, my main problem was that I was completing work without selection. This led to me to take on too much stress and started to affect my quality of life. Even though I could cover both programming and communication duties, the extra tasks led to a division of mind that ultimately hurt the quality of my programs.
The damage done by context switching is real.
Do not underestimate it.
I started to perform and feel worse both times. Interestingly enough, both times I tried to take on more of these responsibilities, the amount of value I was able to provide was more than what I originally expected.
When I later discovered that management did not value the communication duties I performed, I decided to cut them out entirely. At the second (and final) start-up I worked at in Taiwan, they wanted me to take an Engineering Manager position after a few weeks of helping facilitate communication. But after a couple more weeks in the position, seeing how much my job would suffer from the extra duties, I asked to step down. Although I believe it might have hurt my standing with the higher-ups in the company, the improvement to my quality of life and increase in productivity was worth it.
I consequently started to bury myself back into the programming duties I had been neglecting, and came up with a few strategies to apply effectiveness into my work day.
The Rules
When I removed myself as Engineering Manager, I had a lot of catching up to do on software development. Because of this, I devised a few rules of limiting communication in order to boost my productivity.
First, I cut out all facilitation of communication I previously did between other developers. Where I used to drive conversations during meetings, I did my best to avoid them like the plague. I vowed to only open Slack twice a day, and it turned out no one missed me and the world did not end.
Second, I cut down on the number of hours I worked. I had previously tried to set out a specified list of all the tasks I wanted to finish that day and work on them in order until they were all complete. I later realized I was not giving my brain enough time to rest and think of better solutions, and as a result I wrote buggy code.
I had already been tracking the amount of time I worked each day with a wonderful tool called Toggl, and only allowed myself three hours a day to work on start-up related features. This might not seem like a lot, but I only count work time (no breaks) and I ensure I am completely focused for each minute I track on Toggl.
I discovered that when I work fewer hours, I require greater focus to complete the most important tasks. Each time I sat down at my desk to code, I wrote down the top priorities that would push the project forward. I also shared these prioritized tasks with my supervisor.
During my next performance review, my supervisor mentioned how easy it was for him to manage me even though I messaged him at most once a day.
Since I was working much less time, I felt much happier and was able to spend more of my time in the office studying, working on my own side projects, and resting.
In short, I was promoted as Engineering Manager, hated it, fired myself, limited communication with coworkers, worked fewer hours, eliminated distractions like Slack, and ultimately obtained the results I was looking for.
Success — one habit at a time.
