Investing in Your Development Time

A week or so ago, I [tweeted] some thoughts I’ve been having recently about work. I want to take some time to explain and expand upon those thoughts.

Your Daily Work Time is Finite

To refresh everyone on what exactly I wrote about, I talked about how I often spend my development-specific time at work. This means time that I’m actually sitting down at a computer and coding. Never mind the expanding role of more business-oriented needs. Those deserve writings of their own.

So, let’s say the average developer at your company is spending 20% of their time dealing with more “business-like” things - meeting with folks; getting feedback from users; following up on all the emails. The rest of that time, ideally, is going to probably go towards development of actual features and products.

Assuming you work around 40 hours each week, we’re looking at 32 or so hours that you have available to do development things with. How do we best spend them? I’ve found that so many companies have an endless amount of work to tackle, so the decision to work around 40 hours a week is purely a choice. Yet, there’s never enough hours we can work. It’d be safe to assume that no matter how much or how long or how hard we work, we’ve got to figure out how to best maximize creating things on a 40-ish hour work week.

I’ve found that I often split that development time up around a few themes:

  1. Writing features
  2. Fixing existing Bugs
  3. Building better confidence in my features
  4. Communicating the work I’ve done
  5. Designing Work I plan to do

So, what do these things actually mean and how does understand them help me better make use of my time?

In short, we often have to shuffle around prioritizing them based on our current work situations and needs. Sometimes you need to spend a lot of time writing a feature. Other times, you need to really invest some time better communicating what you’ve done and why you’ve done it.

I’ll break each one of these down and try to attach some practical value and instructions for each.

Writing Features

Products don’t get written without features. They’re the main vehicle of pushing things forward with your development team. They’re often what your team is judged by as well. So, why not just write features all the time?

Well, in short, the more forward progress you have the more stability you need to support it. If we push too forward with the development of our product, we often might find ourselves at the helm of something that’s really feature-rich but it isn’t incredibly usable. Even if you’re developing with a high level of precision and skill, there’s often times a need to invest in other things.

You should prioritize features when you feel like the product you’re adding onto is stable enough to support the feature you want to add. Think of a tree branch. You want to grow something that can be supported by the source that its growing from.

Fixing Existing Bugs

Every piece of code your write is going to have bugs. Some are more obvious than others - a syntax error vs a usability complaint. We’re always going to have bugs sitting at our doorstep waiting to be resolved. However, we can’t ignore them either.

The more bugs you have, the less stable your application in considered. The opposite applies for less bugs. While different engineering cultures prioritize the elimination of bugs in different ways, consider what I wrote about features above. We want to have a stable application to write features off of and eliminating bugs is a really practical way to get there.

Building Better Confidence in My Features

Sometimes work doesn’t fall into developing features or fixing bugs. Its often this weird combination of the two, where we’re building confidence in the things we’ve built or are building.

Here’s what I mean by this.

When we’re developing a feature, we or a small group of people are likely the only folks interacting with it. While we may all be really bright and good at discovering things, we eventually have to think about scaling out the feature to others. If its a developer-based tool, we need to think about getting it to work on other folks machine’s. If its a customer-facing feature, we need to think about how we can better improve their experience when we roll it out.

Recently, I remember I had been working on this Serverless Application project. I knew how to develop and deploy it in one environment. But I needed to collaborate with others and figure out a way to implement and scale it in multiple environments (development, staging, and production). I would classify this kind of work as building confidence in my features. We often think of that work as more DevOps-like. However, I’d argue that every developer will find themselves having to grapple with similar issues every once in awhile.

Communicating the Work I’ve Done

The obvious question that arise from this is: “Isn’t this business-related?”

While the answer can be yes, I’d argue that its very much a development-oriented thing as well. While there are channels we communicate through that tend to be more business facing (email, messaging, JIRA), there are just as many sources that are development facing (documentation, code comments, pull requests).

When was the last time you really put at lot of effort into documenting your changes in pull request? I’m talking about stuff that’s beyond: “I changed these files and now it works.”

We often view this stuff as a waste of our time and I’ll often agree with that. Yet, there comes a time when Pull Requests, Code Comments, and Documentation are going to be the legacy by which other folks understand your features and code. I believe its incredibly important to not only communicate what you’ve done for the purpose of having others understand how significant your work is, but also to easily onboard them to help with it.

Most projects start off with just a few people and scale to numerous others after they’ve found success. We need to best communicate that internally as well as externally.

Designing Work I Plan to Do

I’ve often had a heart for graphic design and art. I used to think that programming was more of a cut and dry science that isn’t designed. However, I was easily proven wrong after some time professionally developing.

There’s an immense value in trying to design your ideas before you implement them. Whether that means sketching out something on a notepad or just writing down what you plan to do, there’s a lot of help in planning what you’re going to attack before charging at it.

Design helps me understand what I’m about to do, but it also offers me a break from the grind of staring at a programming screen.