As a software developer at an agency, sometimes I need to work very quickly. Whether that’s to get new features in, understand an existing codebase, pick apart someone else’s CI/CD setup, or anything in between.
My aim in this article is to share some strategies I use to work as fast as I do - and in case you didn’t guess it from the title, I usually go slow to go fast.
Table of Contents
Open Table of Contents
⌛ Take Time to Assess Your Work
Taking the time to assess your work at a high level for a given period of time can be very beneficial, and also prevent you from having to go back to previously completed tasks and make updates.
At my company, we run week long sprints. This means at the beginning of each week, I will have a list of tickets for features, fixes, or setup related tasks, with the goal to finish each of those tickets by the end of the week.
When I first started, I’d often dive straight in to the ticket at the top of the board and try to complete it as quickly as possible to get on to the next one. However, often times tickets in a given week will build upon each other, and it’s extremely valuable to look ahead to get some context before diving straight in.
For example, if my first ticket is to introduce a new property into a database schema, more often than not my next ticket will be writing some new logic around that new property. Getting some context on how the property is going to be used could help when defining the schema.
The first ticket may just specify that the property needs to hold a number, but the second ticket may specify that it’s a currency value. In this case, it makes sense to define it as a decimal type (if we are working in ex. django). If I just jumped right into getting the first ticket done as quickly as possible, it’s very possible I’d have to go back and adjust the schema in my second ticket.
📝 Plan your Most Difficult Tasks
This relates to the first point - once you’ve got a high level overview of your work for the next week, or however long your company chunks sets of tasks, it’s best to pick out any tasks that may be particularly difficult.
For these tasks, it may even make sense to do a small proof of concept just to make sure you’re wrapping your head around the more complex final product before you jump into implementing it.
For example, say you’re doing an integration with an API you are completely unfamiliar with. First, you’d want to familiarize yourself with any documentation you can get your hands on to make sure you understand what you will need to integrate and how it should be structured.
If the integration is fairly complex and touches a lot of existing parts of the application, it may make sense to “get your feet wet” by spinning up a bare-bones project and just trying to integrate the API and any of the relevant endpoints you’ll be using in the actual application.
This way, you can familiarize yourself with the API and troubleshoot any issues you might face without having to worry about if those issues are due to the existing application logic not playing nicely with the new integration’s API logic.
I have found myself in the position more than once where I’m slamming my head against the wall because things aren’t working for an hour, only to find out it was not an issue with the new integration code, but something in the existing code that didn’t play nicely with it. Because of this, it ended up taking much longer than if I were to have verified how to structure the API logic properly before actually integrating it into the application.
Now, this is just an example, but taking a bit of time to actually plan and understand your most difficult tasks can go a long way to moving a lot faster.
🤔 If You’re Stuck, Take a Different Approach
Sometimes, when I’m trying to solve a problem, I’m searching around the internet and there just seems to be nothing out there on the particular problem I’m trying to solve. Eventually, I stumble across a post that enlightens me to the same fact every time - I’ve been asking the wrong question.
When you’re stuck, it can seem like things are hopeless and you’ll never solve the problem at hand. When you’re feeling like that, it’s worth trying to go all the way back to the root of the problem, and attempt to think of a completely different approach than you’ve been taking.
This is definitely easier said than done, so if you can’t seem to do it, it’s worth taking a literal step back. This could be physically getting up from your workstation to go for a walk, or mindlessly browsing your phone for 10 minutes. I find that taking my mind off a problem will let my brain do some background processing, and when I come back to it, I’ll have at least one or two new approaches I can try.
Just remember, eventually, you will find a solution. There is no problem that is unsolvable - it may just take a bit of compromise.
🙋 If You’re Still Stuck - Ask
So, what do you do if you’ve tried the above, but you’re still completely stuck? That’s when it’s time to ask for some help.
Ask a colleague, ask on a forum, ask anyone who will listen to you. For some things, you may even be able to ask someone who is non-technical, if the problem itself is less to do with software and more to do with say, a business requirement.
🤖 No One to Ask? AI is Your Friend
All of your colleagues are busy? No one is responding to your forum post and you’ve got a deadline to meet in 2 hours? This is where I would recommend leveraging AI - copilot, chatGPT, etc.
While AI can be very helpful (sometimes I’ll even use it for rubber ducking), it can get things wrong. It can also produce some pretty ugly or slow code if you’re not careful - this is especially the case if it’s producing code that you don’t really understand. I would never, ever recommend using code produced by an LLM (or code you’ve found somewhere else like Stack Overflow) that you do not 100% understand. Someone will eventually ask you to explain it, why you decided to use this approach, or worst case, you will come back to it 6 months down the line and think “who introduced this garbage into the codebase?”
Those are some of my tips on how to work quickly, and the first two in particular really hammer home the point of slowing down in order to speed things up.
Thanks for reading, and hope you picked up some tips!