back
39 comments
The author touches on it, but to me, this is an extension of "ideas mean nothing, execution is everything"

I'm an 80/20 kind of person. I catch on quick, I'm good at ignoring details, and can usually hammer out a version 0 of something very fast. Then I get bored and don't want to do the hard work of actually making something useful. I've found that outside of looking clever in new situations, this approach really hasn't gotten me very far.

Universally, I have seen really successful people do the extra work for the incremental gain. Competition and success happens at the margins, so it's not surprising that is where the effort needs to go.

Incidentally, this is a justification for "top tier" employers that are looking for perfect grades or test scores. These are a strong signal not just that someone is smart (which in itself isnt to rare or exciting) but that someone is willing to do what's needed to eke out incremental gains at the extreme margins, which is a much more important quality in competitive businesses.

Edit - something like this is mentioned in Haruki Murakami's "Norwegian Wood". There is a character who was a natural musical prodigy and could sight read a song and play it well very quickly. But she could never be a competitive musician because she didn't want to put in the rest of the work to go from good to perfect.

As much hate as there is for MBAs and managers on Hackernews, the people who actually learn to manage well, as in, build teams with the potential for high performance and motivate them to perform, are nearly priceless for the reasons you've listed.

Note: obviously some people learn this without formal training, but to some extent it is a teachable skill that one can pursue in business school

I'm in IT but my MBA taught me a whole bunch of random useful things in business. Things like how to have difficult conversations, how to negotiate, how to do cost benefit analysis' for every applicable situation, how to interpret the numbers from statistical analysis, how to make decisions that involve a lot of stakeholders. Skills you can learn on the go, but it's just super useful when curated, peer-reviewed methods are spoon fed to you.
I am the same but over the time my version 0 grew in quality.

Sometimes I feel writing software is a bit like speaking a posm — there is a lot of power in not using certain words, not going certain rabbit holes, anticipating the paths certain ideas will put you onto and a lot of it must be thought out, formulated and spit out into existence at once.

Business is where the textbook ends and ingenuity begins
More like where the grind begins.
Yes
some of the success comes from the successful knowing the right way to share their prototypes in a way that excites and recruits others who are able to 'fill in the gaps' and then suddenly: startup!
The 20% people remind me of the "sociopaths" in the Gervais principle[1]. They are the people who are just waiting for the right moment to make a play for the top. Doing the rest of the 80% work is not visible or important enough to catapult them to the top. The 80% is left for the "clueless" group who does all the work but never gets recognized or moves up.

[1]:https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

Isn't the point of 80/20 that the last 20% are actually 80% of the work ? That detail is the hard work
Hello, author here, surprising that this one caught on when my own post didn't (https://news.ycombinator.com/item?id=26973194), I still don't understand the HN algorithm...

I want to be clear that there are great reasons to use 80/20-ing https://xdg.me/80-20/ and I do use it myself. I'm just expressing a latent feeling/worry that too many people think it is the secret to success because 80/20 authors try to 80/20 other people's success in an attempt to 80/20 their own.

The world doesn't need more overhyped-never-delivered things. Let's make 100%ing cool again.

> The world doesn't need more overhyped-never-delivered things. Let's make 100%ing cool again.

I suppose we could all get "100%" face tattoos. Too much?

as an 80/20er myself, i have "80/2" tattooed under my right eye ... i regret it every day.
And a response! https://xdg.me/80-20/
yes! i'm in the same writing group with David. thank you for sharing my post! honestly was a little worried about the reaction to this post since it does come off a little cranky.
I am here to validate your crankiness - people using the Pareto principle as an excuse for not doing a good job is becoming more common, with predictable effects.

On the plus side, like you said, it does result in less competition if you take your work seriously.

> I'm reminded of that classic movie Click, where Adam Sandler finds a magic remote that lets him "80/20 his life"

I always thought that Adam Sandler used the remote wrong. If I had one of those I would always be hitting the pause button. I could instantly be an expert on anything, and I'd never be sleep deprived again. #sequelplot

Is Pareto abused? Sure. But I think "premium mediocre" is as well. Which is a shame because it's a great concept -- I'd argue it's on par with McLuhan, Warhol, and Postman's more quotable ideas.

Rather than premium mediocre, I'd say Pareto is a hallmark of Veblenian Entrepreneurship[1], which is my favorite description of hustle porn.

[1]:https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3479042

80/20 can be useful when used in moderation. :-)
I think 80/20 is useful (to an extent) in thinking about how to spend your time not so much as formal model and not as an excuse to ignore details, cut corners, or avoid tasks that need to be done.

Used informally it’s a way of avoiding busy work and focusing your limited time and resources on the most important tasks, hang out more with the 20% (maybe it’s 10% or 70%) of friends that have the most fun with, and so on.

There are a lot of people who get trapped in the roughly 80% of effort that leads to the 20% of benefit, spinning their wheels, doing tasks that have little benefit. We’ve all wasted time unecessarily

There are many ways to think about this general idea of focusing on what’s important. Steven Covey’s 7 Habits of Highly Effective People talks about four quadrants: 1.urgent and important 2. Urgent but not important 3. Important but not urgent (he notes that it’s common to neglect this quadrant) 4. Not important and not urgent.

Ideally, we’d spend most of our effort, maybe it’s 80%, on 1 and 3.

