gophering on
HN Gopher Feed (2017-12-28) - page 1 of 10
Effective Engineer - Notes
314 points by signa11
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:
  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...
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
        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
      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
        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:
    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]
      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
  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.
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
    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
    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  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.
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.
    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
  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 ) 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
  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
  viraptor - 4 hours ago
  Anything written by Kenneth Reitz
  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:
  Facebook: Stripe: Airbnb:
  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:
    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:
        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
        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..
    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
    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.
    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
  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
      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
    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
    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?