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?
Keep reading with a 7-day free trial
Subscribe to Technology Made Simple to keep reading this post and get 7 days of free access to the full post archives.