How to improve developer productivity [Storytime Saturdays]
4 core Principles to help your developers hit better performance.
Hey, it’s your favorite cult leader here 🐱👤
On Saturdays, I will cover stories/writeups covering various people’s experiences 📚📚. These stories will help you learn from the mistakes and successes of others. These stories will cover various topics like Leadership, Productivity, and Personal/Professional Development. Use these to zoom ahead on your goals 🚀🚀
To get access to all my articles and support my crippling chocolate milk addiction, consider subscribing if you haven’t already!
p.s. you can learn more about the paid plan here.
Hello all,
I am currently in Cambridge, Massachusetts/Boston area. Let me know if any of you are around and would be interested in meeting or if you know someone in the area that I should meet. Meeting new people is my favorite thing about being nomadic. Also, if you could quickly fill out this feedback form here, it would help a lot. It asks one question- What are you looking for from this newsletter- and is completely anonymous (although if you leave your contact information for a follow-up, it would be much appreciated). I really appreciate all of you that vote on the polls at the end of the article. This would help further calibrate my writing to your needs (and you only need to drop this once).
Back to the topic at hand. I get a lot of requests from people who are struggling to take their engineering/their teams to the next level. Luckily the internet is a treasure trove of great resources and amongst them is Chris Laffra, whose job at Google was to make their engineers more productive.
While at Google, Chris worked on social graph analysis techniques to improve internal tools used by Googlers. This gave him great insight into what makes top-tier developers and what differentiates high-performing teams. 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. If you’re a podcast person, would highly recommend subscribing to Beyond Coding. I have no affiliation with them, but their content is top-tier.
Key Highlights
Following are the key details that this post will cover-
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. How can you identify what is important? That’s where the next point comes in.
Aim for Leverage- This wasn’t something that Chris went over, but it would be valuable for the last point. For our purposes, leverage is simply the ability to influence people and products through your actions. High-leverage actions exemplify the 80-20 rules- getting you lots of output for lower inputs. Picking high-leverage actions is a matter of developing taste and improving decision making. We will go over how you can do so.
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.
You’re going to have a good time with this. Let’s play.
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. Take the story of this engineer, who went from a junior engineer to a principal engineer in just 4 years. As the aforementioned rockstar engineer did, sometimes the solution is to simply identify the pain points and ask them to be less painful.
The overarching principle is to minimize engineering where possible. As we covered in this article, many teams tend to spend many resources on engineering optimal solutions, where sometimes simpler redesigns would be ideal. Going to code is a form of intellectual laziness, and you want to remove that mentality. Remember, you’re not paid to write code, you’re paid to solve problems at scale. Code, no matter how clean, is a form of debt. Usually, it pays for itself many times over, but viewing more code as a liability will help you adopt the mindset helpful to only seek out the most meaningful actions.
But this begs the question, how can we start identifying these meaningful actions? This is where looking for leverage helps a lot.
Hunt for leverage
As mentioned earlier, leverage is simply the ability to influence people and products through your actions. Someone whose actions affect 30 users has more leverage than someone whose actions only affect 10 users. And given that much of tech operates on network effects, the leverage increases exponentially.
So how can you start identifying high-leverage actions? Simply put, this requires that you step out of engineering and adopt a much wider view of the problem. You need to figure out when something is worth solving, and when you’re better off moving on to something else. You need to learn about more domains, developing the ability to truly understand 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. As engineers, I recommend the following list of subjects (technical and non-technical) that you must know about-
Math and Theoretical Computer Science
Coding
Economics and Finance
Philosophy + Logic
Writing.
The first 3 are covered in this newsletter, extensively. I also provide resources in the posts for those who want to learn more. So as long as you’re regular, you will be fine.
Number 4 is a tricky one. Everyone takes to philosophy differently. The YouTube channel Wisecrack is a pretty fun way to learn about philosophy in a fun and digestible manner. I also like debates on this stuff. Start from there and see where the winds take you. Brilliant’s course on formal Logic is a great one to practice logic through fun puzzles. As is the book, Lady or The Tiger.
University of Chicago has some top-tier content on writing and communicating effectively. That will help you with 5. Look Go from there into other free writing vids on YT. With this, you will have a solid foundation to leverage your engineering skills into building great products and boosting your career.
For more resources, I have a list of over 50 resources you can look at here. Take a look and see if any of them are valuable to you.
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 make up 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.
We also find that shifting attention rapidly throughout the workday is linked with stress and lower productivity. When attention switches from the task at hand, people have to reorient back to the interrupted task. This usually involves a cost, in terms of time to restore the context of the task, and sometimes in doing redundant work (such as rereading text). On average, people check email 74 times a day and after each of those email checks, returning to another task takes additional time to orient to that task, known as an interruption cost.
Work, Email, Distraction, Repeat: Switching tasks is ruining your workflow
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.
Using these principles you will see a notable improvement in your productivity. If you’re a manager, consider you can maximize the potential of your teams by ingraining these principles into your training programs/development resources.
Loved the post? Hate it? Want to talk to me about your crypto portfolio? Get my predictions on the UCL or MMA PPVs? Want an in-depth analysis of the best chocolate milk brands? Reach out to me by replying to this email, in the comments, or using the links below.
Stay Woke.
Go kill all,
Devansh <3
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