My goal is to become extremely efficient at coding. I want to build a reputation as someone who is able to deliver tons of high-quality implementation and products very quickly. I want to build actual velocity where the actual rate of code per hour/day is really high as opposed to just being able to accomplish more from working extra hours. What tactics can I use to level myself up in this way so that my old coding abilities feel unrecognizable when looking back 3-6 months in the future from my vast amount of improvement?

I built a reputation as a "code machine" back at Instagram - I had 250+ commits and 700+ diffs reviewed per half, even after growing into a tech lead with a bunch of meetings. So I'm happy to chime in here and share some reflections on how I was able to do this. At a high-level, you become a code machine by writing a ton of code. There's no way around this, 10,000 hours and all that. However, this raw coding effort does need to be guided in crucial ways - You can easily write a lot of code and still be slow and write low-quality code. Here's my advice on how to do that. Go Deep, Not Wide After I found out that I truly loved doing Android development, my goal was to turn it into a superpower. This is why I've been doing Android for 8 years now. More specifically, I love being close to users and putting pixels on screen. So my goal was to become extremely good at Android product/UI, which made my expertise even more focused. Build the same components over and over again. When it comes to consumer apps for example, there are many common patterns, with the most common one being loading a list of items, usually from an API call. This organically led to me building things like a content list dozens of times, which turned it into muscle memory for me. Figure out what the "content list" equivalents are for you in your space and get extremely good at those. Side note + benefit: I remember doing my Robinhood onsite interview, and the practical Android coding challenge was to build a small content list app. I was able to finish it 20+ minutes early, because I had become such a master of this component - This was easily the funnest and most trivial part of the interview for me. Make Things A Little Better Each Time This is the next crucial ingredient. If you aren't seriously reflecting after every time you build something and trying to poke holes into it, you will write the same hacky code every time. This means your growth is only in the velocity axis instead of quality, which is less impressive as a code machine. My first content list in Android was horrible. It had a very limited API, was buggy, and the code was very messy. Every time I rebuilt a list in my new Android project (which would involve me copy-pasting code), I would ask myself if I could make it just a little bit better (after all, I had this time save from the copy-paste). In particular, I would see what was painful in this new integration and try to solve that. And now after writing a content list in Android 100 times, my most modern iteration is very clean and performant (and it's still getting better). If you're unsure how to make things a little better each iteration, here are some ideas: Can we have the same effect with less code? Is there a lot of duplicated code/boilerplate in the current approach? Are there unhandled edge cases? Maybe it crashes with bad inputs, too many items in the list, etc. Is the code easy to read? Is the code performant? Does it do the core task within just a few milliseconds, or is it something longer that's very noticeable? Build Side Projects Side projects are sort of a "hack" to get yourself better at coding without just over-working yourself. You get to write more code (and probably for a thing you're more passionate about) outside of a work setting. For years, I would come home from work and do something in my side projects for 1-2 hours. This was usually addressing the latest user feedback. However, YMMV with side projects. It was much easier for me as I work on the product/front-end side and Android apps are extremely easy to deploy. If you're further away from the average user, things get harder. Manage Your Time Very Deliberately In particular, build a very strong flow state. You want to have as many uninterrupted periods where you just code and build as possible. One very tactical work advice is to try to concentrate all your meetings on certain days, so you can have 1-2 days where you just code. The goal is make it so that whenever you get 2+ hours on your code to build, you can get a lot done. Related resources: This Is How Software Engineers Should Initially Learn [\[Masterclass\] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/) [\[Masterclass\] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/) [\[Masterclass\] How To Manage Your Time Optimally In Tech And Achieve More Results](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/masterclass-how-to-manage-your-time-optimally-in-tech-and-achieve-more-results/)

How can I write great code faster?

I built a reputation as a "code machine" back at Instagram - I had 250+ commits and 700+ diffs reviewed per half, even after growing into a tech lead with a bunch of meetings. So I'm happy to chime in here and share some reflections on how I was able to do this.

At a high-level, you become a code machine by writing a ton of code. There's no way around this, 10,000 hours and all that. However, this raw coding effort does need to be guided in crucial ways - You can easily write a lot of code and still be slow and write low-quality code. Here's my advice on how to do that.

Go Deep, Not Wide

After I found out that I truly loved doing Android development, my goal was to turn it into a superpower. This is why I've been doing Android for 8 years now.
More specifically, I love being close to users and putting pixels on screen. So my goal was to become extremely good at Android product/UI, which made my expertise even more focused.
Build the same components over and over again. When it comes to consumer apps for example, there are many common patterns, with the most common one being loading a list of items, usually from an API call. This organically led to me building things like a content list dozens of times, which turned it into muscle memory for me. Figure out what the "content list" equivalents are for you in your space and get extremely good at those.
- Side note + benefit: I remember doing my Robinhood onsite interview, and the practical Android coding challenge was to build a small content list app. I was able to finish it 20+ minutes early, because I had become such a master of this component - This was easily the funnest and most trivial part of the interview for me.

Make Things A Little Better Each Time

This is the next crucial ingredient. If you aren't seriously reflecting after every time you build something and trying to poke holes into it, you will write the same hacky code every time. This means your growth is only in the velocity axis instead of quality, which is less impressive as a code machine.
My first content list in Android was horrible. It had a very limited API, was buggy, and the code was very messy. Every time I rebuilt a list in my new Android project (which would involve me copy-pasting code), I would ask myself if I could make it just a little bit better (after all, I had this time save from the copy-paste). In particular, I would see what was painful in this new integration and try to solve that. And now after writing a content list in Android 100 times, my most modern iteration is very clean and performant (and it's still getting better).
If you're unsure how to make things a little better each iteration, here are some ideas:
- Can we have the same effect with less code?
- Is there a lot of duplicated code/boilerplate in the current approach?
- Are there unhandled edge cases? Maybe it crashes with bad inputs, too many items in the list, etc.
- Is the code easy to read?
- Is the code performant? Does it do the core task within just a few milliseconds, or is it something longer that's very noticeable?

Build Side Projects

Side projects are sort of a "hack" to get yourself better at coding without just over-working yourself. You get to write more code (and probably for a thing you're more passionate about) outside of a work setting.
For years, I would come home from work and do something in my side projects for 1-2 hours. This was usually addressing the latest user feedback.
However, YMMV with side projects. It was much easier for me as I work on the product/front-end side and Android apps are extremely easy to deploy. If you're further away from the average user, things get harder.

Manage Your Time Very Deliberately

In particular, build a very strong flow state.
You want to have as many uninterrupted periods where you just code and build as possible. One very tactical work advice is to try to concentrate all your meetings on certain days, so you can have 1-2 days where you just code.
The goal is make it so that whenever you get 2+ hours on your code to build, you can get a lot done.

Related resources:

Alex's answer to this is amazing.

The one thing I'll add is that, as you progress in your career, it'll become far more important what you're working on, in addition to how. Every senior coder has seen the following two things:

Months/years of code down the drain because the project was misguided.
Hours/days of code with a fundamental architecture flaw that has to be rewritten.

It's faster to walk in a straight line than to run serpentine. In addition to building out your skills around coding quickly (which I completely agree is essential early in career), also look to learn telltale signs that a project is headed the wrong direction, or a code path you're taking will need to get ripped out.

How can I write great code faster?

Discussion