
Effective Engineer – Notes - signa11
https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f
======
nostrademons
"Opportunity cost of working on wrong ideas can set back growth by years."

I feel like this is spoken by someone who hasn't seen more than one technology
cycle come and go.

What I've observed - having started my career back in the Java-will-eat-the-
desktop days and then adapted through webapps, big data, mobile, and now AI -
is that the people who are best positioned to capitalize on an emerging
technology wave are the ones who started working on it before anyone realized
it was important, just because it was interesting to them. They're the ones
who write the papers and software that everyone else evangelizes, and then get
multi-million-$ signing bonuses or stock grants (or billions of dollars worth
of cryptocurrency) when corporate interests catch on that this is a new
technology wave. But at the time they start working on the idea, it's both
useless and unlikely to work.

You can make a decent living always being on the look out for a new technology
wave and jumping on it as soon as it's clear that it's hot. I spent much of my
20s doing that, and made enough money doing so that I can take it a bit easier
now. But it's exhausting, and you'll never be the one actually driving change.

It's also usually not clear what's the "wrong idea" except in retrospect.
DropBox is rsync with cloud storage and some pretty slick desktop app
integration, done at a time when everybody thought that desktop apps were dead
and Drew's Windows hacking skills were old news. But it's that familiarity
with old technology that put him in a place to realize that new technology
could make the old technology dramatically more useful, to the tune of a $10B
company.

~~~
edmondlau
For every person who rode a powerful technology wave, there are also many
others who rode the wrong ones.

One of my favorite stories from Drew was that when he first started Dropbox,
he created a 4-minute demo video showcasing the product that functioned as an
MVP for the product. The video drove hundreds of thousands of people to their
site and grew their beta mailing list from 5,000 to 75,000 people overnight.

On the outside looking in, skeptics might have thought that it was nothing
new. But the MVP provided validation around what future customers actually
thought.

My main takeaway from that story (and that I share in the book) has always
been to validate your ideas early and often, so that you can get more signal
on whether the assumptions you're using to shape your behavior are accurate.

More about the Dropbox story here: [https://techcrunch.com/2011/10/19/dropbox-
minimal-viable-pro...](https://techcrunch.com/2011/10/19/dropbox-minimal-
viable-product/)

~~~
nostrademons
That's true and part of the challenge. It's not always clear what's a powerful
technology wave and what's the wrong one.

I've actually got a bit more of a personal connection to DropBox - Drew was
active on HN before founding it, he posted it here before posting it on Digg
[1], and he took me out to lunch right after they'd gotten their Sequoia seed
round and asked if he could convince me to be employee #2. At the time, I was
working on a casual game creation startup with a friend, and I declined, #1
because I felt I couldn't leave my cofounder and #2 because Drew had a
startup, I had a startup, and at the time it wasn't clear which of us was
actually more likely to be successful.

