Want to know how to program faster so that you can deliver software faster? Sure, who doesn't? The internet is full of tips for developers—hundreds, thousands, perhaps even millions of them. The problem is, there are far more out there than anyone has time to read, so I've boiled them down for you.
Here are 53 tips representing the very best advice I've found out there. But, before I tell you what I found, I need to explain what I mean by "programming faster," and "tips."
The problem with "faster"
To code faster, one has to be efficient; that is, no wasted effort or motion. This can mean everything from typing to tools to thinking. But most of our work as programmers isn’t typing, or compiling—it’s thinking. To think faster, you have to learn more patterns and relationships. This is the knowledge and wisdom that experience builds. What you need to go faster will change over time.
The problem with "tips"
Most of the tips I read only apply at certain points along my journey, and don't necessarily apply to everyone. Many of these fall into the “personal journey” or “what worked for me” categories. But my path is probably not your path. While some of the mechanical things that work for me will probably work for you, many of the domain and pattern choices I made may be of no use.
The mechanical stuff is pretty easy to optimize; the options are limited. But the learning stuff has no limits. No one will ever know it all. You must make strategic and tactical choices, and be prepared to take advantage of opportunities when they arise.
The utility of tips falls off as a function of specificity. The more specific tips don’t apply to everyone, but general tips are too, well, general. They’re much more difficult to turn into action. So what do you really want when you say you want to "go faster?" I'll tell you.
What you want is flow
What every programmer wants, especially in the era of DevOps, is flow. Flow state maximizes throughput and increases enjoyment by incorporating just the right level of challenge; one stays fully engaged in the moment and in the work (this is not to be confused with the Ballmer Peak). Sustaining flow state requires a suitable environment and frictionless process.
Flow state when pairing is like each of you having an extra brain. Unfortunately, many developer environments, such as open offices, are unfriendly to flow.
Your options may be limited
When you find something sub-optimal about your process, or yourself, the choices of how to address such constraints are limited:
- Ignore it. Maybe it will get better on its own.
- Avoid it. Is it really necessary?
- Automate it. Make the machine do it.
- Delegate it. Rarely possible, this is passing the buck. But it is a legit option when available.
- Grind it down. We all have to do this from time to time (daily). Some jobs are larger than others.
If your typing is slower than you’d like, take a little time and level up. If your integrated development environment is confusing and unhelpful (or perhaps too helpful), try something different or simpler. If you can’t get away from it, learn more about it; you may find another way, or at least learn the limits.
There are numerous ways to learn. Google is your friend, as are books, videos, blog posts, Stack Overflow questions, and, of course, other people. Some things you want to learn may be hidden; others may be larger than they appear. Balance benefit with effort and be patient with yourself. Celebrate every achievement and keep moving.
Top tips for programming faster
One way of grouping and looking at the tips below is by applying a few high-level categories as a way to draw interesting generalizations from the collection:
- Reflect. What do you want, what do you actually do; includes measuring and optimization.
- Flow. No friction from tools, processes, environment, or knowledge; seek continual challenge but not too much.
- Learn. The fundamentals: languages, tools, patterns, practices, etc., from everyone (especially those willing to teach); learn how you learn, and learn continuously.
- Teach. Teach others. Having to explain things forces simplification, and the transformation from thoughts to verbal or visual expressions produces insights.
- Express and explore. Look outside your normal duties; draw, write, blog, go to meetups, attend and give presentations, talk to Wilson the volleyball if need be.
The tips below are simply data points, things to ponder—not a cheat-sheet for life or a to-do list for your career as a programmer. I started with a list of 183 tips, grouped them into categories, assigned a priority based on repetition and personal bias, and took the top few from each.
That’s right, bias. I know what makes a developer good or fast programmer, so everything I read I filtered through my bias. Specifically, I’m biased toward:
- Agile methods.
- Domain-driven design.
- Automated testing.
- Continuous improvement.
- Minimal solutions.
- Frictionless tools.
- Working in flow state as much as possible.
And I strongly agree with Robert C. “Uncle Bob” Martin's statement on "vehement mediocrity":
“The only way to go fast is to go well. Every time you yield to the temptation to trade quality for speed, you slow down. Every time.”
Take the following tips (and everything else you read on the internet) with a grain of salt. Keep and adapt what works; discard what is useless.
And here's my tip for programming faster: Focus on quality, and speed will follow.
Reflection is key
Reflection is the key to self-improvement:
- Continually improve your decision-making process; learn from your mistakes without reproach.
- Eliminate blind spots in your understanding of the entire scope of your application and its execution environment.
- Don't chase your tail; identify and eliminate time sinks.
Measure objectively
Sometimes you know what your biggest constraint is, and sometimes you have to measure it.
- Consider doing a detailed audit of yourself as you work for a couple of days.
- It is just like optimizing any piece of code. Log everything, identify hotspots and improve them.
- Where does your time go? Many programmers spend far more time reading code than writing code; how do you learn to read code faster?
Practice, practice, practice
There’s no getting around some level of practice, on a variety of challenges.
- Write lots of software.
- Write bigger programs.
- Write review-ready code from the get-go.
- There are plenty of places to practice, including topcoder.com, project Euler, hackerrank.com. Chooses one and get going.
Design for success
Learning design techniques should be a given, part of the mastery of your thinking tools. In addition:
- Understand the user; understand their problem, the real problem; and then solve it. Knowledge of the domain helps immensely.
- Talk to colleagues and domain experts about the problem, solution, and design.
- Reduce cognitive load by drawing or writing while you think and code.
- When designing for longevity and maintenance, remember that data outlives code.
- Know when to reinvent the wheel, and when not to (usually not).
- Name things purposefully; this is the only link from the code back to the domain.
Nail the process
We spend a lot of time in processes of our own construction; don't be afraid to change them.
- Make bugs impossible by design. Fail fast, use exceptions instead of null checks, use the type system to prevent data errors, and use automated testing.
- If you’re at a loss on where to begin, start with the part that you understand best.
- Write the code that would actually make a product first, no matter how silly or small that product is.
- Do not ignore errors; every error means something.
- Follow an agile approach to development.
- Pull out abstractions only if they make sense and would actually be reused.
- Stand on the shoulders of giants; use open source libraries, third party solutions, and so on.
- Optimize for simplicity; the best code is the code you don’t have to write.
- Automate testing and practice test-driven development (TDD)
- Use smart tools such as IDEs, code generation utilities, etc., but don't be afraid to down-shift if they're getting in your way.
- Be extremely familiar with your language and standard library. The less time you spend crawling around in the documentation, the better.
- Use source control — even on your own.
- Use a profiler. Optimize only what is necessary
- Learn to touch-type. Programmers type a lot, and not just code; this reduces the cognitive load of typing to zero, and improves speed and accuracy
Create the right work environment
Constant interruptions, uncomfortable circumstances, and endless meetings discourage flow.
- Make sure that you are in an environment that will not distract you; make it impossible for distractions to interrupt you.
- Know yourself, and work during your peak time — not someone else's.
Explore outside of work
Not everything you might want to know is in your office or on the Internet.
- Expose yourself to new tools and techniques. Keep what works.
- Work on side projects and open source projects.
Keep it healthy
Dead people write no code. Sick people write bad code. Take care of yourself.
- Know the value of stepping away from your code.
- Get more sleep, eat better, and work fewer hours.
- Meditate.
Develop good learning habits
Learning is a life-long process for programmers, but we warned: The internet is full of shiny things.
- Master the fundamentals: programming paradigms and practices such as DRY (don't repeat yourself) and and SOLID (single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion)for OOP), patterns and anti-patterns, algorithms, data theory, graph theory, etc.
- Learn by doing. Always play with the code while learning.
- Find a mentor.
- Explore different ways of learning to see what works for you.
Quality is not constant
Quality covers a lot of ground, from the readability of the code to its modular structure and complexity, to how well it expresses its domain intentions.
- Focus on quality, not speed.
- Accept that code “quality” at any given moment is “the best you can do with what you have and know.”
- Always do your best; it’s good practice.
- Only in extreme (i.e. prototyping/exploring/throw-away code) and temporary circumstances should you let the quality of your code drop below the level of “the best you can do” (and you should feel slightly ashamed at doing it.)
Soft skills matter
I didn't find a lot of tips about people skills, but people are pretty much unavoidable; those I did find were quite helpful.
- Knowing how to interact with people will let you learn from and teach those around you with less friction and more joy.
- Learning to write and speak clearly will help you get your ideas across faster.
Go forth and code
So that's it, my summary of the best advice out there for programming faster. Follow these tips and you'll be well on your way to improving your programming skills—and coding faster.
Don't see your favorite pearls of wisdom above? Add yours to the list by posting it in the comments section below.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
