Paul Buchheit on Joining Google, How to Become a Great Engineer, and Happiness

I think of it as lack of motivation combined with low-grade frustration from not being allowed to shift to something worthwhile. Paul Buchheit is obviously a self-winding guy. But put him in a context where he's expected to do things he doesn't care about and is forbidden to do things he does care about and all the air goes out of him. That's certainly what it's like for me.

Companies should learn a lesson from this. When I'm managing I work hard to build close-knit, cross-functional teams that score well on Pink's Autonomy/Mastery/Purpose triad. Purpose is the foundation: you have to give the team something meaningful to do and then connect them to that meaning. Autonomy comes next: you give them broad long-term goals and near-term milestones and turn them loose. They should always feel independent but accountable. Mastery comes from letting them meet and overcome challenges, learning as they go, but it doesn't hurt to support them by providing them coaching, access to experts, and any training they ask for.

Buchheit is clearly exceptional, but I think everybody benefits from environments that support his approach to the world. Every child is curious and exploratory. Many have that beaten out of them by industrial-model education and top-down corporate workplaces. But I don't think it's ever truly gone, and I think businesses really benefit if they deeply engage their staff.

From an evolutionary point of view, if we're not inspired and excited about what we're doing now or what we expect to be doing in the near future, it makes sense to go into energy conservation/restoration mode and go to sleep.

