How To Write Code 10x Faster Than Your Peers

After 10+ years as a full-time software developer, I have some ideas about how to be faster at coding.

But, many of these ideas didn’t come from being a great developer. Around year 10 of my career, I started building businesses. Those businesses taught me how to be efficient in a way that coding or acquiring certifications could not do.

My first business failed, so I was forced to go back to being a full-time developer. And when I returned to the industry, it astounded me how much faster I was at coding. This was despite me not practicing my craft for a few years.

How was I able to be so productive? Why did I get better at development despite taking a hiatus? Below you’ll find out all the everyday things I see holding developers back.

Learn To Handle Overwhelm

Software engineering and running a business can both feel overwhelming at times.

When an architect designs a building, he’s working with physical realities. We also have many other buildings to compare it to. And people generally understand the limitations of what buildings can and cannot do.

In software, your manager won’t know how to code, and they may not even know how to use a computer. He’ll make up what he wants on the spot and then change his mind a dozen times. He may not even ask for your input, he’ll create time-estimates out of thin air. It leads to a lot of unrealistic expectations that cause developers to feel anxiety.

For some developers, this anxiety helps them to be productive. Nothing like thinking your paper is due the next day to get you to crank out some work. But, for me? It used to paralyze me. If I know I can’t get something done in time, I don’t care if it’s 3 days or 3 months late. Late is late. I lose all motivation.

When running a business, you often face a similar situation where you can’t produce as much as you want. Imagine watching your business slowly go under as you fail to produce enough to keep it afloat. You learn to take things one day at a time, do your best, and block out the noise. Stop being so results-driven. It’s the only way to survive.

This skill will make you more productive and less likely to burn out than your peers. My newfound ability to handle this pressure was a huge advantage I had over my fellow developers.

Prioritize Tasks

When you’re trying to code, manage your git repo, continuous integration servers, stage+production servers, JIRA, scrums, other developers, managers, testers, etc. It’s a lot of things to manage, and it’s the tip of the iceberg. Plus, each task you add makes the list increasingly complex.

The key to both business and software engineering is prioritization. You can’t make all the things perfect. No-one can. All you can do is pick out what will have the most profound impact and work on that. Then repeat.

Most software developers will end up getting caught in the weeds on tasks that don’t move the needle. So while they’ll be busy every day, they won’t do a heck of a lot that actually matters. This simple mindset shift will cause you to dramatically outperform your peers.

Get Build Times Down To Zero

Task switching has major costs on your productivity.

I’ve worked on legacy products that take 5+ minutes to compile. It will absolutely kill productivity. Task switching is an incredibly inefficient use of your time. And when waiting 5-10 minutes for your project to compile, what else can you do?

With new projects, you can choose to avoid this. But, with older legacy codebases, you’ll have to get creative. For instance, one legacy Java program I worked on allowed me to edit HTML on the server in real-time. For any problem that could be fixed with HTML or JavaScript changes, I’d work on the server. Then I’d import that code back into my IDE after finding the solution.

Most software developers won’t find creative ways to get build times down. They’ll just sit there and deal with the constant task-switching. Being pro-active about this problem will make you faster than your peers.

Automate and Systematize Everything

On my last project, one of the junior developers was manually deploying our project to the server. He did this each time we wanted to demo new functionality to testers or management.

To him, it felt like he was working hard and doing a great job (and he was). But to me, it just looked like a waste. This is a task that took him 30 minutes to an hour every time, and it was error-prone. It’s also a task that could be easily automated.

I went ahead and did just that. It took me less than a day to set up auto-deployments on new check-ins. The deployments are no longer error-prone, and they don’t waste the staff’s time. Everyone wins.

Less Code is Usually Better Code

You can find exceptions to every rule, but typically the less code you write the better. When I see verbose code, it comes down to one of the following three issues.

1. You don’t understand data structures, creating objects, methods, or recursion.
2. You don’t understand the full capabilities of your language of choice. (Some library provides this functionality, and you’re not using it)
3. You’ve chosen a bad framework, or a legacy codebase has forced your hand. An example would be many Java developers used to find themselves in XML hell.
   

Very rarely does verbose code need to be that verbose. It’s almost always a type of code smell and should be refactored. The less code you have, the easier it is to maintain.

Don’t Be Afraid of New Technologies, But Don’t Run To Them Either

There tend to be two types of software engineers in this world.

1. The programmer that uses the same tool for every job.
2. The programmer that uses the newest tool for every job.
   

You don’t want to be either of these people. You want to find the healthy middle ground in-between these two states.

