DEV Community

Cover image for How to Become a Faster Programmer
Marcin Wosinek
Marcin Wosinek

Posted on • Updated on • Originally published at

How to Become a Faster Programmer

So you’ve already managed to achieve your first programming goals, maybe developed an example application for two. Great! However, it was a bit slow, and a professional developer would for sure be much more efficient with it. So now your question is this: how to become faster at programming?

Try to get feedback as early as possible

If you are a beginner, it’s safe to assume that there will be many ways to improve your code. If the application works as expected—maybe your solution was a bit hacky. If the approach is OK—maybe you forgot to apply a code style before committing. Or perhaps you made one of many tiny mistakes while using Git, which could be as subtle as using the wrong tense in your commit message.

From the perspective of your senior colleague or mentor, it’s impossible to predict what could go wrong. You need to bring your output to a review, and then there, it’s possible to correct the direction in which you are moving. The sooner you reach out for the feedback, the faster the whole process will be. For example:

  • write up how you think the issue can be solved before you start changing code
  • draw wireframes of the interface before you start building it
  • create a merge request for the implementation before you update all the unit and e2e tests

A task doesn’t need to be fully completed before you ask for a review. Reviewing things is fast, and if you are lucky, then your colleagues will be able to review before you spend too much time following the wrong path. It’s a writing vs. reading difference—I spend about 3 or 4 hours writing articles, and it’s probably 10 minutes reading time for you.

Write fast?

Or rather write little? Your job is to solve problems—not to write code. If you can solve problems fast (or faster than you create new ones), then you are doing well in your job. The code output you produce is part of the problem—it will need review, testing, and maintenance over a long time.

Learning resources are focused on exposing you to concepts they try to teach you. In the case of programming, they will show you some exercise project or task and make you program to resolve it—without questioning whether it makes sense. Good performance at your job requires you to write code only if there is no better solution available.

Question all requests

First step: make sure that ‘what is needed’ is indeed needed. Sometimes you’ll get a request to add a feature that shouldn't be part of the system. Or there is already something in place that the user or your colleague who wrote the ticket is not aware of. Or the request is for a ‘nice to have’ thing, instead of something really important.

In short—try to understand the requirements well enough to be able to evaluate whether they are indeed necessary.

External providers

In the end, there is no way to talk your way out of adding features to the system. The next best solution is to find an external provider to do the heavy lifting for you. For example:

  • a cloud provider for turning address input from free-text to a location on a map
  • a complete payment solution—for online or physical stores
  • a mailing service that lets you send emails without worrying about spam filters

Integrations are often a headache, but if you find a provider with a good API, it can save you a lot of time on writing and maintaining your own code.

Use third-party libraries

Some tasks are too small to abstract them away from your application and obtain them from an external tool. For many typical and less typical needs, you can find a third-party library that provides some help with these. Libraries comes with a trade-off:

  • they provide a solution for some issues
  • but require you to learn their API
  • and sometimes bring their own problems

If you pick the wrong library, it can cause you a lot of pain. There are some things about a library that you can evaluate before deciding to use it: the documentation; how the project looks on GitHub; comparisons with other options online. Other things about the library, not so much: what future the library is going to have and whether it will be maintained as long as your project needs it.

What kinds of things libraries provides us:

  • methods for operating on dates
  • money related features—so you don’t have to worry about result of 0.1 + 0.2
  • generating charts

Reuse your own code

You are slowly running out of options. But before you write anything new, make sure it hasn’t already been implemented in your project. Also determine whether some very similar case that already has code can be reused here.

Reusing code is tricky—it saves you time when you use the same code in related use cases, but it will create problems if you reuse code for unrelated cases. For example—adding and subtracting works the same for temperature and money; until someone introduces support for absolute zero. You wouldn’t like your application to crash as soon as the account goes below −273.15.

Write good code

When all that fails—write as little as necessary to fulfill the need, but write it as well as you can. Name classes, methods, arguments, and variables in a meaningful way. Document the code. Write unit tests and some integration tests as well. Add a commit message that explains what is happening in the code and why.

In short:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Repeat the whole process

Once you are done with the feature you’ve been working on, you are ready to go to the first point and start again.

Don’t rush

No worries, nobody programs fast. Have you heard the 10x developer myth? Supposedly, some developers are 10 times faster than their peers—maybe there are some geniuses out there, but I’m afraid in most cases people move fast by cutting corners. Taking shortcuts can be necessary in the short term, but doing so creates technical debt that needs to be addressed for the long-term health of the project. Hence the response to this myth: 10x devs are the ones that need 10 devs to clean up after them.

Real life

Day to day jobs are full of situations that could trigger the sensation of being slow. The other day, I spent 2 hours trying to connect a network printer—and my solution required moving it to a living room. Every so often, I spend hours troubleshooting an issue that was caused by some minor problem—a typo, chasing the bug in the wrong place, or any other stupid mistake.

Am I hard on myself for those ‘failures’? No. Why? It’s part of the job—sometimes you deliver a solution fast, sometimes it takes more time.


As a junior programmer, your job is to learn stuff and find ways you can help in the project. Every reasonable person understands that learning requires time. In a good workplace, you will receive the support you need to progress and won’t be pressured to develop faster.

For me, fast junior programmers sound scary. I would rather have a slow junior colleague that gets things right eventually. Fast learners, responsive to feedback—that sounds great. But one that just pumps out changes quickly—not so much.

Top comments (18)

wadecodez profile image
Wade Zimmerman

You'll get a huge burst of speed when you learn how to use an IDE and a debugger. This allows you to read source code and follow the call stack. Once you've mastered these tools you rarely need to use documentation.

