Edition 11

Do More by Doing Less as a Software Engineer (The Pareto Principle)

Today I’m going to share with you how I use the Pareto Principle to maximise my time and output as a software engineer and how you can do the same.

The most precious resource anyone has in life is time. We all have 24 hours in the day but we’re not all able to make the most of it.

Your time cannot be replaced, topped up or be given back. It’s THE finite resource for all of us and what’s worse we don’t know how much we have.

Except if your Bryan Johnson in which case this doesn’t apply to you, but anyway.

Most software engineers fail to identify where they should spend their time to create the most impact and value for their own progression, for their colleagues, their communities, their company or business etc.

Most engineers get sucked into the tinkering blackhole, focusing on the 80% that doesn’t matter. Great engineers identify the 20% that matters and focus 80% of their time and energy on that.

In this newsletter we’ll cover:

So if you want to save 80% of wasted effort then keep reading.

The Pareto Principle (Briefly)

The Pareto Principle, also known as the 80/20 rule, was named after the Italian economist, sociologist and philosopher Vilfredo Pareto.

Pareto observed that 80% of Italy’s land was owned by 20% of the population. He also started to notice this ration in all parts of life including his garden. 20% of the plants produced 80% of the produce and so on.

It’s a ratio that can be seen everywhere and almost seems like a natural law at this point.

Today it’s widely cited as: “80% of the outcomes come from 20% of the inputs”.

Why It’s Important for Software Engineers

It’s important for a number of reasons but I say the most important reason is time.

This world is a fast and every changing place but especially in the technical world and online.

The internet doesn’t sleep and neither does the advancement of technology.

Every year the software engineering space becomes more and more popular as more companies look to capitalise on technological advancements like AI.

Our jobs as software engineers is more pressured then it ever has been to compete on delivery and speed.

As software engineers our time goes into to all sorts of activities like:

We might spend 10 hours trying to automate something that only takes 10 minutes to do manually and rarely happens.

We might spend 80 plus hours learning a new language or framework only to utilise 20% of it’s capabilities.

And it’s not just time, the pareto principle could manifest itself as:

We need to know where to spend our time because things only get harder and slower as our product grows.

If we want to stay ahead as a professional we need to understand where to spend our time.

How I Maximise My Time Using This Principle

These are all scenarios or things that I do in order to save time so that I can focus on the 20% of things that matter.

1. Measure Twice, Cut Once

It’s an old saying but very true even for software engineering.

I save time by spending more time planning and thinking something through both from a technical perspective and from a theoretical perspective.

Using techniques like pseudo code, diagramming and simply writing a to-do list allows me to step through the process of creating without the committing to the solution from the outset.

Planning allows you to see if there’s any bad assumptions, gaps in knowledge, pros and cons in potential approaches and tests your understanding of the problem itself.

Now you might come up with a plan, start implementing and still run into issues but I guarantee that if you don’t plan you’re way more likely to waste your time.

Brainstorm, create a plan, check and edit the plan and then implement.

80% time spent planning, 20% of the time spent building.

2. Listen, Watch and Find the Pain

I maximise the impact I can make by listening, watching and searching for signs of pain.

For example, I keep an eye on communication channels at work and make note of common trends where developers either complain about things or raise issues about tech, process of whatever it may be.

If it’s happening very regularly then it’s clearly a pain worth solving. I can safely prioritise my time to engage, ask questions and come up with a solution that helps everyone. Everybody wins.

Other things to watch out for could include:

Become attuned to hearing and seeing consistent problems and find the time to solve them.

80% of the pain will come from 20% of the problems.

3. Review PRs Face to Face

This is a simple one but I save a lot of time by simply reviewing pull requests with the person that created it.

Unless it’s very simple and I understand the context of the changes it’s just easier to talk it through face-to-face.

I spend 20% of the time I would otherwise spend reviewing it with the person and get 80% more value, understanding and connection with that other developer.

The devil is in the detail and simply looking at code for “correctness” is not all that’s needed for reviewing a pull request.

80% more value and understanding gained in just 20% of the time for pull requests.

4. Put Myself in the Customers Shoes

If I can put myself in the shoes as a user of the product I build I should understand what features and pages I use the most.

Now I don’t assume every user is the same but I try to use the products I build so I’m more likely to understand what the user is most likely to do.

Most businesses will have some marketing and analytics function and they should be well attuned to the types of demographics the product has. They might even have avatars for common or target customers.

It’s worth speaking to them to gain an understanding of what common customer behaviours exist, if customers ring or email at certain points because they get stuck or have a complaint.

Analytics tools provide so much data about our users and we can even implement custom tracking events to better understand what customers use commonly or not.

Find the 20% of features and pages that customers use and focus on making those the best they can be.

80% of customers will use just 20% of the features so make them great.

5. Do the Numbers Add Up?

Automation, upgrading, refactoring, refining, these are all potentially pitfalls for time as developers.

We like to make things right, to correct things and optimise things.

But sometimes it’s not always beneficial to do so.

We spend more time automating the thing then it takes to just do the thing manually. Especially if it doesn’t need to be done very often.

We spend a lot of time upgrading and managing dependencies when we might just be better off creating our own functionality with core languages that won’t outdate over time.

We spend time refactoring code but don’t stop to assess if the refactor produces any real value either to the user or to us in our developer experience.

Now this doesn’t always happen but I’ve seen plenty of cases where it has.

We take a lot of pride in our craft which is great but sometimes we fail to assess whether the time spent is going to be worth it or not.

If the numbers don’t add up then why are we doing it?

80% of our effort, time and craftsmanship should go into the 20% of activities that make a difference to the user and the developer experience.

How You Can Apply the 80/20 Rule Starting Now

If I was struggling for time at work here’s a few things I would look at, minimise and change using the Pareto Principle in order to win some time and spend it on things worth doing.

Minimise Meetings

You’re a software engineer, you’re a creator, a problem solver.

Your time is best spent when you’re creating, building and solving problems.

Meeting can serve a purpose but most meetings could simply be an email that’s clear and concise rather than a 30-60 minute chat that involves little discussion or is simply acting as approval by committee.

Look at your meetings and see what 20% are truly valuable and look to remove the rest.

Identify One Big Pain Point

Like I already mentioned in my examples but try to find one clear and intense pain point that’s shared between many people.

Either at work, in an open source project, community or whatever it may be and then hone in on it, ask people questions to clarify the problem and find a way to solve it.

You’ll learn a lot and see the effects of being able to solve the real problems people have that make the biggest difference.

Thanks for reading

Time speeds up as we get older. It’s scary but true so make sure to assess and use your time well. You won’t always get things right and optimise but at least being conscious of it will save a lot of disappointment and frustration further down the road.

Thanks again 🙏

Knowledge for the healthier, wealthier, long term developers

Sign up to my weekly newsletter for software engineers/developers that want to grow. I share my past successes and failures so you can get a head of the rest.