Today I attended and very much enjoyed a webinar hosted by Rahul Pandey and Alex Chiou of Taro. Both Rahul and Alex are ex-tech leads from FAANG companies. The title of the webinar is “How To Write Better Code Faster As A Software Engineer”. These are my notes from the webinar.

There are two axes to being a good “code machine”.

1. Quality
2. Velocity

“Code Machine” is a recognized archetype of staff engineers at certain larger tech companies. Another archetype of a staff engineer might be “Product Manager” for those excelling in that skillset.

A common misconception about delivering lots of software quickly is that you have to sacrifice quality. High quality code is conducive to high output. This is important at any level of engineering. Alex states that even the highest level of engineers, despite having more meetings, still spend about 20% of their time writing code.

Code quality is by far the most misunderstood metric.

• A trademark sign of a bad software engineer is low code quality

You can always throw more hours to increase quantity, you cannot do so for quality.

Velocity

The following are ideas for how to think about and optimize coding velocity.

Go deep, not wide

• Pick one tech stack and stick with it
• Breadth is cheap
• Takes 2-4 years to become proficient at a stack
• Avoid being full stack
• Will eventually hit an inflection point where you can code really fast
• Don’t switch stacks to maximize job opportunity

Be tactical with meetings

A common failure mode is to attend every meeting on your calendar.

• Juniors commonly do this
• Skip meetings where you aren’t a major player
• Always retrospect on meeting value
• Establish focus blocks, a long period of time that is uninterrupted where you can focus
• Try to have 1-2 days per week with no interruptions/meetings

Coding is heavily momentum oriented. Context switching is really disruptive, takes a long time to get the context and setup the environment to write code.

An engineer with 1 x 8 hours blocks of time will produce twice as much as code as an engineer with 4 x 2 hour blocks of time.

Look for patterns

All tech stacks follow a power law.

• Some components matter far more than others. For example, rendering a list of items on mobile.
• Should have an opinion on these common components. For example, should know that there are three ways to implement, this way is better for this reason, etc. Know pros and cons of all approaches for these common items.
• Identify common components to master (e.g. if frontend).
• Once you have identified these patterns, which may be unique per team/organization, get really good at them.

Do side projects

• “Life hack” to write more code without overworking
• Build things for fun on the side
• This builds skills
• If you want to get better at a skill, just need to spend more time practicing that skill
• This is especially powerful if you work at a startup and work on frontend
• Can almost copy/paste code from your personal side project into work codebase because you’ve already solved a lot of problems in your side projects

Other benefits of side projects:

• Fun
• Builds more holistic product skills
• Make you a more complete engineer
• Will help spark creativity at work
• Will help you learn more modern ways to do things because work projects might persist older patterns
• Side project allows you to explore modern approaches

Time spent after writing code

What is the breakdown of how time is spent once a PR is submitted. For example, what happens once you write the code to getting it landed (e.g. committed to main).

A novice engineer will:

• Submit code for review and spend little time on adding a summary, test plan, screenshots, etc.
• Will take longer to respond to code review and code review will take longer because PRs are disorganized and don’t have great summary or test plan. Colleagues are less likely to want to review such PRs. Colleagues have less trust in the PR and programmer behind it.
• Land code into main a greater amount of time in the future from when the PR was submitted

A pro engineer will:

• Submit code for review and spend a longer time here, very carefully explaining the PR, adding videos, screenshots, notes, and areas of question.
• Code review time is way faster due to step one being more complete
• Land code — takes less time, will land the code right away, this time should be as fast as possible.

The goal is that you want this cycle to to be super quick. The pro engineer explains very well what they are doing and anticipates the questions that other people will have in the test plan summary. This allows the PR review to be expedited.

Credit for image to Taro.

Quality

Create a plan

• Try to visualize your approach and come up with a plan
• Don’t jump right into coding, this is crucial with meatier tasks (greater than 3 days)
• Don’t just start coding your first idea, come up with alternative ideas
• Spend at least 15-30 minutes to come up with a plan for most features, even simple ones
• Come up with pros/cons of different approaches

The above idea matches some advice from a chapter in A Philosphy of Software Design by John Ousterhout. It is always a good idea to explore alternatives to your initial approach to a problem.

Submit clean pull requests

• Code is much more than the raw lines of code
• Make commits focused/atomic, 25-250 lines of code, otherwise robbing yourself of feed back that you need
• Explain what PR is trying to accomplish and how
• Proactively surface potential problem areas
• Mention on pull request if you think there are issues in your PR, be proactive
• Can mention code smells or areas you think are messy in your own PR
• Have a great test plan, show what the code is trying to do
• If on front end, 99% of the time you want to attach video or animated gif
• If backend, screenshot of postman, curl, etc
• Providing more info not only shows that your code works but also builds up confidence in your code in the eyes of the rest of your team
• Doing the above will also result in faster code review because it is easier to review
• Test plan should communicate a narrative, what changes the code makes
• State of world, made code change, new state of the world, explain this narrative
• Prove the change and how it looks/works
• Call out the significant lines of code (the import parts of the changes)

Treat code review feedback as a massive gift

• Respond quickly and with appreciation
• Ideally within 1-4 hours, 24 hour turnaround max
• Code review is one the primary ways you can grow
• Don’t make the same mistake twice, absorb the feedback, if you don’t understand the feedback, then ask questions
• Don’t be afraid to hop on a call to explain concepts in PR

Review code from others

• A couple hours per week to review code from other team members even if you cannot approve
• Help your teammates
• Find areas for improvement that you can make

Modularize your code

• Don’t put everything into one class
• Every component should have a single responsibility
• Naming is very important, use descriptive names to make this clear
• More modularization === increased flexibility === increased reusability

Keep it consistent

• Follow what the surrounding code is doing
• Even if the existing patterns are suboptimal, just do the same thing, having two patterns, even if one is better really makes the code harder to read
• If you are going to bring in a new thing, you need to migrate the whole codebase to use it
• It is better to just have one pattern, even if that one pattern is a little older
• If you are going to refactor, do a global scale refactor
• You can keep mental notes on things to improve
• Code following different patterns breaks the readers’ focus

Do the simple thing first

• Start off with the most basic and minimal frameworks
• By using the more primitive technology, you will understand the tech better
• Worst possible code is using powerful framework incorrectly

Make it a little better each time

• Pay attention to pain points
• Can you do the same with less code
• Can you make it more readable
• Can you make it faster
• Are there unhandled edge cases
• Note these things and discuss with other people

Where to go next?

Being proficient at coding is just the beginning. Writing code is operating at a local level. The next level is system design which involves the following:

• Channel code properly
• Understand relevant stakeholders and existing components

Conclusion and final thoughts

I enjoyed this webinar and found the advice to be true based on my own personal observations. I will definitely be focusing on making smaller commits and writing even more thorough test plans in my PRs as well as including more screenshots and explanations of how the code I’ve authored changes the state of the world.

I also plan to focus on shortening my cycle as a developer from submitting code to landing it in main.

Even though it is obvious, protecting time on my calendar to allow for uninterrupted blocks is something I will be more closely monitoring at work. I’ve noticed my own calendar being filled with meetings five days per week with fewer focus blocks.