Similarly, over the long term, if we aren't inspired by the life we see ahead of us, it's best to go into energy preservation and contemplation mode while we try to figure out how to get onto a better path (and if we can't find one, we end up in chronic/deep depression/despair).

I've overcome depression (and come off meds) by developing/learning techniques for finding optimism any time things seem bleak.

In one the latter chapters, he has a rule about "summoning your own enthusiasm". The primary observation in that part of the chapter was that it's really hard to truly exhaust someone physically, and even harder to exhaust them mentally, if they're doing something they actually care about. He gave some examples, one involving special forces people, and concluded that the primary source of tiredness for most people is lack of motivation - lack of interest, or not being able to feel there's a goal to all the work one is doing.

While my opinion is that Carnegie was exaggerating a bit here, I won't deny that this rings very true to my experience. As a programmer, I don't get physically taxed by work, and I very rarely get mental exercise too (most programming on regular web jobs is just plain tedium). But I do feel really tired on the job very quickly, and - back when I was a regular employee - the feeling used to evaporate almost immediately when I clocked out for the day.

I can even give an example from yesterday - lots of work and a visiting a doctor made me really tired by the evening, but I decided to sit down and write some code for a side project. My tiredness was gone immediately, and after 2 hours of cranking out code, I had to force myself to go to sleep, in order to have any energy for the next day.

At least for me, it's boredom combined with a lack of purpose. If you're doing something boring/mundane at home like doing the dishes, at least at the end of it you can see your sink is empty and the dishes are clean. It feels like there was some point to it.

At many companies it can really feel like you are just doing something because somebody told you do it and there's no other purpose in doing so. Sometimes you have no connection to the people using what you are building, and no idea if what you're doing is even really driving revenue or benefiting anybody.

If you're not learning and you're bored, the lack of purpose eats away at you slowly. Even if you build something that ultimately fails, if you can directly understand the cause of that failure you can learn something for the future. It can be harder to understand how what you did is related to success or failure at big companies.

I often get it myself, feeling like I can't physically write another line of code until I move onto one of my own projects, then I'm good to concentrate for another 6 hours. I have to work extremely hard to complete tasks that on the surface look very simple and involve solving no new problems. This also extends into my normal life, like cleaning a messy room.

Note: I haven't been diagnosed with ADD and am not suggesting anyone has it if they experience this, I've just looked into it a lot.

Back when I was in college, I used to go to raves and do drugs.

At some point, I started to chaperone my friends and I'd be the sober one, responsible for taking everyone home.

I noticed that there's definitely an "energy" that you feel in the room, even stone cold sober. Being surrounded by 2000 people who are high as a kite has a way of making you feel high... Even if you're stone cold sober.

I think there's something similar going on in offices. There's some kind of 'proximity effect' there.

Stress. (One of the smyptoms of)

Stuff happens around you, but you are not really a party to it, and you don’t have to be.

Same for really boring meetings. You just get slowly lulled to sleep.

I once had a manager tell me, "Show up or be fired. We will judge if you deserve to go home or not."

Yes, one should look for a better job elsewhere, and lately the economy has found more room for all of society's laborers regardless of vogue credentials.

However, I can't pay the bills with interviews, and often times I lose value through interviewing.

I used to just hit <Tab><Tab> to get Bash to print all possible commands, and I’d just try random ones until I found one that would let me edit text, and vi was it. It was pretty fun learning how to even quit vi, let alone edit any text, but I was pretty determined back then.

That’s mostly how I learned Linux back then: just hit <Tab><Tab> and try out any random command that looked interesting and see how it worked.

I didn't come from a rich family. Throughout my whole education, I was on hand-me-down computers. They were predictably low-spec but that's how I learned HTML, JS, and CSS in high school, and then Scheme, Java, PHP, C, et. al. in college.

Add to that the fact that our internet connection isn't great either. Alongside learning how to program, I developed a preference for tools that came out of the box. You didn't have to download them and you can be fairly confident that they are compatible with the hardware specs you got. It's for this reason that I was never fond of IDEs ala Eclipse and NetBeans; when I started messing with Linux, I used GEdit. Eventually I started doing AI stuff and, either by sheer nature of the algorithms themselves or maybe my own programming incompetence (or both), running those algorithms made my already poor computer crawl (I had 2GB of RAM back in 2010-2012, when this story took place). So I started to really try to squeeze more resources out of my machine.

Among the first to go was GEdit. I could not prove this to you scientifically but my reasoning was that if it had to draw a window, it was eating on my resources. So I learned vi, another decent text editor that came out of the box with Ubuntu. I would've gone for nano but I thought, if I'm gonna learn how to use an editor that does not render a window, I might as well go for the one with the more geek points.

Eventually, I started working and got relatively better internet connection. I finally learned the difference between vi and vim so now among the first things I do on a new machine is install vim (although in my bashrc I have alias vi='vim'). Learned a few tricks from my coworkers who used vim and started a dotfiles repo with my own vimrc. I still try to stay minimalist though. I don't install plugins so I bet by most vim users' standards, my set-up is horribly vanilla.

Elon Musk was once asked in an interview "How do you judge whether a highly-technical expert really knows what they're talking about?" His reply was along the lines of "You ask them questions of progressively increasing levels of detail. Someone who's actually an expert will understand a subject on many levels; they'll be able to give you the ELI5 version, but then will have good answers every time you probe a level deeper."

Larry & Sergey's elevator pitch was "We built the best search engine in the world", but if you asked them "What's it running on? How many machines? How many pages does it index? How do you handle duplicates? How many queries/day do you get? What are people looking for? How do you rank pages?" etc. you'd get good answers for all of them.

Elizabeth Holmes's elevator pitch was "We're going to revolutionize blood testing with finger-stick tests", but then if you asked "Which tests do you run? How many molecules of __ are in a drop of blood? How much variance is there between people?" you would very quickly run into either evasions or outright lies. Once you start asking questions on top of a lie their story usually falls apart pretty quickly, because few people can remember everything they just made up 5 minutes ago and still make up some logically coherent detail on top of it. (This, BTW, is why improv theater is so hard, and why most improv shows are comedy, where it's just funny if you end up with a non-sequitor.)

The same technique works well for reference checks, but you can't blindly trust whatever the reference tells you. Most people cherry-pick their references; it's easy for a charismatic charlatan to find some people who are still super-enchanted by them. Many people are also pretty unwilling to talk (particularly about litigation-happy scam artists like Holmes), for fear of defamation lawsuits.

but, how would you do a reference check on larry, sergey, or holmes? none of whom held a job before they founded their respective companies. as will be the case with most startup founders. are you going to stalk their college friends?

After 4 or 5 years of doing this you'll maybe know enough about how "everthing works" and what books says how to do what, or what company did what in what way, or the "state of the art", at that time you can start doing original contributions in order to not fall back.

Oh and also the Imposter Syndrome sometimes never really goes away :(

1) Write a lot of code. Like a ton, more than anyone else on the team. 2) Get feedback from people on that code.

And that's how you start to beat Imposter Syndrome.

If they have good answers to those questions that don't feel like canned responses, then go dig deeper. Ask their employees about their leadership style - do the answers match? Does their resume and google-stalking match their story of their history? Ask the team about organizational conflict resolution. You should get similar responses.

Also, think about whether they talked to you like a leader. I've had interviews when I really enjoyed talking to the potential boss, and it felt friendly, and those turned out to be sub-optimal leaders. But the good leaders I've worked for interviewed in a way where I was comfortable, but challenged by the questions, and they stayed focused. They didn't chit-chat or make friends (at least not beyond just a few quick minutes as we got started), they drove towards getting the answers they needed to see if I was right for the job, and they gave me opportunities to ask questions back.