cubiclesocial profile image

I generally avoid IDEs wherever possible these days. They have their place for solving difficult problems after code has been written but they generally just get in the way while writing code and I find myself shaking my fist in the air at the devs of every IDE I've ever used for doing dumb things.

For example, I'll start typing the first character of a new line of code and the IDE will decide to live syntax check right then, hang the whole IDE for a solid 3 seconds, and then kindly let me know that there is an error in the syntax. Well, duh - I typed the first character of a new line of code!

I generally just use a plain old text editor (without syntax checking, autocompletion, etc.) and command-line tools and only fire up an IDE if I absolutely have to. So whenever I do fire up an IDE, all of my pet peeves with IDEs bubble to the surface again from long startup times, annoying project management tools, unnecessarily large amounts of RAM usage, massive CPU spikes, insanely long compile times, a window the size of a postage stamp to write code in, broken builds/projects requiring wasted hours to figure out which cache has to be manually deleted, IDE crashes and restarts, etc. The list is pretty much endless and some of those problems are exaggerated a bit but IDEs are mostly broken by design. I always breathe a sigh of relief and my stress levels drop when I can close out an IDE and go back to my regular workflow.

However, I've been developing software for a really long time. After writing software for many years, the fancy stuff stops being useful and starts getting in the way. A reasonable comparison is training wheels on a bicycle. Eventually, a person doesn't need them and the training wheels will even get in the way of riding the bike as it was intended.

My text editor of choice and the one I'm most efficient in when writing software and documentation is Crimson Editor, which was last updated in 2004. It's most definitely not for everyone. I'll occasionally fire up Notepad++ as well but even Notepad++ does obnoxious things that drive me nuts such as "forgetting how to syntax highlight and suddenly decide that the entire file is a comment" every so often.

iseiryu profile image

Which tech stack do you use? Sounds like C++ or COBOL. I've been programming for a couple decades too and stopped complaining about IDEs around 2012. Mine are as fast as a plain Notepad when it comes to the typing responsiveness and 1,000x faster when it comes to the actual development.

elnobun profile image
Ellis • Edited

I love this post very much. After many years of software development, the day it settled in me that simplicity is the best approach to problem solving, my career transformed for the best. I became less worried, had less sleepless nights and developed a better lifestyle.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
— Martin Fowler

We don’t have to say yes to every project. (I wish I knew this earlier in my career). Although this may be different based on company/team size. Mental health is very necessary for optimal learning. When burnout begins, learning stops.

Speed is good, Efficiency is better

marcinwosinek profile image
Marcin Wosinek

Thanks a lot for your comment!

aarone4 profile image
Aaron Reese

Install a snippets extension to your ide. Learn ALL the keyboard shortcuts for your ide. Learn to touch type. Use a linter to format code and pick up poor practices. Write code in a consistent manner so that you and your peers recognise the code patterns.

marcinwosinek profile image
Marcin Wosinek • Edited

Those are good tips as well:)

IDE? ;)

leob profile image

I think the point is not so much at being fast, not even about being efficient, but about being effective ... you can implement a solution super quickly, but if it's not the solution anyone wanted or needed then I'd argue your actual speed was zero ... :)

On the other hand, "fast" is probably easier to quantify (LoC or whatever) than "effective".

marcinwosinek profile image
Marcin Wosinek

Oh, that's another big topic to cover. There are people many hours thinking and testing what the users would use, and pay for—product designer, etc. You can easily burn a lot of time and money building something nobody care about.

leob profile image
leob • Edited

And I'm sure that that happens all too often :)

cubiclesocial profile image

However, it was a bit slow, and a profesional professional developer would for sure be much more efficient with it.

User Use third-party libraries


Third-party libraries are pure technical debt. Each dependency creates an exponential increase in difficulty to upgrade those libraries later on without breaking the application. Third-party libraries are necessary for exceptionally difficult topics that people usually get wrong (e.g. cryptography) or would take an inordinate amount of time to implement correctly (e.g. image processing). But developers purchase ALL of the technical debt of that third-party library or software when using it. For example, if someone makes an Electron app, they implicitly purchase all of the technical debt of developing a web browser from feature development to security issues whether or not they like that concept.

Here's a good rule of thumb is to evaluate whether to create a library from scratch vs. using an existing library: If a sufficient library with a stable API already exists, it would take more than a month to create an equivalent solution, there's no particular business reason for creating a first-party library, and the additional technical debt is acceptable to take on, then the occasional third-party library is probably fine to use.

marcinwosinek profile image
Marcin Wosinek

Thanks for your comment and pointing out the typos!

bradtaniguchi profile image

There is one aspect that can be overshadowed when trying to be "fast".

It's empowering others to move fast as well. It's one thing to be a 10x developer, it's another to work in such a way to help empower others so you become a multiplier.

Some things inherently will help you increase your own speed, but spreading out those gains is how you can really impact.

Plus who doesn't like working on stuff that is inherently easy to work with?

marcinwosinek profile image
Marcin Wosinek

Very good point! Actually I should write a continuation to this post with the focus on team-productivity, not individual one.

ioannisnoukakis profile image
Ioannis Noukakis

Learn the value of unit testing and test driven development. Its a small investment that will result in a massive increase of code reliability. Making you the 'reliable' guy

marcinwosinek profile image
Marcin Wosinek

True! Fixing bugs that shouldn't be there doesn't let you focus on developing new stuff. I touched this topic in another article: What’s the point of unit tests?

ben profile image
Ben Halpern

This is a solid post, thanks!

marcinwosinek profile image
Marcin Wosinek

Thanks a lot!