It's a bold statement to make.

But really, it's what we're all after, isn't it?

To increase our impact, to make more change, to achieve more and get more done with less.

You and me, we're lucky. As software developers we're in a unique position to leverage software towards that goal.

You know how powerful software can be — transforming entire industries, and turning teenagers into billionaires. In fact, you're already reaping (some of) the rewards of being one of the few who can wield this powerful force.

But if you learn to leverage it right, those rewards can grow exponentially.

Leveraged Upside (without the downside)

Let's say that you have a goal of increasing the usability of your codebase by 1% each month (we'll examine what this might look like later on).

Yes, the productivity of a software developer is extremely hard to measure — which can work for us as often as it works against us — but we have to work with something here.

If you can pull this off for an entire year, 1% each month compounds into slightly more than 12% — 12.68% to be exact.

This means that if you have a team of 8, after a full year of 1% monthly improvements you'll be operating as if you were a 9 person team:

12.68% * 8 = 101.44% improvement in productivity

Let me restate that, because I think that should blow your mind if you think it through.

If you, one developer on a team of 8, makes the entire codebase just 1% better each month, after a year you'll have doubled your impact.

If you have a team of 16? You've tripled your impact now.

This is what leverage can do for you, and it's incredible.

You're making your entire team more productive, so those effects are levered against your entire team. The bigger your team and the bigger your improvements, the larger the effect will be — and it can be quite large.

Note: A larger team does seem to imply that it's more difficult to make the whole team more effective, but it also implies a larger codebase with more opportunities.

It's not any more complicated than that.

All you need to do is continuously make small improvements like this, and your impact on your team and your company will grow exponentially.

Of course, I've just thrown some numbers out here, and they certainly look nice.

Is it really that simple?

How do we get 1% better?

What does it even mean to improve a codebase by 1%?

Since we're talking about developer productivity, I would define it to mean that all other things being equal, a developer can now accomplish the same task 1% faster.

Let's look at some more concrete numbers to see how this can play out:

Imagine that you just finished a project that took you 2 months to complete. We'll simplify 2 months to be 40 working days to make our calculations a little nicer.

1% of 40 days is 0.4 days, or ~3 hours.

Now ask yourself this:

Is there something that could have saved you 3 hours during that project?

Perhaps you had to refactor something before you could add a new feature. What if it had already been refactored nicely?

Maybe you needed to write some tests before modifying a big section of code. What if those tests were already in place?

You probably had to write some code that's not too different from code that had already been written in this codebase. What if you could have easily reused some code from elsewhere in the system?

It's not that hard to come up with optimizations.

Generally the problem for us is that we focus too much on optimizations. So I think you'll be okay with this part.

But here is where it gets tricky.

We're not just looking for a one time improvement. We're looking for something that will save us 3 hours on every project going forward (at least when averaged out).

Luckily for us, software lends itself really well to abstractions. And abstractions provide us with the ultimate form of leverage.

If you can write a nice abstraction — one that is actually useful, avoiding YAGNI/gold-plating/etc., you can get yourself these compounding improvements.

My favourite type of abstraction?

A highly reusable component, of course.

Doubling Your Impact

This is how you double your impact in one year.

Constantly be looking for these opportunities to improve your codebase by 1% — you only need to find one of these each month.

If you can do that, you'll double — or even triple — your impact in the next 12 months.

The numbers might not be 1%, 12 months, and doubled impact, but the principle is the same:

Find compounding improvements to your codebase through abstractions, especially reusable components, and you can leverage the productivity of your entire team.

The next step is to make sure your boss sees all of this tremendous value you're creating for the company 😉

My new course, Reusable Components, is launching in less than 2 weeks! Check it out here