Google Developer shares How to become a 10x Engineer[Storytime Saturdays]
His job at Google was improving internal tools for productivity.
Hello all,
I have a very special post for you today. Chris Laffra is a senior engineer who has worked with some of the biggest names in Tech and Finance. For Tech, he worked with IBM, Google, and Uber. For Finance, it was Morgan Stanley, Bank of America, and most recently JP Morgan Chase.
While at Google, he worked on social graph analysis techniques to improve internal tools used by Googlers. It is safe to say that he has a lot to share when it comes to what makes top-tier developers. In this article/post, I will be covering some lessons that I found most insightful/impactful from his appearance on the phenomenal Beyond Coding podcast.
Warning: This post will be quite long. Patrick is annoyingly good at asking insightful questions. And Chris has a lot of knowledge to share. I would suggest saving it and coming back to it repeatedly. I know a lot of you managers are busy people who can’t always read the longer posts in one go.
Key Highlights
Following are the key details that this post will cover-
The 10x engineer vs trying new things- 10x engineers can achieve a lot because they end up using tools and technologies they have mastered. However, this also means not spending time on new frameworks/tools/languages and there will be times when you end up using tools not compatible with your organization. This is a tension you will have to resolve. I will share my experiences with balancing this tradeoff.
Doing more coding=/= being a better coder- As engineers, it is tempting to try to approach everything as an engineering problem. Come across a problem? Try coding up the solution. The domain also self-selects for people like that. However, it is important to sometimes take a step back, and not rush in. Breathe, and take a second to think about the stakeholders. Talk to a lot of people. It will pay off in spades.
Context Switching is bad for creative work- A Google study showed that you want to avoid constant meetings and distractions for peak performance. Setting aside a block of time for Deep Work, minimizing meetings, and blocking meetings from one day a week were all shown to be very effective.
Productivity requires F.R.E.E- Focus, Results-Oriented, Efficiency, and Empathy. This is an amazing framework for becoming more productive. Don’t miss this.
This was a brilliant talk. You don’t want to miss this.
[FREE SUBS]To buy access to this post, use any of the following links. The price is 3 USD. Once you send the payment, message me on IG, LinkedIn, Twitter, or by Email:
Venmo: https://account.venmo.com/u/FNU-Devansh
Paypal: paypal.me/ISeeThings
Or you can sign up for a Free Trial Below. Get 2 weeks FREE at no risk to you.
Doing more vs Doing different
The first idea that I found very compelling is this idea of there being tension b/w ultra-productivity and picking up and testing new things. This is a tradeoff that we have to make a lot balancing both are key to career growth. In AI terms, this tradeoff reminds me of the exploration vs exploitation dilemma.
Both things have helped me a lot throughout my career so far. My first programming language was actually Java. I used that pretty extensively, eventually getting into Android Development. I was even the winner of an international Android App Development Competition for students.
I could have stuck to that and done alright. I decided to try out Machine Learning and Python on a whim, and it quite literally changed the course of my life.
Since then, I have mostly stuck to Data Analysis, ML, and Math. I have worked on other projects occasionally, but these have been my money makers. The years I’ve put into understanding the nuances of ML have allowed mastering the basics beyond any other field I’ve worked on. Working with mainly Python allows me to quickly start making contributions. I don’t have to keep learning the basics in different domains because I already have a foundation built up.
Clearly, both things have helped me at different points of my life. So how do we know when to commit to something and when to bounce to something new? The talk didn’t really talk about this, but I will share my experiences.
At the start, you should absolutely check out different fields and frameworks. Test out concepts and ideas and see what domain most interests you. I did Java because that’s what they taught us in India. Picked up Android because that’s what my boy Noni was also getting into. I happened to be watching some talks on decision theory, which is what got me into ML. Learnt JS for my climate change modeling work. And so on…
Jumping around exposed me to different ideas, and taught me how to learn new frameworks quickly. It also taught me how to identify what the right questions to ask were. Most importantly, it helped me identify what I didn’t like, and what I would do. Android was fun, but the setup was a nightmare. I didn’t really enjoy the CSS/design elements of web design. Machine Learning let me combine my love for Math and my ability to code into one neat package.
Once you find something that is a good match for your skills and likes, you can put a lot of time into learning about your specific domain. For example, most of the study I do these days is related to Machine Learning. I don’t apply to non-ML roles. ML is the domain I have decided to pursue mastery in.
However, there is a lot of value in still spending time picking up other skills on the side. The beautiful part is that just mastering the basics will give help you a lot. These interests don’t have to always be coding-related (it’s better they are not). I bonded with a senior developer at Microsoft over MMA and competing(we met at a BJJ gym. More on that and networking here). The shared experiences of weight-cutting and doing underground cage fights gave us lots to talk about.
Even this newsletter has benefitted from me having non-coding interests. My interest in economics and finance allows me to create Finance Friday content. As we covered on yesterday’s Finance Fridays on the Crypto Crash, much of the cryptocurrency was caused by a combination of Greed, FOMO, and a poor understanding of economics. Today, I saw the following video by the amazing internet detective Coffeezilla, on a new crypto Ponzi Scheme. Watch it. You will see the same themes we covered show up again.
As they say, history always repeats itself. Understanding more domains will allow you to spot more ideas and be more creative. We covered this in the post about the super dev that got from SW2 to Principal Engineer in 4 Years.
Speaking of this, let’s now get to the next point. Sometimes less is more. Sometimes you don’t want to code. Let’s get into it.
Less is more
To the person with a hammer, everything looks like a nail.
This is one of my favorite quotes. This also holds true for software engineers. And sometimes we need to drop the hammer and pull out other tools. Or just talk to the nail. What do I mean?
As engineers, it is tempting to try coding up a solution for everything. This is a fatal mistake. Sometimes, the best solution is found in talking to the stakeholders, and filtering based on that. As the aforementioned rockstar engineer did, sometimes the solution is to simply identify the pain points and ask them to be less painful.
Recently, Carlo Ancelloti ended up winning the UCL (the biggest comp in club football)with an aging Real Madrid team. He took over midway through the season and helped a struggling Real team win the league and UCL. On their way to victory, they beat a who’s who of favorites. Don Carlo is one of the most successful managers in football history.
His success is largely thanks to his flexibility. He is able to adapt and talk to his players according to their needs. He molds to their needs, giving him exceptional man-management. But don’t make the mistake of thinking he doesn’t understand the game. His knowledge of the technicalities is impeccable. We must all aspire to be more like Don Carlo- deeply knowledgeable but ultimately flexible.
This involves learning about more domains. Truly understanding the problem domain from multiple perspectives and needs. This will allow you to identify the best use cases for your business/org. This is also why having a foundation in fields like economics, finance, and the domain you’re working in is important. It will help you identify the best value adds.
This will drop your output in the short term, as you’re not creating code. But once you do start building the product, the products you develop will be valuable. That will more than makeup for it. The next part will cover how to actually become more effective when working on the problem.
Boosting your Productivity
Chris mentions a few organizational/work-style changes that allow you to become more productive. These are the most interesting-
Setting aside a block of time for Deep Work- He gives an example of setting aside 1-4 PM every day for Deep work, for the entire org. This conditions people to be more productive since the entire environment around them is working at this time.
Minimizing meetings- Meetings can help you share challenges and learn from + update others. But too many will detract from your productivity and work.
Blocking meetings from one day a week- Chris gave the example of not having any meetings on a Wednesday.
These are ways to effectively direct your attention to your work. Your attention is a powerful currency. It’s not a coincidence that some of the biggest companies are all fighting for your views. We’ll cover the attention economy soon. For now, just remember that your attention is crucial. Productivity requires your undivided attention to the task at hand.
Wrt to productivity, Chris shares his ingredients for high-level productivity. We’ll end up covering that.
Productivity is FREE.
Once we go over each of these letters, you will see how all the ideas we have expressed tie together-
Focus- This means focusing on the right things. 1 Great value add is much better than 10 average ones. Remember, tech operates at scale. Take your time picking the most impactful battles.
Results-Oriented- Everything that you do must aim towards an end. When it comes to your work, ensure everything you do contributes to the end goal. If it doesn’t, then it’s not worth doing. However, make sure you balance this out by exploring other interests when not working. We’ve already covered how this will help you in your work (and make life more fun).
Efficient- See a task that you do repeatedly? Automate it. If it’s not important enough (and hard to automate), delegate the responsibility to someone else. Build your pipelines to ensure minimal wasted time/effort.
Empathy- This was my favorite letter. Everyone must work on developing their empathy. Empathy has a lot of practical benefits. Writing clean code, Effective Standup meetings, Meetings with Managers/People under you, Learning to identify the most effective features for users, and good documentation are all going to be improved by more empathy. After all, empathy is the ability to consider alternate perspectives. As we’ve covered, that is a superpower by itself. More empathy will also help you understand what you want better, allowing you to live a more fulfilled life.
That’s it for this post. I know we covered quite a bit here, but there were a lot of important points to be covered/elaborated upon.
Make sure you share your thoughts on this question/any interesting questions/developments in the comments or through my links. If you liked this post, make sure you tap that heart button and let the world know.
Reach out to me on:
Instagram: https://www.instagram.com/iseethings404/
Message me on Twitter: https://twitter.com/Machine01776819
My LinkedIn: https://www.linkedin.com/in/devansh-devansh-516004168/
My content:
Read my articles: https://rb.gy/zn1aiu
My YouTube: https://rb.gy/88iwdd
Get a free stock on Robinhood. No risk to you, so not using the link is losing free money: https://join.robinhood.com/fnud75