Effective Engineer – Notes
gist.github.com
gist.github.com
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.
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.
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.
https://en.wikipedia.org/wiki/WhatsApp#History
I 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).
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.
I'm currently working on commercialising a pharmaceutical manufacturing monitoring device[1], based on the work from someone's PhD.
Would saying "success = preparedness * luck" be better?
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...
My buddy wrote a book on VRML.
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.
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.
> how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.
“For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” CVS!!!
When you are working on any idea, there's a temptation to be a visionary about your product's impact. But nothing good comes out of this feel-good bullshit. It's better to focus on solving meaningful problems that exist today, rather than being hopeful that they will become relevant tomorrow.
More of a personality thing. If you would pitch Dropbox or Facebook to me today, I would consider it bullshit just like back then. Nice little niche maybe but certainly no Unicorns. Who would put sensitive personal information into the cloud?! Obviously not much of a market.
Really? If you don't have that filter you'll be prey for every investment scam that comes along.
Its not just “interesting” there is also happenstance
There are going to be college kids working on “XEM Smart Contracts” for some ICO consultancy startup just because they had more java classes across semesters
And they will be heralded as pioneering geniuses just because some fortune 500 starts looking for the word smart contract on linkedin
It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated.
We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own <x>" or "growth mindset". You can see the author using the word "leverage" here repeatedly in the same way that we often chide managers for using words like "synergy".
Interestingly the conversation around "effective engineers" has also shifted to really de-emphasize that technical ability - the best engineer is a good teammate, first and foremost (and I think a not-so-subtle implication also is that a good engineer is mostly extroverted as well). In the past decade or so, it seems like the "effective engineer" has become one who straddles that line between management and technical ability.
I don't really have an opinion on this yet (I think there's good and bad, as with most things), but it's just fascinating to watch.
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.
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.
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!).
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.
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.
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%.
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.
Instead of YOU, as head of household putting more hours to solve Home chores/issues, if you teach other 3 members of your family how to solve issues/do chores , you get 3X return .
An example is online shopping for Home: Instead of you spending time for all the research each time, teaching family members, you can achieve leverage .
> 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
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/...
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.
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
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.
Be careful with this approach. If you're not paying candidates for their interview time, you're not allowed to use their work. Big companies go to great lengths to demonstrate that the entire interview is for the purpose of a hiring decision and nothing more. This is to limit liability. Your approach is very dangerous for your company and if an unhired candidate's idea shows up in your product, even if you arrived at that result independent of the interview, the candidate has a strong case against you in a lawsuit.
If you're doing interviews like this, be sure you've discussed all the nuances with your company's lawyers.
Or do you also want something where all your interviewers will give the same candidate the same score, and that's robust against being gamed?
The former is easy: "Tell me about a time you helped a colleague improve their performance", "What do you think makes for a good coach?" etc etc.
The latter? I've never seen a convincing way of doing it.
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.
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.
I believe promotion committees try to see measurable impact, which at least to me sounds like soft skills unfortunately don't help much..
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.
I'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.
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.
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.
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)
Assuming 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.
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.
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.
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.
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.
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.
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.
Worth keeping in mind that this is true for the culture/environment within Google, not universally. Different companies have different cultures, and the above actually makes me more cynical about the culture within Google. If two people have competing ideas for a engineering solution/implementation, is the winner going to be the one with the best technical merits, or the one best at office politics? Judging from the above study, it seems like Google's culture is less meritocracy-driven and more politics-driven than people think.
Once the majority is mediocre, it becomes accepted practice.
See also: "Paradigm shift" was coined by a physicist to talk about scientific revolutions, IIRC.
Er, not really. From the article:
> Leverage = Impact Produced / Time Invested
"Impact Produced" has a precise, concrete meaning?
> This is... unambiguous,
:)
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.
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.
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.
(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.)
Or 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"!
Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?
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.
Again, 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.
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 :)
- Optimize for learning
- Invest in time-saving tools
- Shorten the debugging loop
- Don’t sprint in the middle of a marathon
- Recovery over prevention
- Automate mechanics, not decision making
- Make batch processes idempotent
We read it in the book club at work a year ago, and I wrote a longer review of it here: https://henrikwarne.com/2017/01/15/book-review-the-effective...
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.
http://www.effectiveengineer.com/blog/lessons-from-self-publ...
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?
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.
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.
Less easily communicated ideas often need at least a demo. Dropbox is one example.
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.
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...
In some sense, it might actually be easier to tell at a startup because what matters at a startup is growth. That can be growth of revenue (if you already have a product to sell) or growth of users (if you need traffic first to sell, e.g. Quora).
The highest-leverage work would then be the things that most directly lead to that growth. Sometimes, this will require talking with product managers or salespeople or users to understand what the biggest accelerators or roadblocks would be. So, for example, at Quip, I looked at data on how the product spread within teams and organizations, developed engagement metrics around it, and then built features to move those metrics.
Working on some projects that end up failing is perfectly normal. What's important is to front-load as much of the risk as possible and to be explicit about the hypotheses required to make a project successful so that you can validate them early and, if necessary, change course.
That's where some of the projects we worked on at Quora failed (e.g. topic groups, an infrastructure rewrite) -- we let ourselves be overly confident about what we knew and didn't invest the time to sanity check our hypotheses.
For my book, validation played a huge role. Even before I started writing my book, I had written engineering-related answers on Quora for over two years and started to get a sense of what resonated with readers. That helped me build confidence that there would be demand for something in this space. Continued feedback and reviews during the writing process built on that confidence more.
Humans' current advantage is the ability to tackle complexity and uncertainty.
So you are surprised that a bunch of people whose work is to create mental models and automate them are obsessed with creating mental models of their own work and automate it?
It's fascinating, but at the same time I wish it was all simpler.
Actually it is, IMHO. A lot of the parafernalia around the job is useless obsession indeed. We're just that way for good or bad.
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.
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.
We have people sometimes produce the software equivalent of a Picasso, but it so rarely comes to light, and even more rarely codified to guidelines/standard-practice.
Would be very good to have "greatest-hits" of a company's codebase, that could serve as internal knowledge-sharing.
https://github.com/github/hub/blob/master/github/crash_repor...
Or do you mean with comments in the margin?
An idealist, for sure...
> Prioritize learning over profitability.
... but that doesn't sound very pragmatic.
I love learning. My boss loves making the company profitable. Coming to a happy medium is where a lot of learning can happen if both of you let it. If one party's not on board, then it's going to end up being a problem.
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.
> ... If one party's not on board, then it's going to end up being a problem.
Idealism, IMHO, acts as a motivator and helps folks get through the obstacles that inevitably block progress.
While there are good chances most people will be working on web or mobile applications, there's much more going on. Compilers, cryptography, compression, operating systems, graphics, simulation, data retrieval, distributed systems, etc. To that you need to add machine learning and AI.
I think it is hard to come up with a unified set of tactics/strategy to be an effective engineer at each part of this occupational spectrum.
For example, some engineers, while learning, try to specialize themselves in an area while others try to become generalists. Both approaches can be valid depending on the role.
Some engineers focus on applied science while others on theoretical science, some others just on empirical knowledge, processes and techniques. Again, the impact of this decision will largely depend on the role.
Then, prioritization is a double edged sword. To do what is perceived as important is intuitively the right thing to do. But during learning it is harder to recognize what is important. This is how many people end up neglecting valuable learning.
FWIW: I didn't produce the content present on this gist.
I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.
I've found that this can mean doing grunt work or it can mean reducing siloed information by having them do grunt work. This is to say that helping the team, helping grow yourself, and helping to ship product are not mutually exclusive from each other.
Of course if someone is only doing 20% of any given piece of work (say, never writing tests or refactoring or doing code review), then yea, that is a big problem.
+ The most valuable thing? + The riskiest thing? + The simple thing?
Edit: [guesstimated]
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.
Does any of this seem a bit Shepard Tones to anyone else?
https://www.youtube.com/watch?v=OsBanpBQj0k
(ever-ascending-tones audio illusion)
Thinking more strategically about the most effective way to spend my own time and energy was easily worth the nominal cost of the book.
As an example - if you work as an software engineer in finance learn about a few particular financial products at the same level or better than your users, get a masters in finance, applied math, accounting and whatnot. This has the added benefit of staying relevant in the market when you age, as software engineering becomes increasingly commoditized.
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”.
Don't believe me? Any invention that you have created at your workplace (patents etc.) is always held by your company, not you.
They pay me real money - I do real work for them.
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).
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.
https://news.ycombinator.com/item?id=16037746
You decide if there is any merit to the advice given.
One other quality of effective engineers is not fall for bullshit and have a scientific mindset of inquiry.
First of all look at this sales copy of the book. https://www.effectiveengineer.com/book
It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph. Then there are testimonials about how great the advice is from "LeaderLeaderLeader" enterprise hierarchy pattern i.e people with big titles from popular silicon valley companies.
Everything in that page is designed and optimized to make you buy the package. For a price of 250$ you too can know the secrets of effective Engineers.
To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package and read the content and then they too will be part of the club and work at a big name brand company. Some people in our work places are exceptionally good at social engineering and not so much in actual engineering. The sales copy co-opted the "engineering" discipline to sell some curated content. This looks much similar to team/company "politics".
I do not think people in "effective engineering" business do this. This is certainly what people in content business do.
Now compare that to some other book for a contrast. https://basecamp.com/books/getting-real
Engineering is just like any other skill for e.g., like playing chess or piano or swimming etc. You get better by doing it many times and failing often. To be good at engineering involves many factors like genetics, discipline, irrational love and passion for a particular domain, patience, exposure to better ideas and better people. Even you are good at engineering, to be effective at a company/market, you need to know the right people and have right social and financial skills to get name and recognition.
Some how, effective engineering has become synonymous with what happens at big name company teams which I think is very wrong. If you look at the real world, once companies reach a bigger size, they stop doing effective anything. They just buy other small companies which spend more time on making effective products.
This content seems to be analogous to "founders at work" but a better title would have been "engineers at the enterprise".
Where are you reading this?
"The most effective engineers — the ones who have risen to become distinguished engineers and leaders at their companies — can produce 10 times the impact of other engineers, but they're not working 10 times the hours."
Taken from https://www.effectiveengineer.com/book
To be good at sales copy also involves many factors, like interviewing your prospective customers, understanding what language they use to describe their problems, listening for what dreams they actually have, addressing their concerns by establishing credibility, and having a strong desire to help them achieve their goals.
Good sales copy doesn't aim to "trick" people; it aims to show that the product being sold will achieve the prospective customer's goals.
The reason I'm sharing this perspective is that many engineers do look down on marketing and sales copy as something that's automatically "bad." And that automatic association does them a disservice.
They write awesome code or build awesome products and features that could add so much value to the world, but they then just expect anyone to automatically see that value. They don't take the time to understand what their users' problems might be, to share how what they built might solve those problems, and to "market" their solutions. That mismatch of supply and demand ends up being a missed opportunity, and sadly, this happens all the time.
I understand your perspective about engineers undervaluing marketing and sales skills, but I think it's an example of short term thinking. Credibility is a currency, internet never forgets and I would never build credibility like this because I do not know how this will limit my future possibilities.
The author is just giving you advice for doing those things.
We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks.
The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable people in the industry are the young people looking for guidance and advice from older generations. The sales copy is clearly exploiting their insecurity by suggesting somehow there is a shortcut and by knowing these secrets for a small price, you too can be a 10x engineer.
When you have a choice, you should always choose high leverage. You should work to limit distractions and get more focus time. This is all great advice.
Which one did you purchase? "The master package" to become effective engineer.
It makes bold claims like it will make you 10X engineer and it some how guides you to figure out which technologies you need to work that will succeed in the future and keep reading, you will find more gems in there. The whole content is preying on the vulnerable.
We have had great advice in the tech industry so far like, "put customer first" or "think lean" or build beautiful products etc but this is the first classic that says to put yourself first and work on things that elevate you at the expense of the team and company and more narcissistic gems bundled with gossip from engineering teams with famous name companies.
I seriously doubt anyone who is looked upon for guidance by others would suggest something like this.
adios while I read the "Tactial Toolkit" to become effective engineer.
BTW i didn’t see any marketing claim on his site that he’ll magically turn you into a 10x developer, but googling found this blog. Read it and try to tell me it’s advice isn’t good or that it’s “corrosive” in any way to the team.
http://www.effectiveengineer.com/blog/how-to-become-a-10x-en...
First let me look up the author. Let me also just say that I have nothing against this author. I respect his entrepreneurial spirit and I believe he has a great future. But I deeply believe this sales page here is just plain wrong https://www.effectiveengineer.com/book and I strongly feel that experienced people like myself have to speak up when situation calls for it. It is fundamentally sleazy thing to do to other younger minds seeking proper guidance in the tech valley.
Authors resume
First things I noticed. This person has not stayed at any company for more than 3 years. No strong engineering role titles like architecture or design or scaling roles. Mostly soft engineering roles like testing and growth hacking. as a 30 year experienced person like yourself ask yourself. What kind of serious engineering product can one build in that time period at a company with that roles and how many? In many respectable companies I worked for, a person with this experience level cannot even hire/fire people, interviewing someone is not same as hiring.
Next look at the the github profile vs quora profile.
https://www.quora.com/profile/Edmond-Lau
You can notice, this person is more of a content writer compared to code writer. What sort of engineering skills and expertise do you notice about the author that makes him write a sales page like this?.
https://www.effectiveengineer.com/book
Just like how I said it before, this is an effective nonsense garbage content marketing. The author has no qualifications to be writing a book on effective engineering. It is an insult to people who do actual engineering.
This person is milking his past job experience role at brand name companies to an irresponsible extent. This is not illegal but a very sleazy thing to do.
To people who really care about this topic, please get a good mentor in and around your workplace. Just do not fall for this click baits and gossip about tech companies does not make you effective anything. Engineering skill takes a lot of practice and patience, I am afraid there are no secrets and shortcuts.
If you don’t like specific ideas of his, attack them. But as a 30 year engineer whose managed teams as large as 40 people, while i don’t agree with everything he wrote, lots of it rings true to me.
I find it difficult for a person with valid credentials in real life support this content marketing fraud.
You haven't even read the notes, if you're conflating these two ideas.
Do you disagree that effective engineers need to come up with strategies to be continuously learning? Or that it's important to make sure you spend time on tasks/projects that matter as opposed to busy-work? Or that it's important to properly use your daily tools? etc etc
I haven't read the book, and I only went over the main headers of this gist, but this all looks like pretty sensible advice to me to be more effective and productive.
- 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 through
For 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
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/
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.
If I hook everything into slack I have a simple interface that can cover and reflect all my needs!
"FWIW: I didn't produce the content present here.
I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit."
How convenient? It was copy/pasted from somewhere, but oops, can't remember where or who wrote it, oh well, I'll just put it under my name :)
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."
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.
"About 20 percent of the bugs causes 80 percent of all errors, and--this is stunning to me--1 percent of bugs caused half of all errors."