In the startup world, bullshitters are pretty much the norm, so finding bullshit isn't difficult. What's difficult is ignoring the hype bubble and social pressures that come with challenging people who are well-funded (and of course, sometimes you're wrong, which is part of what makes it hard).

Even if you're wrong, though, a non-bullshit answer to a pointed question will address the question. Most people, however, will just say words that dance around your question, clarifying nothing. In that case, you have to have the guts to keep asking followup questions, even if it makes the bullshitter uncomfortable.

When I think back over my history, I've always had a pretty good idea about the bullshit level of various employers simply by asking simple things like "how do you make money?" Good entrepreneurs will simply tell you (even if the answer is "we don't, yet"). Bad entrepreneurs will dress it up and try to hide their answer in word salad. Avoid these people.

One of many Bill Joy legends: BBN had a big contract to implement TCP/IP, but their stuff didn't work, and grad student Joy's stuff worked. So they had this big meeting and this grad student in a T-shirt shows up, and they said, "How did you do this?" And Bill said, "It's very simple — you read the protocol and write the code"

http://norvig.com/

When you have 10 people in a project there's way too much friction. Every decision is stalled, people code defensively rather than proactively. Everyone is trying so hard to get to the lowest common denominator that they can never do anything actually good.

That's not to say that better or worse engineers exist. They do. But I feel like a team's context and environment has a much higher impact on the quality of the output. You take away people's autonomy, the result will undoubtedly be shit. You give people autonomy, you can get bombs but you can also get brilliance.

The end result still depends on experience, but even the best programmers slow to a crawl when they work in an enterprise environment (obviously not always true, but as a general rule)

You can tell there wasn't a winer equivalent on the windows 95/98/ME teams

My timing was atrocious; every single month my home was worth less and less and less.

I absolutely bent over backwards to keep my job. Worked sixteen hour days, worked weekends.

My employer kept trying to replace me, because my rate was fairly high. First they tried to hire three people in India to replace me, but a third of the Indians quit, a third were gobbled up by another team, leaving one Indian who wasn't that great.

Then they brought in a couple of consultants. They basically phoned it in for a year, and were eventually sent back.

I think the reason that I weathered all this is that I simply didn't have a Plan B. I couldn't fail, if I did, I'd lose my house. I was willing to do whatever it takes to stay employed, and though they kept trying to replace me, they couldn't find anyone that was that invested in succeeding.

This isn't to say I was smart, or talented. But I was tenacious and I was relentless.

John Carmack

Dennis Ritchie

Ken Thompson

Bill Gates

Donald Knuth

Jeff Dean

Brian Kernighan

I don't think those are generally good examples of 10x engineers. Most people don't get to have a large impact by making the most of something specific. I think in the wild it is more as described in the article. That 10x engineers are people who raise the standard for whatever is in front of them and save themselves, and their companies, thousands and thousands of man hours by doing so. It is really really hard to be better at people at hard things, it is a lot easier to be better than people at things that are supposedly easy, but people consistently fail at.

Basically: brilliant, but very quirky.

On the other hand, if your problem is to simply produce more of something no 1000x genius will get you far enough. Farer than the mediocre resource, but even for these people a day has only 24 hours.

Ivan Sutherland

L. Peter Deutsch

The bigger the company, the smaller your role's coverage. You get well-compensated and aren't worked too hard, but your job might effectively be "you're responsible for these two screens of this one component of this particular application". The conflict is that the bigger the company, the higher the bar for entry. So you end up with a bunch of really bright, challenge-loving people cooped up working day in day out on very specific cogs of the giant machine, and that's not an ideal lifestyle for all of those people.

> On Leaving Google [...] But when I went in the next day, the energy drained out of me. I suddenly felt like I used to feel working at Intel. Partially I think Google had grown so much in my absence, but it was also partly a “boiling the frog” effect: before I spent time away, I hadn't noticed things slowly changing, but when I got back I realized, “Oh wow, here I am in a meeting with a bunch of people I don't know who are telling me to do stuff that I don't care about.”

Everyone still says Google is so great. Enough that I still wonder what happened. I also couldn't settle in, didn't like anyone, and was continually interrupted/harassed/followed.

Isn't it easy to change teams at Google?

The channel sorted by new: https://www.youtube.com/channel/UCcefcZRL2oaA_uBNeo5UOWg/vid...

Perhaps that isn't the intent of your question but just wanted to state that, at least as a warning to others, as it is the implication.

Software, and life in general, is an exercise in abstraction. How do you effectively use abstractions that others have used, without knowing how they really work. How do you figure out which sub-abstractions and intricacies you can safely overlook, because they aren't relevant to your current priorities. And how do you shortlist the ones that you do have to care about, because they have a big impact on your project's success. These are the key skills that effective engineers possess. Trying to avoid the above problems by brute-force learning everything, is going to get you stuck in a quagmire.

Once, while investigating the cause of occasional bursts of static in audio, I eventually narrowed it down to misconfigured pull-down resistors on the ADC data lines. (Okay, not quite silicon.)

EEC memory, a not uncommon upgrade for servers, guards against data corruptions due to thermal noise (a silicon-level concern), among other things.

Okay, it's rare that the lowest levels will affect most projects, but without a little bit of understanding, some bugs can be impossible to even fathom.

As abstractions have improved and become less leaky over over time, the necessity has decreased. Older programmers will thus tend to feel this much more strongly than younger programmers.

I think it used to be very true, it is less true than it was and it is becoming less true every day - with the exception of environments where foundational technology is engineered shoddily.

Or did you think "systems" ended at some smaller scale? ;)