If you never adapt and learn new tools, you end up as the only Delphi developer left in 2024. Or you become a Java developer who adopts GWT because you’re scared to write JavaScript. Good luck building a modern website with that skillset. You’re irrelevant.

But, if you always use the newest framework, things are equally bad. The modern equivalent is React or Flutter for mobile app development. I’m not saying React and Flutter are a passing fad. I’m just saying Xamarin promised the exact same thing a few years ago. Do you really want to have a Xamarin app right now?

Let these technologies age a little bit before making your application dependent on it.

Think Outside The Box. Think In General.

A lot of developers are given a task, and they get to work immediately. I commend them for their hustle, but their work-ethic is stupid. They should be asking the following questions.

1. Why am I being asked to do this? Is there a better way?
2. Does this need to be done at all, or is it a big waste of time?
3. What obvious problems are going to arise if I build this the way I’m planning to develop this.
   

Managers don’t often know how to code. In that case, they will often ask you to do very non-sensical things.

Junior developers will say “how high” when managers ask them to jump. I usually say, “Wait, why do you want me to jump again? Maybe there’s a better way.”

Challenging management is easier said than done. But, avoiding stupid tasks is a tremendous time-saver and worth doing. This will make you much more productive than your peers who don’t do this.

Learn To Say No

Management will inevitably ask you to do something stupid someday.

If I told you to jump off a bridge, would you do it? I sincerely hope not, but too many developers would without a second thought. Don’t do things you know are stupid just because somebody told you to.

You need to learn to say no. It’s hard to do in the moment, but long-term, you’ll never regret not doing stupid things.

Don’t Re-Invent The Wheel

I worked with a new developer who wrote a little JavaScript library to create HTML popovers. He was showing it to me to go over how clever it was.

And it was clever enough, the problem is Bootstrap already did this better than we ever could 8 years ago.

When the wheel already exists, use the wheel. If you don’t want to use the wheel, you best have an excellent reason for it. Otherwise, you’re wasting everyone’s time maintaining this monstrosity.

Use The Best IDE / Computer You Can

I’m a huge fan of pretty much every IDE that JetBrains puts out. IntelliJ, Rider, AppCode, PHPStorm, etc. They’re all great. The problem is they cost $20-ish/m. Many developers won’t even try them because of the cost. This is astounding to me for two reasons.

1. These tools increase my productivity by 40% or more.
2. Full-time software engineers are typically making $50k-$150k/yr. Trading $20/m for a 40% productivity increase is a no-brainer.
   

It’s astounding to me that businesses don’t bend over backward to get their software engineers the best computers and tools. But that’s a topic for another day.

Equally astounding is that developers are so unwilling to invest in themselves. I understand how you may not care about your job, but trading $20/m for a 40% productivity gain? That reduces an 8-hour workday to under 5 hours. You’re also going to be getting raises and promotions that cover the expense. Not to mention working code is more fun to play with.

And I understand employees usually aren’t in control of how powerful their work computer is. But, if you are in control, it’s the same thing. How much is a 15% productivity gain worth to you? You can get a great computer for $500 these days. It’s tough to understand why developers are working on 5-year-old machines.

Find a Good Teacher / Mentor

People go to college for 4+ years to become software engineers, and then they’re great at coding, right?

Eh, not so much. During my career as a software engineer, I very rarely meet recent grads who are good at coding. Let alone great.

However, I find the new developers that have great mentors become good developers themselves. Meanwhile, the developers with bad mentors struggle. If you’re a developer, I strongly encourage you to find developers who are better than you at coding. Try and learn from them.

Watch YouTube Videos

I remember buying a subscription to O’Reilly books in 2006. I did so because these books were the only place I could find information on obscure new frameworks we were using.

These days you’ve got StackOverflow that seemingly has an answer to everything. And for more in-depth knowledge-transfer, there’s usually a YouTube video. It’s truly incredible.

I’m incredibly jealous of the resources new developers have at their disposal. Use these tools! You’d be surprised how many developers haven’t realized that all of the answers exist in video format right now.

Take a Nap and Eat Something

You are not a machine. Eating, sleeping, taking breaks, etc. are all very important to your overall productivity.

Many developers have such a need to please, that they’ll sacrifice their own health to meet deadlines. Don’t do it. Your health is all you have. It’s much more important than an arbitrary deadline set by a middleman who doesn’t know how to code. High-level management will deal with him in due time.

In the meantime, recognize that in hours 6-10 of coding, you’re nowhere near as productive as in hours 1-5. So stop trying to force it. Eat, nap, live your life. Come back tomorrow and be productive again.

Follow My Other 12 Steps To Be Productive.

I wrote an article about how to be more productive that had nothing to do with software. Those tips will make you the best programmer imaginable.