HN Gopher Feed (2017-12-28) - page 1 of 10 ___________________________________________________________________
Effective Engineer - Notes
314 points by signa11
https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f___________________________________________________________________
[deleted]
henrik_w - 1 hours ago
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
idempotentWe 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...
edmondlau - 58 minutes ago
Awesome! Thanks for adding your notes to the discussion.
vinceguidry - 4 hours ago
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 - 1 hours ago
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...
[deleted]
nostrademons - 1 hours ago
"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.
brucephillips - 1 hours ago
"useless and unlikely to work" -/-> wrong
nostrademons - 1 hours ago
But without the benefit of hindsight, how do you tell the
difference?When I look at some of the giant wins of the last
major tech wave, often times the key factors in their success
were external events that happened after the formation of the
company. AirBnB benefitted massively from the housing bubble &
financial crisis (3 years after formation), which created a
large class of people who were desperate for income and whose
primary residence was their primary income-producing asset.
Uber had to try the idea multiple times before cell phone
batteries became good enough to run navigation continuously in
the car (2 years after formation), and took off because of the
publicity of getting sued by San Francisco. WhatsApp took off
after the addition of push notifications to iOS (~18 months
after formation) made it feasible to use as a messenger rather
than just a status update.All of these companies certainly did
things to influence their success, in particular having a
product on the market at the time the market changed to take
advantage of the product. But for most of them the product was
actually wrong in the sense that it was a complete failure in
the market until that market changed. Brian Chesky's fond of
calling AirBnB "the worst startup idea that actually
worked".It's like the formula for success = preparedness +
luck. This cribsheet does a good job at preparedness, but you
have to acknowledge the role of luck if you want to actually
capitalize on that preparedness, and being afraid to work on
the wrong ideas will often shut you out of ideas that require
some luck to work.
brucephillips - 1 hours ago
> But without the benefit of hindsight, how do you tell the
difference?See value missed by others.Do you have sources for
any of the success factors you described? My understanding
was that WhatsApp's success was largely due to focusing on
feature phones, increasing ubiquity.Regardless, none of this
changes the fact that OP is correct in saying that you
shouldn't work on the wrong ideas, of course.
nostrademons - 52 minutes ago
WhatsApp's push notification story is in the Wikipedia
page, though I think I'd read it in a news story profiling
Jan Koum after the
acquisition:https://en.wikipedia.org/wiki/WhatsApp#HistoryI
was wrong about timing though: it was only about 6 months
after WhatsApp was incorporated (2 years after they left
Yahoo though, so they might have been working on it
beforehand).
edmondlau - 59 minutes ago
I like the bottom-line perspective you provide at the end, of
"success = preparedness + luck."Preparedness is what we can
train ourselves for, and preparedness also has the effect of
making you more able to see and take advantage of
opportunities that come your way. And to someone who doesn't
know how much you've prepared, it appears that you're just
luckier.
brucephillips - 14 minutes ago
But these examples are cherry picked. Was Google lucky?
Oracle? Hotmail? Take away what luck might exist, and would
they not still be billion dollar companies?
shrimp_emoji - 1 hours ago
Like communism!
ringaroundthetx - 37 minutes ago
> 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 themIts not just ?interesting? there is also
happenstanceThere are going to be college kids working on ?XEM
Smart Contracts? for some ICO consultancy startup just because
they had more java classes across semestersAnd they will be
heralded as pioneering geniuses just because some fortune 500
starts looking for the word smart contract on linkedin
edmondlau - 1 hours ago
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...
nostrademons - 54 minutes ago
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
edmondlau - 37 minutes ago
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.
jedrek - 1 hours ago
> there are also many others who rode the wrong ones.My buddy
wrote a book on VRML.
makecheck - 4 hours ago
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.
Terr_ - 3 hours ago
The effect can't last long though: The long-surviving codebase
becomes such a mix of styles that it's more noise than signal,
and even the good code appears as just another local
inconsistency.
beager - 2 hours ago
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.
anichale - 3 hours ago
> coding styles enforced: bad changes to good code no longer
stick out like a sore thumb!I can see the benefit of being able
to identify smelly code immediately from poor code structure.
However, I think that coding styles enforce consistency between
good programmers who maintain their own coding style. A reviewer
should be able to discern code quality - even with compliant code
style - by how quickly it is to comprehend.
[deleted]
ghrifter - 5 hours ago
Wow yet another Github Markdown README about how to be good at X or
a list of things of X
0xdeadbeefbabe - 4 hours ago
What's so surprising about Markdown?
nicodjimenez - 5 hours ago
who knew that Github would be used for "10 ways to do x" type of
articles
0xdeadbeefbabe - 5 hours ago
People who applied the lessons of 10 ways to read the future.
jotux - 4 hours ago
It's just someone's notes from reading a book.
swanson - 36 minutes ago
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.
Blazespinnaker - 1 hours ago
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.
nicodjimenez - 5 hours ago
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 - 2 hours ago
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.
Yokohiii - 2 hours ago
> Reduce Operational ComplexityIf I hook everything into slack I
have a simple interface that can cover and reflect all my needs!
edmondlau - 5 hours ago
Hi! I'm Edmond, the author of the book. Happy to answer any
questions about my two-year journey in self-publishing the book.
gdubs - 5 hours ago
What was the process like? How much time did you spend relative
to other projects, and how did you incorporate your principles of
leverage into creating the book?
edmondlau - 4 hours ago
I also just remembered that I wrote this blog post a while back
on what self-publishing taught me about shipping products. It
also shares a few vignettes and lessons from my self-publishing
experience.http://www.effectiveengineer.com/blog/lessons-from-
self-publ...
edmondlau - 4 hours ago
In many ways, it was similar to building a startup product.I
quit my full-time job at Quora and spent ten months full-time
on the book (with bits of traveling). Like any other project, I
drastically estimated how long it would take. I estimated one
year; it ended up taking almost two. I finished the book while
working full-time at Quip.At times, it was an amazing
adventure. I loved going around Silicon Valley and interviewing
people like Mike Krieger or Sam Schillace to get their stories
and their most valuable lessons.Other times, there were also
intense periods of self-doubt. The first person I shared a
chapter draft with was my wife. She's also an engineer and by
default can give quite critical feedback. And, wow, did I feel
shut down after my first round of feedback. It's confusing! I
don't understand the point of this! etc.I ended up spending two
months iterating by myself on my next drafts to build up more
confidence before sharing with more engineering friends -- they
then really gave me the support I needed to feel confident
about writing the book. The experience was a great lesson in
how new ideas need to be nurtured, and you need to either find
supporters who will nurture that for you, or ask for the type
of feedback you want (which is what I now do with my wife). It
was also a valuable lesson in getting feedback sooner on your
project before you are too emotionally attached to feel
comfortable about asking for feedback.All in all, it's one of
my proudest accomplishments in my career.
0xdeadbeefbabe - 5 hours ago
I saw your google tech talk a while ago, and I really like the
concept of leverage even though I usually dislike this genre
https://www.youtube.com/watch?v=BnIz7H5ruy0 I think people get
too religious about effectiveness.I was wondering what you do
when you don't want to follow a list of good things to do? I
assume self-publishing was discouraging at times, wasn't it?
edmondlau - 4 hours ago
Two things I've learned since writing the book:1) It's also
important to align your energy levels and what you want to do
with your list of high-leverage tasks. When you're really
excited about doing something, even if isn't strictly the
highest-leverage thing you could do, you can actually end up
creating more impact because you do a much better job of it.2)
Sometimes what's needed is just a change in perspective about
things you need to do. I play with this a lot in the leadership
coaching that I do. For example, I hate responding to emails
because processing them all feels like a chore. But if I
reframe responding to emails in my mind to be hunting for gems
that might lead to new opportunities, I'm much more likely to
go through them (at least the ones that are gems).And oh yes,
there were definitely discouraging points. The story about
early, negative feedback from my wife (that I posted in another
comment) was one.Another is that ten months into book writing,
around the start of 2014, I started feeling a sense of intense
FOMO from reading Hacker News. Stripe had raised a valuation
round of over $1B, and WhatsApp had been acquired for $16B.
That led to moments where I would wonder "What in the world was
I doing writing a book?" and "When will I ever finish?". I had
just finished a first draft, I wasn't sure how rewarding
financially the book would be, and I was feeling like I had
removed myself from the startup game.That led me to start
looking for jobs, which quite fortunately, also led me to my
current role at Quip. So everything worked out in the end.
mzzter - 4 hours ago
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.
barrkel - 3 hours ago
Leverage directly implies multiplication. Leverage, the
physical concept, multiplies force or torque (rotational
force). The analogy applies finance: multiplying your
profitable strategy with borrowings to multiply the gains. The
analogy also applies in software: multiply the uses of your
code to increase the value it creates.
edmondlau - 4 hours ago
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.
mzzter - 2 hours ago
Thanks for your response, I understand it better now. Sorry
for what must have seemed like a stupid question.
ashwinaj - 9 minutes ago
Hi Edmond, your book was great and I enjoyed reading it!I do have
a question on your topic on high leverage work; as a startup how
would you know what is high leverage work? You have talked about
various tooling projects at Quora which turned out to be duds,
but how would you know that beforehand without trying? I guess
the same applies to your book...
brucephillips - 2 hours ago
Have you read much Drucker? You cover some of the same ideas.
edmondlau - 2 hours ago
Yep! I've read The Effective Executive. One of my big
motivators for writing the book was that there were all these
great ideas that were encapsulated in business books or
personal improvement books, and very few books that would tie
them back to engineering. That's the gap I wanted to fill.
brucephillips - 2 hours ago
Great. Though one of the complaints I have here is the same I
have with Drucker, and the same that others have given:
"Impact" is ill defined.
edmondlau - 1 hours ago
Your observation is a key reason why taking the time to
define your impact and to measure it is so important. As
Drucker says, what gets measured gets improved.In business
contexts, your engineering impact generally ties back to
the business value you create (i.e. revenue and profit). If
there is already some model for translating your area of
work to revenue (e.g. increase users -> increase revenue,
reduce fraud -> increase revenue) then that can also give
another proxy metric to optimize for. So for example, when
working on Google Search Quality, we would often just
optimize for long clickthrough rates, knowing that
strategically, the ads team would take care of turning
returning searchers to revenue.It gets harder when you're
working on areas like bigger bets (where you can have high
impact but it is unknown for a long time) or in trying to
understand an infrastructure investment in terms of its
business value to the company. There, it may be sufficient
to just know that something is of strategic value and then
measure your impact in terms of those strategic goals.
foopod - 2 hours ago
Hang on.. What should I do first?+ The most valuable thing? + The
riskiest thing? + The simple thing?
jrs235 - 1 hours ago
You should work first on the riskiest part of the [guesstimated]
most valuable thing.Edit: [guesstimated]
edmondlau - 55 minutes ago
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.
bsder - 2 hours ago
> 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."
joshuamorton - 2 hours ago
Yes it does. The 80/20 rule cleanly fits an exponential
distribution. The assumption is then that the work to implement
any given feature in a project follows an exponential , and this
appears to hold reasonably true in practice.
bsder - 1 minutes ago
All you did was move the question--why does this thing fit an
exponential distribution?The birth project of agile--the
Chrysler Comprehensive Compensation project--should have been a
wonderful example of the 80/20 rule. They implemented the most
important chunks of the project and got about 80% of the cases
correct--totally awesome.Except--it wasn't. The value of the
project was in handling all of the exceptional cases. And
those cases started consuming VAST quantities of resource.80/20
only works when you can interchangeably wipe out tasks without
affecting the result. Most engineering is NOT like
that.Analyzing the soil may not take very long when building a
bridge, but you can't skip it.
[deleted]
inetknght - 5 hours ago
> Optimize for LearningAn 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.
[deleted]
snoman - 2 hours ago
> ... at the end of the day a job is about money.This is short-
sighted. A job is what you make of it - you can get lots of
different things out of it. Otherwise pro-bono work,
internships, etc. couldn't exist. If all you're in it for is
the paycheque in 2 weeks time, then that's all you're likely to
get out of it.When you look at a career as a whole - from both
sides of the relationship - then it is beneficial for both you,
and your employer, for you to increase the value that you
provide to your employer. That can mean learning more so that
you can be more efficient, do more (volume), do more (variety),
do higher valued things (ie. via promotion).Also, you're not
wrong that you can learn in a big 'boring' corp but the
conditions have to be right for it to happen, and those
conditions are often more prevalent in companies that have
knowledge or skills gaps - which is more often the case in
smaller organizations (doesn't have to be a startup, could be a
historically-under-funded/under-recruited IT group in a well-
established corp).
brucephillips - 2 hours ago
Please don't insult.
crispyambulance - 4 hours ago
> ... If one party's not on board, then it's going to end up
being a problem. Yep, that's why he says prominently: "Change
jobs if you have to."Idealism, IMHO, acts as a motivator and
helps folks get through the obstacles that inevitably block
progress.
whistlerbrk - 5 hours ago
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 - 2 hours ago
Challenging an idea is not a "take down".
bharatmeda - 3 hours ago
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.
apthnz - 4 hours ago
On the "read code written by brilliant engineers" point, as someone
just starting to learn Python, where would I find some?
nemild - 4 hours ago
Lots of different ways:- Find a function call you're making in a
library and see how it works- Look through the top python
libraries (see https://github.com/vinta/awesome-python ) and pick
a few of the simpler ones to flip throughFor reading code, some
things that can be useful:- Flip through test suite and get tests
running; then break some tests to see what's happening- Diagram
out code on a piece of paper (file structure, data structure,
stack trace for a popular call)- Discuss implementation with
friends- For certain files, it's often valuable to rewrite
yourself
ianbicking - 3 hours ago
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.
viraptor - 4 hours ago
Anything written by Kenneth Reitz https://github.com/kennethreitz
edmondlau - 4 hours ago
If there are engineers you highly respect on your team, their
code is a great place to start.Otherwise, many top tech companies
now open source software that they've written internally,
oftentimes with their own websites. And there is also a growing
trend for them to actually maintain the software they open source
as opposed to just throwing it over the fence.Think of companies
that have a strong engineering brand, and then just search for
what open source software they're released. Pick whatever seems
most aligned with your interests.Some examples:Google:
https://opensource.google.com/projects/list/featured?languag...
Facebook: https://code.facebook.com/projects/#backend Stripe:
https://stripe.com/open-source Airbnb: http://airbnb.io/projects/
m3kw9 - 4 hours ago
Maybe find a very well received project on GitHub and check out
the author and see some of his code
IronKettle - 5 hours ago
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
" 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.
jakevoytko - 5 hours ago
This is a mindset that I encountered a lot from managers and VPs
at Google. The premise is that the best way to improve one's
incremental technical contribution is to improve an entire
team.If you bust your ass for a year and improve your own
technical chops, you might be able to implement stuff 10% faster.
Instead, you could help a team of 30 people to produce 10% more
work. This is achievable from my anecdotal experience, but
citation needed. At this point, you can throw your 10%
incremental improvement out the window because now your
incremental engineering improvement is 10% of a 30 person team,
or 3 engineers. Now imagine you organized a department of 300
engineers to develop the right mix of infrastructure, forward-
looking projects, and core projects such that the organization
runs and grows efficiently. Now your incremental technical
contribution is so much larger than the initial 10% that it's
laughable.This doesn't have to be limited to management, which is
where I think the Google VP perspective falls a little flat. You
can do this kind of work through pure technical contributions. I
think managers write about this kind of leverage more often, but
it can come from any kind of organization. A core library or tool
has a massive impact, because it's reusable past the bounds of
your team. Maybe you're change isn't 10% distributed across 30
people, but you could improve 3000 people by 1%.
IronKettle - 4 hours ago
Yeah, and I think this is where it's fair for the author to use
terms like "leverage", since you're effectively multiplying
force.To be fair, though, I don't think having that team-first
mentality (where you're focused on improving the team's
productivity as opposed to your own) necessarily implies
pervasive "management thinking" (for lack of a better phrase)
or even soft skills. I imagine we can all think of teams where
that isn't the case.
edmondlau - 5 hours ago
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/...
IronKettle - 3 hours ago
> Unfortunately, almost all computer science education nowadays
focuses on pure technical skillsI'm not sure I'd really call
that unfortunate. CS education isn't about making you a more
well-rounded person: It's about giving you a basic education in
Computer Science.Similarly I don't really lament that CS
programs don't have a course in basic financial literacy, even
though it would be incredibly useful.These are really topics
that should be addressed much, much earlier (empathy in
particular is something we should start teaching children as
young as possible) and should be mature ideas by the time
people reach college-age.> 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.To mirror the
other comment, I hate to say it but if you're a software
engineer at Google you're likely already a "top"
engineer.You're trying to explain what differentiates the top
0.1% from the top 1%, but I'm not sure it's a super useful
distinction for the other 99%. For them, investment in hard
skills might actually be considerably more fruitful (and land
them that Google job in the first place).Maybe not, I'll admit
I could easily be wrong on that.
edmondlau - 3 hours ago
There's for sure a tricky balance on what fits into a CS
education.I remember when I was at MIT (oof, over a decade
ago), many project-based CS courses where students were just
put into teams and expected teamwork to just happen.
Sometimes people got along, and the project would go fine.
Other times, not so much.I know I certainly wasn't very well-
equipped to handle tension or to have hard conversations
about fair distribution of work. And back them, I ended up
just avoiding them. Knowing what I know now, even a single
lecture on tools for more effective teams or for having hard
conversations or giving feedback would have made those
projects SO much more valuable in terms of being learning
experiences.Given that effectively using your CS education
will involve collaborating with other people to some degree,
I do believe that giving more emphasis to the non-technical
skills that play a big role in your career would have a
hugely positive impact.
IronKettle - 3 hours ago
> I know I certainly wasn't very well-equipped to handle
tension or to have hard conversations about fair
distribution of work.I guess my point is more that primary
school really should've prepared you for this: Group
dynamics and how to handle these "group tensions" is more
of a basic learning skill that we should be developing very
early on.I'm not arguing that this is a useless skill to
teach, more that it's far more expensive and much less
effective for MIT to be teaching you these skills and not
MyTown elementary/middle/high school.
shrimp_emoji - 1 hours ago
Why can't the managers with business backgrounds be the
social engineers expertly manipulating the asocial
software engineers? I thought that's what they were for.
Distribution of labor!
IronKettle - 37 minutes ago
I think for me it's more like:One of the fundamental
duties of a middle manager is to worry about group
dynamics, team effectiveness, group communication, etc.If
the engineers are now doing all of that as well, what's
middle management doing?("Nothing, same as always" is of
course the snarky answer)
grandmczeb - 3 hours ago
I can?t speak to this particular study, but as a former Google
employee, I would take any of the social ?research? done at
Google with a massive grain of salt. Very little is peer
reviewed (or even externally available) and the stuff I looked
at internally is not even remotely rigorous.Additionally, the
results that make it to the media get way exaggerated compared
to the actual underlying study. This is compounded by the fact
that Google picks and chooses what it publicizes, so what
you?re seeing has a huge PR/political filter.
kbenson - 3 hours ago
> Unfortunately, almost all computer science education nowadays
focuses on pure technical skillsAssuming by computer science
education you mean the actual classes within that major, I
don't see this as a problem. I didn't take CS classes to learn
interpersonal relationship skills. Other college classes and
the college experience in general does help with that though.If
talking about tech programs, I also think that isn't
necessarily something they can or should focus too much on, as
that's not their focus. The assumption is you have that part
already figured out. If not, go through a course that focuses
on that in addition, I'm sure you'll get a better education in
that topic that way. It probably is appropriate for them to
stress it's important though, even if they don't offer much in
the way of rectifying it.Or, spend a lot of time on self-
directed self improvement in one or both those areas. The
resources and programs exist for that as well.> and hiring
interviews at most tech companies also focus on the technical
skills.I agree on this. Companies should hire people that will
function within their system. Hiring the smartest guy from
MIT's class of 2017 sounds all well and good, but if they can't
function well with your existing 100 employees and they leave
after a year or two (or worse, they cause a few other people at
your company to leave every year causing high turnover), the
chances of them somehow making up for that are probably
extremely low.
sbov - 2 hours ago
Our CS program had a "basic communication" class, where you
learned to write basic reports, memos, emails, your resume,
etc. The final project was investigating some piece of tech,
writing a 30 page paper on it, and presenting your findings
to the class. Other CS teachers were invited to drop in
during the presentations too.Supposedly they added this after
receiving feedback from industry that the biggest problem was
that their graduating students couldn't properly
communicate.Altogether it felt pretty appropriate, since it
was still focused on CS related concepts.
robotsonic - 4 hours ago
>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 - 3 hours ago
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
brucephillips - 2 hours ago
Do you have any ideas on how companies can better assess
soft skills during interviews?
edmondlau - 1 hours ago
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.
fernandopj - 3 hours ago
I strongly agree with this analysis. It's already a
population with strong STEM abilities, it should suffer from
some sort of diminishing returns after an already high hiring
standard on a company well-known for hiring only top
students.It's like conducting an analysis on skills of all
F-1 drivers, and what differentiates champions from remaining
pilots. I'd expect a lot of mindset-related and soft skills
to appear as key indicators, and "driving abilities" to have
a minimal gap between drivers.
mastratton3 - 3 hours ago
This makes so much sense and frequently overlooked. I find
even in other areas (such as sports), what makes someone seem
really impressive generally isn't what is actually
important.A dumb example is from cycling, people frequently
over-practice the ability to sprint at the end of a race but
what is really important is the ability to conserve energy
throughout the race... Really dumb example, but I think it is
somewhat similar.
brucephillips - 2 hours ago
Another likely bias is that success is probably measured by
peer review, and peers are more likely to overvalue soft
skills.
rifung - 1 hours ago
Is there any evidence this is happening? I work at Google
and as a lower level engineer more often than not wish some
of the leads had better soft skills which makes me think
they're not emphasized nearly enough in terms of promotion,
which is at least one measure of success.I believe
promotion committees try to see measurable impact, which at
least to me sounds like soft skills unfortunately don't
help much..
[deleted]
ssivark - 2 hours ago
> Project Oxygen shocked everyone by concluding that, among the
eight most important qualities of Google?s top employees, STEM
expertise comes in dead last.And yet it seems to me that the
typical software/technical interview process emphasizes #8 more
than the other seven. Maybe like the drunkard searching for
lost keys under the lamp post. Quite sobering.
Silhouette - 1 hours ago
There are quite a few implicit assumptions here that make it a
dubious example, though.For example, there's an assumption that
what works well at Google would work well for other tech firms.
And yet Google is in the rare position of having gained so much
from its early golden goose that success in terms of producing
viable, valuable products and services has been almost
irrelevant among most of its workforce for most of its
existence.There's also an assumption that the staff at a big,
famous organisation like Google are generally better than those
elsewhere, and therefore that being successful in such an
organisation is something to be emulated. Working at one of the
Big Five seems like a default aspiration for some parts of the
tech world, and there's definitely an element of hero worship
for those who have made it. I can't help wondering whether that
is simply because of the amount of money they can throw at new
starters in the hope that they attract some of the best people
among the catch.What I see here is that if you're in an
environment where being good at walking the walk isn't always
necessary, talking a good talk becomes the path to recognition
and success. While this is almost certainly true, anyone who's
ever observed the phenomenon of middle management could have
told you that, without reference to any specific industry. What
it doesn't tell us is how much being able to walk the walk
matters in most other environments where it is necessary for
success.
marcosdumay - 2 hours ago
The prase "success of people working at X is correlated with Y"
has about the same meaning of "X recruitment process is weakest
on select Y".
quadcore - 4 hours ago
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."That is describing what it takes for an
individual to be successful in a group of men. I think Im safe
in saying this is like that since the dawn of men. Specifically
here, it happens in organisations big enough so that people's
actual productivity is unknown.Innovation though generally
doesn't happen in such environment.
rifung - 1 hours ago
By group of men are you using that like group of people or
are you saying it's specific to males?
quadcore - 1 hours ago
I meant human
brucephillips - 2 hours ago
What about this is specific to men?
quadcore - 1 hours ago
I meant human.
[deleted]
DoreenMichele - 2 hours ago
among the eight most important qualities of Google?s top
employees, STEM expertise comes in dead last.I have a lot of
those soft skills. But no one is going to hire me as an
engineer because I don't have the coding skills.It comes in
dead last because you have to have high level coding skills to
get your foot in the door. Everyone has that. Getting ahead in
that crowd means having others assets on top of being a good
coder.It is a little like saying "Height doesn't matter for
success as a basketball player. As long as you are at least
6'6", what matters are these other attributes." Yeah, sure,
cool. It isn't a strong differentiator for the in crowd
because you can't even join the crowd without it.
avprpl - 1 hours ago
I agree. If everyone at some company meets some bar for
expertise, then differentiation among peers comes elsewhere.
barrkel - 3 hours ago
This is the article that argues that for people in the top 1%
of STEM expertise, STEM expertise isn't the distinguishing
factor.Frankly, it would be surprising if it was. If you've
topped out that tech tree, most of your performance variance
will come from other areas where there's more, uh, variance.
dejawu - 1 hours ago
This frustrates me greatly. Many "engineering management"
professors will show Dilbert strips and Office Space memes, then
immediately fall into using the same kind of vocabulary that
these works mocked.(Recall that Initech in Office Space had
"Hawaiian Shirt Fridays" - one of the core features of this
manager-speak is to try to appear human and relevant as much as
possible.)
dualogy - 1 hours ago
> You can see the author using the word "leverage" here
repeatedlyOr maybe devs/engineers are just growing more eloquent
than used to be? "Leverage" is truly the most intrinsic essence
of everything engineering/developing. Reducing man-days,
eliminating manual efforts, extracting infinitely reusable
abstractions, code that emits+evals code .. I could go on and on
and on --- hard to find a more sufficiently terse umbrella
moniker that captures the mindset behind it all than "leverage"!
IronKettle - 1 hours ago
I've heard multiple similar arguments in favor of the word
"synergy" or "paradigm".Let me turn the tables: Why is
"leverage" acceptable to use but "synergy" engenders scoffing?
brucephillips - 1 hours ago
Fashion
dwaltrip - 56 minutes ago
The terms themselves don't induce scoffing, it is the
specific usage patterns over time, which then becomes
associated with the term, devaluing it as a meaningful way to
communicate.Synergy was frequently used in a mindless, vague
way by individuals who wished to appear in-the-know. Thus, it
was devalued, as people actually in the know did not want to
be mistaken for those those who didn't know how to use the
term.This dynamic usually happens with high-level
abstractions that have much complexity and nuance, as it is
difficult to assess if the term is being used in a meaningful
way. "Paradigm" and "synergy" are good examples of such
powerful yet tricky concepts prone to misuse and
buzzification.Some philosophers say that the meaning of a
word is determined purely by its usage. In this view, a word
like synergy loses much of its meaning, as it is commonly
used in such a jumbled and unclear manner.
IronKettle - 41 minutes ago
> Synergy was frequently used in a mindless, vague
wayAgain, I'm really not trying to put the author down here
- but "leverage" is a term that can very easily and often
is used in a mindless and vague way. Not always, of course,
in the same way that "synergy" can absolutely be used
properly.Still, it would be extremely easy for me to
mindlessly posit whatever I want as "high impact", or at
the very least "minimal time investment". "Minimal" and
"high impact" are inherently subjective phrases (minimal
compared to what? high compared to what?) and without a
baseline are effectively useless.So, I guess I still don't
see a huge difference between "synergy" and "leverage" in
terms of vagueness. And if vagueness exists, mindless usage
is pretty soon to follow.
dwaltrip - 36 minutes ago
I agree "leverage" is further down the spectrum of being
prone to meaningless usage (than most words), but I don't
think it is as far as "synergy".It's a more precise
concept: put x in, get more than x out. The more you get
out for each input of x, the greater the leverage.Synergy
is the idea of "greater than the sum of the parts", which
is a useful concept but much more nebulous, in my
view.Not that this is a particularly important debate :)
dualogy - 27 minutes ago
I'll take that table-turn! Well my intuition here goes like
so: think back to the first moment in life you heard about a
"lever" --- then "synergy". Chances are, the former was an
illuminating childhood moment when simple levering was first
powerfully demonstrated to you by a peer or parent, and
tickled your inner engineer/fixer-upper/tinkerer. Chances
are, no comparable "engineerish" moment occurred when you
first encountered the latter.
Waterluvian - 2 hours ago
I'm first in line to make fun of the title "scrum master" and
other nonsense. But the things that have crept in seem to have
because they work.I'm results driven. I don't care who comes up
with what or what it's named. If it works, I'm on board. If it
doesn't, I'll lambast it.
FLUX-YOU - 2 hours ago
>But the things that have crept in seem to have because they
work.Keep in mind that things like Agile and Scrum might have
had buy-in from team members because a team member adopting it
wasn't as high of a cost as the same team member leaving the
job. You might be able to object, but you'll probably be
overridden.There's some amount of reprogramming that happens
there to keep the team cohesive, so people might begrudgingly
adopt new habits. So in those cases, "it works" is barely
sneaking in because everyone was forced to make it work.It's
not as easy to prove/disprove as more objective things like
program performance, size, or correctness. There's a whole lot
of flavors of "it works" out there.
goialoq - 2 hours ago
Many adults have an aversion to new words. Foods too! Over time,
they grow accustomed.
pm90 - 5 hours ago
I think you're being a little too pessimistic, although I do see
where you're coming from. Technical jargon and vocabulary aren't
created out of thin air: they are meant to efficiently and
effectively convey certain facts and behaviors. Sometimes
(perhaps many times?) there are co-opted and misused by certain
people (many times managers, since they're further away from
actual coding).The thing about engineer being a good teammate: I
don't think it is about extroversion as much as realizing that
modern software systems are very non-monolithic and thus require
cooperation among many different services to work effectively.
This means that the days when a person could write the entire
thing by himself/herself is over, and a lot more co-operation is
required among engineers to design and build effective systems.
That cooperation requires a certain amount of communication
skills (apart from stellar technical skills), but it doesn't mean
that you have to be an extrovert.
Silhouette - 1 hours ago
This means that the days when a person could write the entire
thing by himself/herself is over, and a lot more co-operation
is required among engineers to design and build effective
systems.At that point, you're not really talking about being an
effective engineer, though. You're only talking about being an
effective engineer in a large organisation working on a large
project.I know plenty of people in the freelancing and startup
world who can build and maintain very significant systems
single-handedly. Take someone with the skill and experience to
do that, give them a free hand in choosing whatever tools and
processes work for them to get a good job done, and remove the
overheads of micromanaging this and co-ordinating that. It's
not unusual for that person to outperform an entire team
working for a competitor under more traditional constraints, or
for a small number of such people who can keep the overheads
down to outperform a more traditionally organised but mediocre
team an order of magnitude larger. Of course these people also
need good soft skills, but those are not why they are so
productive.
meddlepal - 4 hours ago
I think often lost from the whole introversion vs extroversion
debate is that:1. It's not a binary. It's a bell curve where
many people fit near the middle and some are extreme outliers
in either direction.I know personally that I am an introvert,
but I confuse a lot of proclaimed extroverts who mistake me for
being extroverted because I have a fairly gregarious and
willing to try anything once personality.2. Introvert /
extrovert really has nothing to do with communication skills
except that introverts appear to be bad at verbal communication
usually because that skill isn't as practiced as extroverts.
But good verbal communication is totally a developable skill
rather than something innate to a person.
wallflower - 3 hours ago
> That cooperation requires a certain amount of communication
skills (apart from stellar technical skills), but it doesn't
mean that you have to be an extrovert.There are many people
(including myself) who can operate quite successfully in the
text-based world (Slack, email) and collaborate that way.I
think Slack (and other tools like it) helps the introvert be a
more active participant or even a leader in certain technical
discussions. Most especially, the ones where the servers are
melting down.
IronKettle - 3 hours ago
That's very true! I wasn't really thinking about Slack/etc.
when I made that statement. Excellent point.
IronKettle - 4 hours ago
> That cooperation requires a certain amount of communication
skills (apart from stellar technical skills), but it doesn't
mean that you have to be an extrovert.Yeah, and I realize it's
a spectrum and not a binary thing. My point was more:If we use
the simplistic, trendy definition of introversion/extroversion
as "do you gain energy having conversations or does it require
energy?" and then say that regular conversations are an
extremely important part of doing modern development work, I
think it's fair to say that you're implicitly selecting for
extroverts.And again, I don't really put a judgement on that. I
think it's fair to say "regular conversations are required to
be successful as a software developer." I'm just noting the
shift (as you've also done!).
guelo - 3 hours ago
I don't think so. Leverage has a precise concrete meaning in this
article. We shouldn't avoid a descriptive accurate term just
because it's for an abstract higher-order concept.
brucephillips - 2 hours ago
"Synergy" is a precise term as well.
IronKettle - 3 hours ago
> Leverage has a precise concrete meaning in this article.Er,
not really. From the article:> Leverage = Impact Produced /
Time Invested"Impact Produced" has a precise, concrete meaning?
barrkel - 3 hours ago
Sure. For software, it might be reuse of a component. Reuse
leverages existing code. This is precise, unambiguous, and
frankly uncontroversial.
IronKettle - 3 hours ago
> it might be> This is... unambiguous,:)
lazyasciiart - 4 hours ago
As far as I'm aware, 'growth mindset' comes from
education/psychology with Carol Dweck, not from management - did
I miss something?
IronKettle - 3 hours ago
Not the first or the last time management has co-opted terms
from academic fields :). Social psychology is especially ripe
for this.See also: "Paradigm shift" was coined by a physicist
to talk about scientific revolutions, IIRC.
simonbc123 - 4 hours ago
I do have an opinion on the phenomenon. There are more and more
mediocre engineers who need this sort of thing in order to
justify their existence.Once the majority is mediocre, it becomes
accepted practice.
barrkel - 3 hours ago
"Leverage" has real meaning. Another word for it that you might
be more familiar with from software is "reuse".Reuse is leverage.
If a piece of software (function, class, module, service, tool,
whatever) is used for 1 task, it's not leveraged. If it's used
for 10 tasks, that means the creation of the reused thing had 10x
leverage: working on that reused thing created 10 times more
value than working on something that's only used once.It's not
quite that straightforward as everyone knows, there are costs to
reuse (abstractions (both lowest common denominator and leakage),
more dependencies, higher maintenance costs owing to risk of
breakage of multiple clients, etc.). But the leverage is very
often real.
halter73 - 3 hours ago
What's your point? Synergy has real meaning as well. The
problem is when concepts like leverage or synergy become goals
in and of themselves. That might be something you'd expect from
someone who's read a lot of management books, but you'd expect
engineers to see these as means to an end.
ralmeida - 2 hours ago
While I don?t advocate the use of these terms in every
situation, it?s hard to have all ends in mind and to
carefully choose which tool should be applied to each end.
That may be why these properties are used as goals. Easier to
spot, easier to reason about. Basically, they are heuristics.
yanilkr - 5 hours ago
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?.
eitland - 5 hours ago
Also it comes off as a way to build a career at the companys
expense.
goialoq - 2 hours ago
Which parts hurt the company?
ashwinaj - 5 hours ago
You're forgetting the fact that the company is also building
it's "career" off your's too.Don't believe me? Any invention
that you have created at your workplace (patents etc.) is
always held by your company, not you.
eitland - 4 hours ago
That's the deal though isn't it?They pay me real money - I do
real work for them.
ashwinaj - 4 hours ago
So you're okay with the fact that they are kinda-sorta
exploiting you (by not including you as a co-patent holder)
but have reservations on employees utilizing company
resources to further their career?That seems like a really
raw deal to me. You might argue that you are "paid" to do
this; not really, you can just coast on 9-5 and draw the
same (or in the same ballpark) paycheck as someone who is
busting his behind to invent something. Also when there is
downsizing you might think that contributions is the only
thing that matters, but it is demonstrably not (I'm
speaking about regular companies not a small startup).
barrkel - 3 hours ago
You expend labour; they build capital. The capital you
build produces returns long into the future, but you don't
own any of that future income stream. Sooner or later, your
sharpness and skills will decline, and your labour will be
relatively worthless. The capital you helped build will
continue to be valuable (presuming you did a good job).It's
a poor deal if you're in a competitive market where there's
another schmuck willing to do your job for just as cheap as
you do it. But if you have pricing power, you'd be a
complete fool not to either charge substantially more, or
demand some ownership.
dudul - 4 hours ago
What do effective engineers do then? Based on your experience,
what practices do they implement?
tw1010 - 4 hours ago
There are good ways and bad ways to interpret the book. Just
because good engineers have historically not lived their lives
according to these particular buzzwords, does not mean they
haven't implicitly incorperated similar, analogous, strategies. I
would be surprised if Linus Torvalds and Peter Norvig and the
like didn't use concepts like prioritization, investing in tools,
and some similar idea (though not necessarily expressed in that
way) to the 80/20 rule. Why should it matter from which culture
productivity buzzwords originate from?
brucephillips - 2 hours ago
Perhaps rather than spew vacuous insults, you could describe
specifically how effective engineers differ from the descriptions
in this post.
plandis - 2 hours ago
What do effective engineers do then?