It was probably not made clear but he seems to be talking about systems engineering in particular.

1. Write down the problem. 2. Think real hard. 3. Write down the solution.

This is a joke of course, but much of the real 10xness is invisible. It certainly doesn't look like typing. Perhaps quite a lot of it occurs off screen, in conversations, whiteboards, on the computers of colleagues. I'll give you two analogies:

In some ways it's like one of those "bullet hell" shoot-em-up games, but played out over weeks or months. There are all manner of mistakes that can derail a project but only become obvious later (e.g. poor dependency or architecture choices), and there are all manner of techniques that may let you skip a section or avoid a whole category of problems, perhaps at the cost of requiring more immediate skill (e.g use of higher level but unfamiliar programming languages like Haskell or APL). Someone with 10xness dodges all the bullets and takes the correct shortcuts, while people with less talent and experience mistake the one for the other or don't see it coming.

Or there is "bug sniping", which I think is the place I've been able to make "10x" contributions: it's possible for your colleagues to be simply stuck on something, consuming a lot of time for no progress. Maybe they can manage a workaround, but at an efficiency cost - like people driving slightly broken cars which you have to open the passenger's side first to unjam the driver's door. This is the field in which puzzle-solving ability really helps. It's just that the puzzle has been created accidentally by other developers or yourself.

That’s one thing that makes them really hard to recognize by non technical people. I would say that to recognize them and admire their work, you have to bang your head against the same problem as they do, and then see how they solve it. But just looking at their work from the outside will probably be very unimpressive.

I don't know about 10x engineer (I actually think that whole line of thinking is bullshit), but Blow has shipped a few games.

See also https://www.gun.io/blog/what-i-learned-from-watching-notch-c...

https://www.youtube.com/watch?v=7Hlb8YX2-W8

They don't have to type fast, but they're also not relying on Stackoverflow for learning concepts.

Most web applications start as prototypes written by one guy in 90 days or less, then just re-labelled as "production."

https://www.youtube.com/watch?v=1e0OCwlaEZM

Yep, a busdriver. That's what he does. I find having these videos open during coding is pretty inspiring, too bad there's so few of them.

https://vimeo.com/105955605

Someone with a Bachelors (or less) who builds systems by writing code is not a computer scientist. That is a less appropriate title than engineer.

> Here that would be so totally illegal if you are not a member of the order which requires an engineering diploma.

Yes, we know Canada is almost uniquely psychotic about this. I, personally, think it is ridiculous, and I state this as someone who holds an accredited engineering degree (EE) and originally considered pursuing licensure.

That said, I do think software engineering is in dire need of some actual engineering discipline. This industry also is in dire need of title bifurcation; calling everyone "software engineer" regardless of what they actually do, just because they touch code, is ridiculous.

I know what you mean though: Chartered Engineer is a proper thing for example, with exams and governing bodies involved, and anyone in construction who just decided to call themselves a Civil Engineer would likely get into some bother for doing so.

There's a spectrum of software engineering like there's a spectrum of any engineering. It's called software engineering because it's applying an engineering approach to software.

https://www.theatlantic.com/technology/archive/2015/11/progr...

We also have certifications. They're not evidence you are a good software engineer.