Building on my previous post 'Why write a line of code', I've continued to reflect on our jobs as engineers in the context of a wider business.

In that post I made this observation:

The only reason you need to write code in a commercial organization is to ensure the company makes a profit

An uninspiring conclusion! But right now I'm convinced it's accurate.

Before we despair too much, I'd like to develop this idea a bit more. Yes, if you're employed by a business, the name of the game is profit. As an employee you cost the business something (salary, training costs, HR overhead, and so on). In return, the business hopes to get some value out of you - ideally more value than they invested in you originally.

Yet the value of an employee is hard to measure. It's very rare that I can point at a specific piece of work I do and say 'That resulted in X dollars of revenue'.

Thinking in terms of profit isn't helpful, even if it is the ultimate aim. It's depressing, cynical, and boring.

Instead, we ought to think deeply about the wider effect of the work we choose to do. Even the smallest pieces of work cause a chain reaction, some kind of ripple effect into the wider world.

Pick high impact work

Let's take a trivial example - a user reports a bug in the morning, you spend the day fixing it, and ship a release in the afternoon. What is the impact of that work?

To measure the impact you might ask questions like:

• Did we ultimately unblock the user?
• Does the fix affect many people, or just a few people?
• Does this affect the company's reputation?
• Did you share the knowledge of the fix with your peers? If a similar issue arises, is the team now more prepared to fix it?
• What did you learn by fixing the issue? Does it contribute to your progression as an engineer?

In fact, there's an unlimited number of questions you can ask.

So here's my point - before you pick up any piece of work, estimate it's impact by asking questions like these. If the answers are 'meh, not really', then perhaps you should rethink picking up that work.

Let's change things slightly - another bug report comes in. It affects our biggest customer. It's super urgent, and it's clear thousands of other users will hit the problem eventually. However, the fix will only take a few minutes of your time.

Of course, you'd fix that one too. A high impact piece of work that only takes a few minutes? Great!

Observe, therefore, that being busy doesn't mean being productive. It'd be better to come in for 20 minutes for that high impact work, than work a full 8 hour day doing low impact.

When put in such stark terms, it seems obvious. Yet I think it's easy to sleepwalk into spending a lot of time on low impact work.

If you can come up with a high-impact feature that takes one hour to design, implement, and ship - I'd say that's more valuable than spending a full 40 hour week working on trivia.

Of course, since impact is hard to measure, it seems necessary that we sign contracts that tell us to sit at our desks for 40 hours a week. It'd be hard to imagine an agreement that demanded '5 pieces of impactful work a month', for instance.

At any rate, the principle remains - focus on the high impact work. The lower impact tasks ought to come second on your priority list.