Before you laugh, consider the environment in Feb 2008 (when this occurred).
My cofounder was a consultant at Monitor Group, where he'd been researching
the casual gaming space and had run across multiple reports saying it would be
a $200M, $1B, etc. space (market research reports never agree on market size,
because they're largely bullshit). Kongregate had just raised a Series A from
Reid Hoffman, Jeff Bezos, and other luminaries. Max Levchin had just raised
$50M for Slide the month before. Zynga had just been founded but Farmville
hadn't come out yet. The Web 2.0 bubble was in full swing, AJAX and Javascript
were the new hot buzzwords (I had just ported Arc - PG's pet programming
language, which HN is written in - to Javascript, which is what caught Drew's
interest in the first place), and as you can see from the first comment on
DropBox's "Show HN", anything that required installation of software was
considered a non-starter. And our product concept let everyone, from teenagers
to retirees, build their own games instead of being at the mercy of a studio &
professional developers.

My lesson from how things evolved - learned _much_ later, and I'm probably
still grasping the implications - was to preference personal experience over
industry zeitgeist and prestigious research reports. Drew's personal
experience with the problem domain and his 75,000 beta signups were worth a
lot more than the famous people and industry market research reports around
the problem domain we were solving. And this insight has actually saved me a
lot of time & aggrevation chasing fads that people realize are bad ideas 4
years in.

But this is not obvious to someone just starting their career, probably
because they don't actually have all that much personal experience to draw
upon, and because it takes a certain amount of chutzpah to hear about all
these eminent people saying "This will be the next hot thing, you better get
in now!" and think to yourself "Actually, sounds like bullshit to me."
Personal experience is also inherently limited because you've only got your
own and it takes years to build; it turns out that the set of problems you can
viably solve is actually quite small.

[1]
[https://news.ycombinator.com/item?id=8863](https://news.ycombinator.com/item?id=8863)

~~~
edmondlau
Wow, that is an amazing story. Thanks for sharing.

It really hammers home how hard it is to disentangle good & bad advice and how
easy it is for an outsider looking into to really underestimate the depth of
someone else's expertise in a given domain.

~~~
LrnByTeach
>It really hammers home how hard it is to disentangle good & bad advice and

> how easy it is for an outsider looking into to really underestimate the
> depth of someone else's expertise in a given domain.

------
IronKettle
This is totally an incomplete thought, and I'm not trying to be down on this
author in particular:

It's interesting to see a lot of management thoughts and colloquialisms slowly
creep into the "other side" of software development (i.e. the actual
developers) and become fairly well-tolerated.

We still make fun of phrases like "paradigm" or "synergy", but we're all
mostly on-board with phrases like "own <x>" or "growth mindset". You can see
the author using the word "leverage" here repeatedly in the same way that we
often chide managers for using words like "synergy".

Interestingly the conversation around "effective engineers" has also shifted
to really de-emphasize that technical ability - the best engineer is a good
teammate, first and foremost (and I think a not-so-subtle implication also is
that a good engineer is mostly extroverted as well). In the past decade or so,
it seems like the "effective engineer" has become one who straddles that line
between management and technical ability.

I don't really have an opinion on this yet (I think there's good and bad, as
with most things), but it's just fascinating to watch.

~~~
edmondlau
It's less about management and technical ability, and more about soft skills
and hard skills.

A recent Washington Post article shared an analytical study from Google on
what made engineers at the company successful:

"Project Oxygen shocked everyone by concluding that, among the eight most
important qualities of Google’s top employees, STEM expertise comes in dead
last. The seven top characteristics of success at Google are all soft skills:
being a good coach; communicating and listening well; possessing insights into
others (including others different values and points of view); having empathy
toward and being supportive of one’s colleagues; being a good critical thinker
and problem solver; and being able to make connections across complex ideas."

Unfortunately, almost all computer science education nowadays focuses on pure
technical skills and hiring interviews at most tech companies also focus on
the technical skills. The impact is that many engineers plateau in their
careers because they've underinvested in (and oftentimes looked down upon) the
"soft skills" that actually separate the top engineers from everyone else.

Here's the article: [https://www.washingtonpost.com/news/answer-
sheet/wp/2017/12/...](https://www.washingtonpost.com/news/answer-
sheet/wp/2017/12/20/the-surprising-thing-google-learned-about-its-employees-
and-what-it-means-for-todays-students/)

~~~
robotsonic
>Project Oxygen shocked everyone by concluding that, among the eight most
important qualities of Google’s top employees, STEM expertise comes in dead
last.

This result seems a bit unsurprising. People who work at Google would already
be in the top n-th percent in terms of STEM expertise. If everyone you hire is
'above average' then being a bit better than that has marginal gains and other
factors would lead to your success. I'd be curious to see how this plays out
at smaller firms where they cannot afford to hire the top-end STEM expertise.

~~~
edmondlau
Your observation is a great one, and I'd love to see more data on this as
well.

A related point, though, also rings true. Soft skills like being a good coach
and effective listening are so underinvested in, that even marginal
improvements in those skills lead to huge differences in success.

I see this in engineering leadership workshops that I've run with Jean Hsu and
Diana Berlin, where even teaching a handful of coaching and listening skills
can have a transformative impact on participants.