A trite and possibly gag worthy way of way of saying it is, “work smart, not hard,” which I’d amend to try to work smart and hard.

Anyway, it’s useful to take a look at these ideas but not as an excuse to do shoddy work.

In my opinion 80/20 is the initial signpost. It's a filter to create some focus and reduce overwhelm.

Starting a new project, feature, hobby, whatever?

Figure out the 20% that gives you 80%. This is your primary focus. Then iterate and tweak, for the other of ~50%.

Aiming for 100% is counter-productive unless you work in an environment that 100% is required. So yeah, if you are working on a heart pacemaker, 99% is not good enough.

To me, 80/20 is somewhat recursive. For 20% of the effort, you get 80% of the value. Then, within the remaining 20% of value, you can find another 20% of the effort that gives 80% of the remaining value. Repeat infinitely. As such 80/20 is a useful tool in estimating how much effort it will take to get to a certain level of perfection.

If you are working on a heart pacemaker, 99% isn't good enough, but you do have to define what is. How many nines of reliability does a pacemaker need? Once you have the answer to that, you'll be able to figure out how many iterations of the 80/20 rule you're going to have to go through to get the reliability you want. Obviously in real life it's not as clean as always being 80/20, but generally the idea that the last 9 of reliability takes as much effort as all the nines that came before it holds pretty well.

I've been developing software for over 35 years and this is exactly the approach I and most of my teams (well, the successful ones anyway) have taken. The strategy is to show viability and let business drivers determine how and when to best tackle that 20%. The pursuit of perfection is the pursuit of failure.

P.S. - I've also worked in shops where bugs in software can result in serious harm or loss of life. Guess what? They don't use this approach.

What approach do they use?
It's similar to the defense in depth strategy used in the cyber space. First, you need to start with a real-time OS (RTOS). We used Microware OS-9. You need to ensure you have processes or tasks guaranteed to run at set intervals. Then you need to use a language that doesn't have garbage collection. Again, you need to know that the code you write will be run in the time you measured - you can't have garbage collection interfering with those timings. We used Objective-C (this was the early 90's - and remember, Objective-C was not a language invented by Apple). They desired the object-oriented nature of Objective-C with the runtime predictability of C. They felt C++ was too difficult to analyze.

Which is a good seque into the code. Yes, we used static analysis tools and performance analysis tools. We needed to know exactly how long each section of code took to execute on our target processor. We also did a lot of unit testing and had extensive integration testing. We had a dedicated build manager who ran the build daily, ran the unit tests, ran the integration tests, and ran the performance tests. They sent out a daily report. This was a full decade before anyone had created what we now refer to as CI/CD tools. All told I would say there was a 4:1 testing-to-coding ratio. Our customers never experienced any issues with our system not working properly - and these were industrial users in complex manufacturing environments.

Feature management is a serial process. You add one feature at a time and thoroughly vet it before adding the next feature. The marketing department prioritized features - usually based off what customers needed for their upcoming projects. We released on a set schedule so customers could plan their updates.

What's interesting is that pacemakers are not 100% reliable. This is why there are things like electronic scales that measure % BF that tell you to not use them if you have a pacemaker.
I am in favor of more laziness. Spend 20% of time automating 80% of the work. Spend more time with your loved ones, pets, take longer walks.
I use 80/20 rule quite a bit of coding. Developers can easily get obsessed with minutia that doesn't help the product organization or has ample diminishing returns. Tuning a business app is a great example. Is 80% performance tuning good enough? Most times, yes. In fact 80% is probably too much in most cases. I can spend the remaining 80% working on new features that would greatly enhance the business' service.

Only in rare exceptions would I want the inverse: spend the remaining 80% of my effort to gain the final 20% improvement.

Note to those reading the article: it does not state that you shouldn't focus on "high-value, low-effort" levers where minimum force gets you maximum results - it does state that using the Pareto Principle as an excuse for not applying force to high-value areas that are not in the top 20% is a bad idea.
There's a reason it's not called 100/20.

Should you 80/20 your primary life's work? Probably not, but I doubt you will. But for everything else, it's an incredibly useful idea to keep in mind. Life is short, people have other responsibilities, and you shouldn't sell yourself short or sell short what limited time you have to explore new areas in life.

Even if it is really half-ass (50/20?), most people can get farther as a beginner than they realize.

I’ve always understood the principle to refer primarily to the distribution of outputs. It’s not like any of us really know where to focus. For me it helps me set my own expectations more than being prescriptive. E.g. you might write 100 articles for your website and 3 of them will drive all your traffic.
Similarly, I think A/B testing early on in a product is an excuse to half ass too (kinda literally): https://zuhayeer.com/writing/abtest.html
If you try to learn a foreign language you quickly realize that 80% is actually a very low percentile. If you ignore or don't understand one thing out of every five you are really missing a ton and don't pass the threshold of usefulness.
The alternative title should have been 'don't use 80-20 as a crutch'.
Sorry for being somewhat off-topic but... wow, the scroll bar on this site, it's kind of awesome but it also almost hurts my eyes to look at it while I'm scrolling. Take a look if you missed it :D
Wow, I remember me and and old boss of mine read the 80/20 Principle and tried to live/work by it. Now I’m about to read that it was lazy.
I read 20% of the article. Now I don't need to read the rest, right?
The right 20%?

Was it the first, last or middle 20%

It is more of a Fifth-Ass concept than anything.