November 05, 2016

How important is it to work efficiently?

Hello, developer friend!

Today I'd like to talk a little bit about the idea of effectiveness vs. efficiency, and how it fits into your daily work.

I've always been the type of person that shrugs their shoulders at micro-optimizations of tools and processes. So for example, I've never gotten beyond a level of mediocre proficiency with my text editing capabilities, my use of revision control, etc. I'm bored by arguments about what The Best Way is to use a particular framework is, or how to customize my development environment heavily.

Instead, I tend to focus on the other side of the equation: exploring the problem space I'm working in, making sure I'm solving the right sort of problems, making sure that I've narrowed the scope of the work I'm doing as much as possible so that I don't need a bunch of fancy tooling to support me, etc.

And when it comes down to it, I stand by my strong bias. Efficiently solving unimportant problems is a losing strategy, but inefficient-yet-effective work can still be quite valuable.

Because figuring out how to be effective is a hard enough problem on its own, I always push people to lean heavily in the direction of wondering "am I solving the right problem?" rather than wondering "am I solving this particular problem right?"

But that having been said, it's reasonable to ask "why not both?"--and as more people ask me that question, I realize it's something that I need to think more about.

Driving up efficiency can definitely be a good thing, and in some situations might even make-or-break your ability to stay on top of your work responsibilities. The key seems to be to recognize the difference between optimization-for-the-sake-of-optimization and optimization as a means of streamlining and routinizing the work you're already doing a lot of day-to-day.

I recently had a conversation with Brian V. Hughes about what it was like to be a web developer at the time that the Web itself began. This was a time of rapid growth and technology change, and as an early adopter he ended up having to build out a staff to help him keep up with the rapid increase in demand for web-related work.

This is surely a familiar problem for many... and usually the first impulse is to go out and aggressively try to recruit new hires with the skills you need as quickly as possible, expect a somewhat painful onboarding process, and then hope that things will balance out over the long haul.

But sometimes rapid team expansion can lead to a vicious cycle, where hiring new people and getting them to the point of being productive is inefficient, so you need to continuously keep hiring to compensate for the productive time lost in recruitment, onboarding, and training. This is a path of diminishing returns, and in some cases can lead to a death spiral.

When I talked with Brian about how he built out his own staff, he pointed out that routinizing and optimizing work ought to come before scaling a team, because this way you end up making it much easier for people to hit the ground running and also drive down training costs substantially.

This idea fascinated me, because I feel like it can be extended far beyond the context of building out a development team. In other words, I think there's something to learn from this which can be applied in everyone, even if you're working as a solo developer.

Brian suggests that the following rule ought to be applied whenever you're trying to grow something: define the problems you're dealing with, optimize their solutions, routinize your processes, and then work on scaling last.

This is a refreshing perspective, because it implies that we ought to know what we're trying to optimize and why before we dig into tuning the engine for its own sake. In order to do that, we need to have some decent awareness of our own friction points, as well as a clear understanding of the critical paths that cut through our daily work.

What I'm starting to recognize in my own work is that the process of becoming more efficient needs to start with documentation. And by this, I don't mean well-crafted tutorials and guides that are perfectly suitable for others to follow, but instead more like adhoc scraps of lab notes:
  • When I learn something new, I jot it down.
  • When I hit a pain point, I spend two minutes describing what it is that's standing in my way, whatever current workarounds I know, and also some thoughts about what I might try in the future.
  • When there's some process that's a bit tedious and error prone, I start putting together little checklists, even if some of their steps are a bit vague or are filled with placeholders like "Ask SomePerson about how to do ThisThing."
I would share some of these notes with you, but this is something I've historically been mediocre at (despite the fact that I *do* publish often), and so I need to spend some more time building up examples. I'll do a follow up in a couple months, and by then should have plenty to show.

I've also been encouraging everyone I collaborate to start documenting their own processes as well. I don't expect them to spend any significant amount of time on this, because I don't want it to feel like I'm slowing them down in any way. But when I say... "can you just drop a few lines in this wiki that list the basic steps you took, and then later on answer some questions if I need you to?"--pretty much everyone is willing to invest the 60 seconds of effort.

It's amazing to me how much these habits are already helping me. Simple chores that originally started as "Ask SomePerson because they're the only one that knows" can with just minutes of documentation effort become... "Check X and Y, and if they make sense, try Z. Otherwise ask SomePerson."

There is a proverb that says that even the faintest ink beats the strongest memory. There is probably some truth to that, and it seems like the essential step zero that's been missing from my own approach towards optimizing things.

I'd love to hear your own thoughts on this topic. How do you decide what to optimize in your own daily work, and when? What has worked and what hasn't worked? How do you know when you've become more efficient at something? Reply to this email, and let me know!


PS: Thanks so much to all of you who have picked up the Programming Beyond Practices book, we're off to a strong start! If you have a few minutes, please also help let others know what you think of the book by writing a honest review on Amazon, O'Reilly, and/or Goodreads.

Your review needn't be long or elaborate (although those are certainly welcome too)... a sentence or two that mentions anything interesting you found in the book is more than enough! In the case of Goodreads, you can even rate the book without adding any commentary at all, so it only takes a few seconds. :-)