How to Maximize Your Impact as a Software Engineer

Edmond Lau is an experienced Software Engineer who has worked for the likes of Google, Ooyala, Quora, and Quip. He also spoke to Engineering Leaders from companies like Twitter, Facebook, and Stripe, whilst writing his book ‘The Effective Engineer’. We interviewed him to understand what he has learned about maximizing impact as an engineer.

*Read more interviews with some of the world’s best developers on our blog or follow us on Twitter.

Lau says that something he noticed early on in his career that was reinforced after speaking with Engineering Leaders is that, “if you pick up the right habits, techniques, and mindsets when you’re starting off, then you’re significantly more likely to succeed”. This is most obvious when you look at the career progression of Junior Developers in organizations with and without effective onboarding programs, says Lau.

When starting at Quora early on, Lau says “it was sort of luck of the draw whether you would have a good mentor, or whether someone would explain to you core concepts in your first day or your first week or your first month. People who got lucky were much more likely to succeed and much more likely to be effective many months down the line”. So Lau set work on revamping their onboarding, and his re-worked “program was an attempt to level the playing field a little bit so that it wasn’t based on luck… whether you were on-boarded well.”

“Onboarding is not something where you do it once and you’re done. It’s something you do very incrementally,” explains Lau. “Start by documenting questions that new engineers are asking and make them reusable resources. If you are a new engineer, then as you are onboarding identify the things that are giving you problems. What is taking a long time to do that really shouldn’t? Over time, you can build up a repository of knowledge that becomes much more useful for new engineers joining the company.”

As an example of this Lau describes how things work at his current company, Quip. “Any time we are building new products we end up writing a short design doc that is then shared with the team” and then “everybody gets this new piece of information” and if “someone ran into an issue we document that into some best practices.” What this means is that over time “we end up with lots and lots of documents that are really useful for new engineers.”

Having spoken to many engineering leaders about what worked well in their careers, a number of common themes emerged. Lau says that one such theme was “focusing on and investing in tooling”. For example “when I talked with Bobby Johnson, who is the former Director of Engineering for Infrastructure at Facebook”, Lau recalls, “one of the biggest time and investments that he made that had the biggest return was just building tools. Trying to automate as much of the mechanics of what they were doing as possible. Every time they got a problem and found that they were still repeating what they were doing, they would write a tool for it and automate it.”

Another theme was “just keeping things simple… when I asked them what’s the biggest lesson or the most valuable lesson you’ve learned in the past year, they would say they just sort of made things a little too complex” and that things didn’t work when “there were a lot of operational burdens to keep things going.”

Keeping things simple and automating repetitive tasks are great examples of work which optimizes the impact you can have. This is a key part of Lau’s approach to engineering and is what he terms Leverage, and focussing on this helps engineers identify activities that have the most impact.

“Leverage basically means what is the output you’re producing for the amount of time you’re investing? It’s a metric of the impact you’re generating per amount of time that you spent.” So to be “an effective engineer you want to focus on the high leverage activities.” This might seem obvious, but as Lau explains it can be hard to actually internalize — “This is something that took me many years to learn… I used to work 70 to 80-hour weeks because I thought that was how hard a team had to work”. But after “we built an analytics module for a client and they never used it, or when we would build a product and it would never get the user adoption that we wanted… those experiences made me feel like working hard, putting in those hours just isn’t enough.” Lau says that what he then learned to do was “prioritize the things that are actually generating a large impact for the amount of time you’re spending.”

So, how do you know what to focus on? “The key” explains Lau, is in “setting up feedback loops, and that applies to everything you do. For instance, when you’re writing software, it means you send around a lightweight design doc to get feedback on your design before you even write any code. When you’re writing code it means… sending your code to code reviewers that are the strictest. The ones who would do a good job of critiquing what you’re doing. If you’re working on a product it means… getting feedback from gatekeepers who sort of block or launch as soon as possible. Then when you’re building or iterating a product, it means running A/B tests to measure if this change is actually materially improving the product in some way.”

To monitor and gauge this feedback you want to “pick a metric that incentivizes the type of behavior that you want”. Lau gives the example of a Performance team looking to optimize the performance of their product — “the metric that you want to improve could be something like the 99th percentile of all load times. Or it could be the average load time. Either of those metrics would improve the performance of your product, but they have very different outcomes. If you’re improving the average load times, that would tend to make you focus on general server improvements, but if you were focusing on the 99th percentile… then you’re focusing on the long tail of the application.” So it’s important to consider the metric you choose carefully, as “the choice of metric affects the type of work that you focus on,” Lau says. So “pick the metric that is most aligned with the success of the business.”

Lau attributes success in his career to having purposefully sought out job opportunities where he could continue to learn new things and push himself. Without doing this, Engineers can end up “being stuck on a plateau where they’re not really challenging themselves, they’re not really learning day to day. Just from my own experience, when I was at Google, it was a very comfortable place and sort of after my first six months there I learned a ton… but after two years I felt like I wasn’t really challenging myself anymore,” explains Lau.

Another way he has developed himself is through meet-ups and swapping stories with other developers. Lau comments that “when you’re working on a team, a lot of times the lessons we learn are just the ones that occur during the projects that you work on. People who have either had similar experiences or have gone through other projects… can teach you a ton.”

*Read more interviews with some of the world’s best developers on our blog or follow us on Twitter.