There was a time when I believed that becoming a better developer was all about learning more, knowing more, and mastering new languages. But then I realised, it’s not just about being better—it’s about being faster. Fast enough to impress, delight, and sometimes even save the day. Today I want to talk a little bit about working faster as a developer.
Why do you want to move fast?
The faster you work, the more experience you get in the same amount of time. As I’ve blogged about before, experience density is incredibly important for getting ahead. Secondly, the faster you go, the faster your customers get the value you’re creating, and this is particularly important in start-ups and small businesses. I think the time when these skills are most valuable is when things are going wrong. Mastering the skills to code, troubleshoot, and work faster is crucial during downtime issues, critical bugs, or urgent matters that can make you the hero of the office and hugely valuable to your company.
What working fast doesn’t mean
I don’t want you to think I’m advocating for rushing in this blog post. Working fast does not mean rushing. It does not mean putting out lower-quality work. It does not mean skipping steps. And finally, it does not mean putting out a worse product your customers hate. Working fast is working to your usual high standards but simply in a shorter time frame. With conscious effort and practice, you can make it happen.
It’s all about habits
If there’s one thing that I’ve found to be scarily true, it’s that habits accumulate. Good habits speed you up, and when they build up, you can go faster and faster. But the opposite is also true; bad habits can slow you down, and when you have many bad habits, you can approach a glacial pace. This post is about habits. Habits you should work on over and over again, collecting more and more as you accumulate to approach the most efficient version of yourself.
Why should I?
You might think “Why should I work faster? It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime; so where's the motivation?” This is true. I’m not advocating you work at 120% every day at the office only to burn out to a crisp in weeks. And I certainly don’t advocate it if you feel you won’t be recognised for it. Good companies with good managers will recognise it (bonuses etc) and these companies will open doors faster for you than they would for others. And of course finally, you have your own ethics, values and craftsmanship to consider when deciding how much effort to put in. Do what feels best for you.
Mindset and Approach
Develop a Sense of Urgency
This idea is borrowed from the retail space, where work happens quickly in order to keep a store running smoothly. If you want to move fast, you have to want to move fast. It’s not about rushing or cutting corners, but rather about cultivating a mindset where you’re driven to deliver value swiftly. A sense of urgency doesn’t come naturally—you have to cultivate it.
Understand the Big Picture
Stepping back to understand the broader concepts behind what you’re doing can speed you up in the long run. For example, don’t just learn how to use AWS SQS; understand the concept of queues, messages, retries, visibility, etc. so that when you encounter similar tools like Azure Queue Storage, you can adapt quickly. The effectiveness of mapping existing knowledge onto new concepts depends on how strong that existing knowledge is—so keep expanding it.
Be Aware of your Surroundings
It’s highly likely another developer has solved the same problem you have. Keeping an eye on your team’s work channels, emails, sprint reviews, etc will help you learn what others are doing. Keep a mental note of it all, so you can seek help from others or their code when needed. You can do things like searching slack or emails to help you recall. Encouraging your team to ask questions and share knowledge in public forums can benefit everyone, even if it feels a bit awkward or embarrassing. It also helps to build a network in your team and company to collect the set of gurus who can help you with various things. And pay that forward—if you become a guru in something, be approachable as well.
Slow Down to Speed Up
Sometimes, the fastest way forward is to slow down and learn something properly. Don’t just hack away at tasks to get them done—take the time to fully understand what you’re doing, and you’ll move faster in the long run.
Mastering Your Tools
Master Your Language
Whether it’s TypeScript, Python, or any other language, having the syntax in your muscle memory is crucial. Practice regularly, beyond just your backlog tasks, to make sure you’re always sharp. Finding solutions for tricky parts is just as important as mastering the language itself. Go write a few lines of code for practice.
Use IDE Extensions to Your Advantage
Your IDE is a powerful tool, but it’s only as good as the extensions you use. Regularly explore new extensions and ask colleagues for recommendations. For instance, tools like JSON to TS or Toggle Case can save you loads of time. Share the ones you find, and even set them up in your code templates so fellow devs are promoted to install them. Also, if you see a colleague do something when you’re pairing that looked fast or magical - stop and ask them how they did that– you want that power too! It’s worth asking your colleagues for their recommendations as well anyway.
Use Terminal Aliases and Dotfiles
Long commands slowing you down? Create aliases. For example, gco for git checkout or gcob for git checkout -b. These small shortcuts can add up over time. Keep your dotfiles updated and use them everywhere you go. You could even think about creating a standard set for your team. Consider uploading your dotfiles to GitHub.
Lean Into Your Tools
Tools like TypeScript (over JavaScript), Unit test frameworks, linters, formatters can save you so much time. Lean into these tools, understand their features and benefits, and make the most of them. Be on the lookout for more tools that you can add to save you time. Ask senior developers for tool recommendations that could benefit your team.
Be an Expert in Your Tools
Spend hours a day in tools like VS Code, AWS, or GitHub? Make sure you know them inside and out. Learn the shortcuts, understand the error logs, and know when to restart your tools. Mastering these tools shaves precious seconds off your workflow. Let’s say you’re a VS Code User, you’re in it eight hours a day. Do you know the shortcuts? Do you know multi-cursor editing? Do you know how to see logs for extensions? Do you know when your extensions aren’t kicking in? Do you know when it’s time to give up and restart VS Code? If you’re using something for eight hours a day, there’s little excuse to not know your tools inside and out. This is a sign of any good craftsman. It could be helpful to watch some tips and tricks videos on your IDE.
Efficient Workflow Practices
Copy and Paste Effectively
Let’s be real: copying and pasting is a developer’s best friend when used wisely. But the key is knowing when to start and when to stop. Don’t just blindly copy code; understand it, and make sure it fits your current context. Sometimes, it’s better to copy the idea rather than the actual code. Ask yourself: 'Surely another team has solved this' (and go look at their code) or 'Surely I’m not the first person to do this' (and go to Google/StackOverflow/CoPilot). On the team idea - its a good idea to keep a bit of a mental map of what other projects your team or wider team are working on, to give you some places to check. Paying attention to work going on around you pays off in all sorts of ways, but this is one I’ve enjoyed a lot. Consider unmuting those Slack channels now :P
Search Documentation Smartly
When you’re deep in the weeds, knowing how to efficiently search through documentation can be a game changer. Use shortcuts like Command + F in Chrome to find what you need quickly. However, when you’re new to something, it pays to slow down and read the full documentation to get a comprehensive understanding. The better your mental model of what should be in the documentation, the easier it is to find what you need. Finally, you’ll realise there’s a few popular tools for documentation out there that a lot of OSS uses and so eventually you’ll develop skills for quickly finding the search bar or toggling dark mode, even on unfamiliar websites.
Another part of this tip is knowing how to quickly access the documentation for your tools. Command clicking on method definitions, or googling certain terms, or having it bookmarked. Work on reducing the lag time from deciding you need to look something up to being in the right place and reading it. You should also be very efficient with the documentation you use regularly.
Shorten Your Debug Loop
The debug loop is the time between writing code and seeing if it works. Aim to shorten this as much as possible—ideally to just a few seconds. Setting up a quick debugging environment or even creating a small test project can pay off in the long run. Learning to enable debugging (or at least logging) in your tools is crucial, as it will save you time repeatedly. Consider ways to shorten your debug loop on your current task.
Bookmark Everything
Websites, code snippets, curl/postman requests—if it’s useful, bookmark it. This way, you’re never more than a click away from the information you need, or you once had. Both physically bookmark it (in a tool like your browser or snippet library) and mentally bookmark it – so you remember you have it stored. A forgotten bookmark is of no use to anyone.
Scale Yourself
If you’re creating packages or working on shared code, document it thoroughly. The more you document, the less time you’ll spend answering questions about the work later on. If you contribute 10 internal code packages to your team, but don’t document them – can you imagine how your days will look? You’ll be bogged down answering questions. However, a good readme or changelog that does the talking for you can free you up for more interesting things. What is essentially happening here is your past work is working for you without you doing anything. It’s what this blog post is doing for me right now. It saves me from having a 1:1 conversation with every reader. Consider trying this on your next work package.
Automate Repetitive Tasks
If you find yourself doing the same thing every day, automate it. Whether it’s a bash script or a custom tool, automation can save you hours over time. My teams often build internal CLI tools or script collections, making it easier for everyone to write and share scripts. This is a super powerful way of keeping yourself and others speedy. Consider pitching this to your team.
Stay Busy
Always have more than one task on the go. If you’re blocked on one, even for a few minutes, move to the next. And if you run out of work, don’t wait for the stand-up—reach out to your lead or manager immediately to get more work. There’s always more to do and downtime robs you of experience you could be gaining. Once you finish this post, consider checking the backlog for something to do in parallel.
Collaboration and Knowledge Sharing
Leave And Read The Clues
Code changes over time. Additions, subtractions, and substitutions. Small but powerful actions, like leaving comments, updating README files, and maintaining a well-structured codebase, can significantly help the next person who works on the codebase (which will likely be you). The more clues you leave, the faster you’ll be able to navigate your code later on. Of course, learning to read the clues is just as important as well - for example, recognising the codebase structure by the patterns it uses, Clean Architecture, Singleton, Serverless. Next time you’re in your codebase - try “read the room” a bit more - what do you notice?
Document What You’re Learning
If you're struggling to learn something, document it. Writing things down not only helps you retain information better, but it also provides a reference to look back on later. In fact, this is something I might be doing right now. By writing out the challenges you're facing, you will learn and retain information better. You will find gaps in your knowledge as you try to paint a narrative. If you're not a fan of blogging, keeping a private diary can be an effective way to achieve the same results. Of course podcasts, tweets, tiktoks, etc. will also have a similar effect.
Ask for Help at the Right Time
Mastering the timing of when to ask for help is an art—a skill you will build over your career. Don’t spend hours in the weeds—reach out when you’re stuck. However, it's equally important to recognise when pushing through a challenge on your own will lead to valuable learning and potentially make you faster in the future. Continue honing your intuition on when to ask for help versus when to persevere on your own."
Continuous Improvement
Practice Makes Perfect
Side projects, hackathons, or even working on internal tools can give you the extra practice you need to get faster. The more you code, the more efficient you’ll become. It’s cliché, but practice makes perfect. There’s always more work to be done, both in side projects and at your job, so ask your team if you have the capacity and want additional tasks to practice on.
Reflect Often
Reflect regularly on your work. Reflect, reflect, reflect. Lock in that learning. It will accumulate. Remember my saying: Work + Reflection = Experience. The more experience you have, the faster you go. After every task, ask yourself (or your lead if you don’t know) why it was done that way. What was different from last time? What was the same? In what other situations would this approach work? In what situations wouldn’t it work?
Bonus Tip: Using AI Coding Tools
I’m in the early days of using AI coding tools at home—like GitHub Copilot—so my observations are limited. However, I’ve noticed that for situations where it seems many other developers have tackled what you’re about to do, such as writing a map function or performing some standard React coding, AI tooling can quickly generate boilerplate code. Nevertheless, I’ve wasted plenty of time expecting too much from my AI assistants. Therefore, be careful and take your time to figure out when they work and when they don’t. Also, be sure not to deprive yourself of a learning opportunity by letting the AI solve everything for you; you might be sacrificing future speed.
In the end, moving faster as a developer isn’t about rushing—it’s about building the right habits, using the right tools, and continuously refining your process. Start implementing these tips today, and watch your productivity soar. Remember, the aggregate effect of all these small changes is where the magic happens. You've got to want to move fast, and that’s not for everyone, but I recommend it. Ultimately, moving faster isn’t just about speed—it’s about efficiency, creativity, and staying ahead of the curve. It’s about wanting to be the best you can be, without burning out. Good luck.
Disclaimer
I’m not perfect. I don’t follow all these tips myself 100% of the time, and I’m not claiming to be faster than you or my team. Additionally, this list of tips is not all the tips out there. Please keep looking for and collecting them. I would love if you found some that worked for you and let me know. Perhaps this list can keep growing.