If you're interested in future workshops, you can sign up to hear about them
here:
[https://effectiveengineer.typeform.com/to/cDMeZu](https://effectiveengineer.typeform.com/to/cDMeZu)

~~~
brucephillips
Do you have any ideas on how companies can better assess soft skills during
interviews?

~~~
edmondlau
At Quip, we run one coding interview that happens on a laptop, and where your
conversation and discussions with the interviewer, including how you handle
suggestions and feedback, matter a huge deal.

For experienced hires, we'll do deep dives on technical projects that they've
worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining
that team. Bring me up to speed." These interviews focus on whether the
candidate can clearly articulate concepts, explain the big-picture
motivations, defend decisions they've made, understand complex technical
problems, and stay humble and share lessons learned.

For manager interviews, we'll also do interviews that are one-on-ones with
engineers on actual issues that they're facing.

~~~
curun1r
> we'll also do interviews that are one-on-ones with engineers on actual
> issues that they're facing.

Be careful with this approach. If you're not paying candidates for their
interview time, you're not allowed to use their work. Big companies go to
great lengths to demonstrate that the entire interview is for the purpose of a
hiring decision and nothing more. This is to limit liability. Your approach is
very dangerous for your company and if an unhired candidate's idea shows up in
your product, even if you arrived at that result independent of the interview,
the candidate has a strong case against you in a lawsuit.

If you're doing interviews like this, be sure you've discussed all the nuances
with your company's lawyers.

------
henrik_w
Really great book! The things that stood out for me:

\- Optimize for learning

\- Invest in time-saving tools

\- Shorten the debugging loop

\- Don’t sprint in the middle of a marathon

\- Recovery over prevention

\- Automate mechanics, not decision making

\- Make batch processes idempotent

We read it in the book club at work a year ago, and I wrote a longer review of
it here: [https://henrikwarne.com/2017/01/15/book-review-the-
effective...](https://henrikwarne.com/2017/01/15/book-review-the-effective-
engineer/)

~~~
edmondlau
Awesome! Thanks for adding your notes to the discussion.

------
edmondlau
Hi! I'm Edmond, the author of the book. Happy to answer any questions about my
two-year journey in self-publishing the book.

~~~
mzzter
Hi Edmond, is “high leverage” a phrase you use in the book? From the notes,
“leverage” is defined as “impact / time invested.” Why did you choose
“leverage” to describe this concept? “Leverage” suggests to me that it is
grown with the idea of using it to climb a career ladder, but I’d like to hear
your thoughts on this, as I have read just these notes and not the book yet.

~~~
edmondlau
Yes, "high-leverage" is a phrase I use in the book. I learned about leverage
when I read Andy Grove's High Output Management.

Why the word leverage?

Time is our most limited resource. And so the way to really increase our
impact (say by 10x) is not to increase the number of hours you work, but to
increase your rate of impact, which is how I define leverage in the book.

Another way to think about leverage is in terms of a lever, which lets you
apply a little bit of force, have it amplified, and then move large boulders.
Many of the stories and strategies from the book talk about these leverage
points in engineering, e.g. investing in iterating speed or validating your
ideas early and often, where small bits of effort end up having a
disproportionate impact.

~~~
davidjnelson
What’s the right level of completion for validation? A few weeks for a
prototype seems reasonable, but even that can result in feedback that isn’t or
isn’t considered fast enough.

~~~
brucephillips
It depends. Easily communicated product ideas can be validated on day 0 by
talking to users.

Less easily communicated ideas often need at least a demo. Dropbox is one
example.

------
jyriand
It's strange how obsessed software engineers are about methods of working. At
a surface level it's just: sit down and write the code. But actually there are
thousands of programming languages you can choose from; there are build tools,
code standards, testing(to TDD or not to TDD) and mental models you have to
wrap your head around before you even can start to consider yourself a decent
programmer. It's fascinating, but at the same time I wish it was all simpler.
I wonder if there are other occupations in the world that are so much focused
on tools, paradigms and methodology as software engineering(investing and
trading come in mind. And it's interesting that these notes use so much
investing and business lingo).

~~~
nine_k
If it was simpler, it wont command such wages, and would be automated out
sooner.

Humans' current advantage is the ability to tackle complexity and uncertainty.

~~~
davidjnelson
Another way to look at it is automation will free people up to solve more
important problems.

~~~
nine_k
Yes, those who'll happen to be capable of that by the time.

------
makecheck
On the topic of reading code “written by brilliant engineers”…

Code bases can be so large that you might find brilliantly-written things
intermixed with things that are not brilliant (and some of those parts may
even have been added by the brilliant engineer on an off day). Therefore, it’s
risky to just absorb an entire blob as Good without also understanding its
history.

An interesting side effect of languages/ecosystems with single coding styles
enforced: bad changes to good code no longer stick out like a sore thumb! In
my experience, developers with the discipline to write great code also
typically write it in a consistently _structured_ way, and it’s kind of useful
that “warts” added by others over time usually won’t follow the
structure/style and those warts will be easier to find and scrutinize.

~~~
beager
Somewhat unrelated, it would be great to have a Medium-style highlight feature
for codebases, where you could onboard developers toward excellent practice by
highlighting good code in a repository that consists of various levels of
code.

~~~
Systemic33
That's actually a really brilliant idea.

We have people sometimes produce the software equivalent of a Picasso, but it
so rarely comes to light, and even more rarely codified to
guidelines/standard-practice.

Would be very good to have "greatest-hits" of a company's codebase, that could
serve as internal knowledge-sharing.

------
inetknght
> _Optimize for Learning_

An idealist, for sure...

> _Prioritize learning over profitability._

... but that doesn't _sound_ very pragmatic.

I love learning. My boss loves making the company profitable. Coming to a
happy medium is where a lot of learning can happen if both of you let it. If
one party's not on board, then it's going to end up being a problem.

~~~
whistlerbrk
I really liked this post, and I'm again saddened to see 'take downs' in the
comments (not solely addressing you).

The author said "prioritize" not to sacrifice profitability in order to learn.
By prioritizing learning you may very well increase profitability over the
long term. See the recent Google Maps is a moat post.

~~~
brucephillips
Challenging an idea is not a "take down".

~~~
whistlerbrk
At the time I posted there were 3 top level comments, all negative on the
post.

------
partycoder
I think that the understanding of software engineering as an occupation is a
bit oversimplified.

While there are good chances most people will be working on web or mobile
applications, there's much more going on. Compilers, cryptography,
compression, operating systems, graphics, simulation, data retrieval,
distributed systems, etc. To that you need to add machine learning and AI.

I think it is hard to come up with a unified set of tactics/strategy to be an
effective engineer at each part of this occupational spectrum.

For example, some engineers, while learning, try to specialize themselves in
an area while others try to become generalists. Both approaches can be valid
depending on the role.

Some engineers focus on applied science while others on theoretical science,
some others just on empirical knowledge, processes and techniques. Again, the
impact of this decision will largely depend on the role.

Then, prioritization is a double edged sword. To do what is perceived as
important is intuitively the right thing to do. But during learning it is
harder to recognize what is important. This is how many people end up
neglecting valuable learning.

------
nicodjimenez
Pretty good overview, although I was aghast when I saw that The Mythical Man
Month was missing from the book list. The Effective Executive is also a
timeless classic that's useful to anyone who manages anything.

~~~
snoman
It references the primary concept, and it also looks like much of the
information from MMM is already distilled into this - which is not hard to do;
MMM is a bit verbose if I recall correctly.

------
andendau
I love all of Edmond Lau's stuff. I accidentally found one of his Google talks
while trying to find something for my team when we started on fixing a
massively underscaled tech stack. I bought the book read it and shared it with
a few other engineers. Super valuable and a lesson I keep trying to teach to
our organization is how worth it is to build better tooling.

~~~
edmondlau
Thank you! It means a lot to me hear its impact on you -- stories from readers
are what keep me excited about doing this work.

------
rondysousa
(From the gist's account owner)

FWIW: I didn't produce the content present on this gist.

I've just copy-pasted it from somewhere over the Internet, but I cannot
remember exactly the original source. I was also not able to find the author's
name, so I cannot give him/her the proper credit.

~~~
lazyasciiart
This seems like something worth mentioning on the gist.

------
Blazespinnaker
Lot of very selfish anti team ideas here. Shipping requires doing grunt work.
That’s the person I want to work with and that’s the person I think is
valuable.

~~~
sethammons
Perhaps I misread the post. I thought there were several points about putting
your team first.

I've found that this can mean doing grunt work or it can mean reducing siloed
information by having them do grunt work. This is to say that helping the
team, helping grow yourself, and helping to ship product are not mutually
exclusive from each other.

------
KKKKkkkk1
I work on a team in which a few people adopted the strategy of doing 20% of
the work for 80% of the impact. That leaves the rest of us doing the remaining
80%. If the people doing most of the work are not getting the credit for it,
how is it going to play out in the long run?

~~~
afarrell
Why does that 80% need to be done?

~~~
jodrellblank
How else do you get to 100% of the work done?

~~~
afarrell
What I mean is that the number of pieces of work that _can_ be done is some
high multiple of the work that you can do. So find the projects that are in
the top 20% of impact by starting with “why does this need to happen?”

Of course if someone is only doing 20% of any given piece of work (say, never
writing tests or refactoring or doing code review), then yea, that is a big
problem.

------
foopod
Hang on.. What should I do first?

\+ The most valuable thing? \+ The riskiest thing? \+ The simple thing?

~~~
edmondlau
They're orthogonal dimensions. My fault that this isn't clearer.

Here's a simpler ordering of operations:

1\. Start with the most valuable, highest-leverage thing you want to focus on.
2\. Figure out what the riskiest bit of that thing is. Focus on de-risking it.
3\. When you're de-risking (or more generally whenever you're just doing that
thing), start simple. Beware of adding in unnecessary complexity.

------
jodrellblank
High leverage, compounding learning, exponential growth, high impact work,
high priority, fast paced, focus on value, larger time blocks, ever deeper
flow, prioritization for higher leverage, faster deployment, faster tools,
shorter iterations, skyrocketing productivity, scale impact beyond confines,
impact scaling, time saving, shorter loops, faster tests, shorter compiles,
mastered tools...

Does any of this seem a bit Shepard Tones to anyone else?

[https://www.youtube.com/watch?v=OsBanpBQj0k](https://www.youtube.com/watch?v=OsBanpBQj0k)

(ever-ascending-tones audio illusion)

------
swanson
My most useful insight/takeaway from the book was about leverage and what
activities you choose to do as you progress in your career: in six months you
could ship 1x engineers worth of output (or maybe 2x or 3x if you are really
great) -- or you could help hire and onboard 10 engineers and create 10x worth
of output.

Thinking more strategically about the most effective way to spend my own time
and energy was easily worth the nominal cost of the book.

~~~
yks
you are pretty much saying that the most effective way to be an engineer is to
not be one

~~~
jrs235
"The best code is the code you don't write."

------
bra-ket
A combination of software engineering and domain expertise makes for a really
effective engineer.

As an example - if you work as an software engineer in finance learn about a
few particular financial products at the same level or better than your users,
get a masters in finance, applied math, accounting and whatnot. This has the
added benefit of staying relevant in the market when you age, as software
engineering becomes increasingly commoditized.

------
yanilkr
This is effective nonsense. Based on my personal experience, effective
engineers I know do not follow a formula like this.

This looks like a list of how to be teacher’s pet. A superficial need to be
praised by others as effective only takes to “mediocre”.

~~~
yanilkr
I will try to elaborate without trying to insult anyone. It might be harsh but
I am sure the author can handle it.

First of all look at this sales copy of the book.
[https://www.effectiveengineer.com/book](https://www.effectiveengineer.com/book)

It looks like a weight loss e-book product designed to trick ambitious people
into impulse buying. It tries to build credibility by name dropping "google",
"facebook", "insert big company here" every other paragraph. Then there are
testimonials about how great the advice is from "LeaderLeaderLeader"
enterprise hierarchy pattern i.e people with big titles from popular silicon
valley companies.

Everything in that page is designed and optimized to make you buy the package.
For a price of 250$ you too can know the secrets of effective Engineers.

To sell this content first create and exploit an insecurity in jr.Engineers or
fresh job seekers in technology by saying they are not an effective engineer
unless they buy this book/package and read the content and then they too will
be part of the club and work at a big name brand company. Some people in our
work places are exceptionally good at social engineering and not so much in
actual engineering. The sales copy co-opted the "engineering" discipline to
sell some curated content. This looks much similar to team/company "politics".

I do not think people in "effective engineering" business do this. This is
certainly what people in content business do.

Now compare that to some other book for a contrast.
[https://basecamp.com/books/getting-real](https://basecamp.com/books/getting-
real)

Engineering is just like any other skill for e.g., like playing chess or piano
or swimming etc. You get better by doing it many times and failing often. To
be good at engineering involves many factors like genetics, discipline,
irrational love and passion for a particular domain, patience, exposure to
better ideas and better people. Even you are good at engineering, to be
effective at a company/market, you need to know the right people and have
right social and financial skills to get name and recognition.

Some how, effective engineering has become synonymous with what happens at big
name company teams which I think is very wrong. If you look at the real world,
once companies reach a bigger size, they stop doing effective anything. They
just buy other small companies which spend more time on making effective
products.

This content seems to be analogous to "founders at work" but a better title
would have been "engineers at the enterprise".

~~~
edmondlau
The perspective I'll offer is that good sales copy is also a skill, just like
engineering or any of the other skills you mention.

To be good at sales copy also involves many factors, like interviewing your
prospective customers, understanding what language they use to describe their
problems, listening for what dreams they actually have, addressing their
concerns by establishing credibility, and having a strong desire to help them
achieve their goals.

Good sales copy doesn't aim to "trick" people; it aims to show that the
product being sold will achieve the prospective customer's goals.

The reason I'm sharing this perspective is that many engineers do look down on
marketing and sales copy as something that's automatically "bad." And that
automatic association does them a disservice.

They write awesome code or build awesome products and features that could add
so much value to the world, but they then just expect anyone to automatically
see that value. They don't take the time to understand what their users'
problems might be, to share how what they built might solve those problems,
and to "market" their solutions. That mismatch of supply and demand ends up
being a missed opportunity, and sadly, this happens all the time.

~~~
yanilkr
Hope what ever you did works for you. I am probably not your prospective
customer. I found the whole sales copy very deceptive. You are selling
"Tactical Toolkit" to be effective engineer.

I understand your perspective about engineers undervaluing marketing and sales
skills, but I think it's an example of short term thinking. Credibility is a
currency, internet never forgets and I would never build credibility like this
because I do not know how this will limit my future possibilities.

------
apthnz
On the "read code written by brilliant engineers" point, as someone just
starting to learn Python, where would I find some?

~~~
ianbicking
Peter Norvig has lots of expository code that embodies lots of good design.

I find I like to learn the flavor of different kinds of code, but practical
codebases have so much stuff going on that it's not easy to find the
distinctive part. It would be great to see more people do expository versions
of familiar software and libraries.

~~~
svec
+1 Here's a link to Norvig's (self annotated!) github repo:
[https://github.com/norvig/pytudes](https://github.com/norvig/pytudes)

------
bharatmeda
I used to follow Edmond's detailed posts on Quora and that led me to buy his
book. I am yet to complete but like it so far.

------
Yokohiii
> Reduce Operational Complexity

If I hook everything into slack I have a simple interface that can cover and
reflect all my needs!

------
scrpn
I pwrsonally found that Refactoring often and unit testing don't play nicely
together. A huge refactoring lead to a lot of rewriting of unit tests since
they weren't compiling anymore. I was able to reuse test logic though.

------
vinceguidry
Does this violate copyright? It appears to be a clear derivative work. I ask
because this is something I'd love to see more of, but I'd be afraid of doing
myself because I don't want to get a C&D.

~~~
derekja
Is a book review a derivative work? The author of the book is in here politely
answering questions rather than crying "you copied!" so the nice summary of
his ideas must feel ok to him...

------
yters
Next big thing is finding out the non-algorithmic capabilities of the human
mind, and how to best utilize human in the loop.

------
noway421
The website is broken (sign up link not working) with ublock on. This is
really unacceptable for a landing page.

------
kapad
I just skimmed the article, but it seemed a lot like a rip off of "The
Pragmatic Programmer" to me.

------
ghrifter
Wow yet another Github Markdown README about how to be good at X or a list of
things of X

~~~
nicodjimenez
who knew that Github would be used for "10 ways to do x" type of articles

~~~
0xdeadbeefbabe
People who applied the lessons of 10 ways to read the future.

------
rb1
Not one mention of using a spellchecker, surely that's high leverage: quick
and easy, increases the quality of your output.

~~~
jodrellblank
surely commenting on the spelling of something you understand is not a high
priority, high leverage, effective use of your time?

------
bsder
> 80% of the impact comes from 20% of the work.

This simply has no basis in reality nor research and it pains me to see it
propagated.

The old VLSI design koan is: "The first 90% of the project takes 90% of the
schedule. The last 10% of the project also takes 90% of the schedule. 90% of
the engineering occurs in the last 10% of the project."

~~~
daxfohl
I was going to say the same thing. The 80 20 thing should be reserved to the
higher-ups and marketers deciding what to implement. At the development level,
zero value is provided by any less than 100 percent of the work. Too many
developers just focus on the 20 percent, leaving the project 4/5 unfinished.

~~~
gonzo41
Your assuming complete and correct requirements. 80 20 is great when you get
fuzzy reqs and have to make a decision.

