Lessons from 14 years at Google

One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.

I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.

Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.

* Don't work "off the clock", no matter how strong the urge: There's nothing managers hate more than surprises. Even good ones! If you've got some idea to work on, discuss it and get buy-in early. If you're spending a lot of your own time on something, that means it's probably low-value and you subconsciously know it, or it's stepping on somebody else's toes, or it's something that you're the only one who cares about. Once you're done, all your manager is going to say is "why were you doing that instead of ", and if it creates a bug or user complaint or anything else, you'll be on the hook. Save your creativity for personal projects.

* Get fast feedback. This kind of relates to the above, but more generally, iterate quickly at every scale. If testing your changes takes more than one button click and a couple seconds, whether compile time, staging deployment time, etc., fix it. Find out how others are automating their dev flows. A tiny bit of improvement here cascades greatly. Get fast feedback on designs: don't spend a ton of time writing a long doc and waiting for approval; send out a 1-paragraph summary or whatever you think the minimum is, get signoff, get done and move on. Do document, but don't overdo it. Get fast feedback on ideas; don't wait until code review time to find out that the team was planning a different direction. Yes, this does kind of suck if you're naturally introverted and prefer just coding, but it's part of the job.

* Set an extremely low bar for each day, but meet it. We aren't all superstars all the time. There'll be times when you're burnt out or blocked by something you really don't want to deal with, and making progress can seem overwhelming, so "I'll just surf the web for a while" turns into all day, which can turn into all week or all month of excuses about how little progress you're making, and the anxiety and guilt becomes more overwhelming than even the work. Avoid this by setting an easily achievable goal: a couple lines of code, a quick chat with someone who might know how to unblock one thing, whatever. That way you're not letting the anxiety build, you're not waking up the next day in the same state that you were the previous day, you at least have something to talk about during standup, and it's one less thing to deal with. Oftentimes it creates some momentum, and turns into a fully productive day! But be okay if it doesn't: the goal is just to get that one thing done, and anything else is purely optional: sometimes it's good to have an off day to recharge, so long as you're not starting the next day in the exact same position.

The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.

Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.

And then from the specification, decide how to implement it, which is not decided at all ahead of time.

Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.

There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.