In a recent post, we gave you 5 tips on how to become a more efficient and high-performing software developer. But that was only half the story. Here’s the rest of the story with 6 more ways to help write better code faster.
Eat a frog
There’s a famous quote by Mark Twain that goes,
“If it’s your job to eat a frog, it’s best to do it first thing in the morning.”
For the vegetarians and the queasy out there, don’t worry. Our good friend Mark and I were only being figurative. I’m as fond of frogs as anyone and wouldn’t think of eating one – certainly not live.
But it really hits home the point.
Tackle your hardest task first.If you start a project, large or small, with the technological bottleneck you don’t (yet) know how to overcome, then once you’ve resolved it, the rest should be a breeze. As an added bonus (of sorts), you might even come to the realization that you need to approach your project in a completely different way. Think how much time you saved not having to redo all those “easy” tasks had you started with those first.
Be a copy-cat
We’re in the most innovative era in the history of Man. And yet, in many ways, nothing is new anymore. Many of the problems you are trying to solve have probably been addressed before, possibly within your own team. Instead of reinventing the wheel, ask around and see if anyone has already done what you’re trying to do. You could copy and paste the solution as-is, wrap it into a reusable component, or maybe just borrow an idea. Whatever it is, though, you just saved yourself a ton of time.
Ask for fish, but also learn to fish
Yes, we’ve all heard this one:
“Give a Man a Fish, and You Feed Him for a Day.
Teach a Man to Fish, and You Feed Him for a Lifetime.”
But what you may not have realized is that you can apply it to yourself.
It’s fine, even effective, to ask for help, whether you’re starting a new job, working on some unfamiliar code, or just need some friendly advice. But there’s also a lot to be learned from grappling with a problem by yourself. When you dig into code, you acquire an intimate understanding of it. You get the big picture and are more equipped to handle other problems in the code that may arise later.
The art is in finding the right balance and knowing when to ask for help and when to go at it by yourself. Without help, you may waste endless hours, but if you ask for help all the time, you’ll learn a lot less. The guideline that usually works for me is to decide to allocate a specified amount of time to try and work through the problem by myself. If I make progress, I may continue on my own, but If I find I’m not getting anywhere by that deadline, then I’ll ask for help. This way, when I do ask for help, I’ll be in a better position to understand my colleague’s explanations.
Become an expert at your core technologies
Whatever it is that you do in your job, there are probably a few core technologies that are a big part of your daily work. If you’re a programmer, it might be a specific programming language or development framework. If DevOps is your thing, maybe it’s the Infrastructure as Code technology you’re using to orchestrate your deployments. Whatever it is, it’s worth investing the time and effort to become an expert in that domain. And I don’t mean just learning as you go and building up experience. I mean going all-in, reading books, taking courses, attending webinars and meetups, joining groups on social media, and more. All these things may take up some of your time, and expertise takes time to build, but this is definitely a worthwhile long-term investment.
Be the best you can be
Self-improvement is a life-long goal. You should always be looking for ways to optimize yourself. I already mentioned the importance of learning the s4!t out of your core technologies, but you can take it further. Certainly, as a programmer, there’s always that hot new language that is now trending on Google. You never know when having at least some basic knowledge in that domain can help you in your work. And you can even take it beyond “knowledge.” How about optimizing your work processes? You should constantly be asking yourself questions such as “Was I as effective as I could have been in completing that task?” or “Was there a better way to approach that problem?”. Questions like these are essential to Continuous Improvement, a goal we all need to have in mind all of the time.
Keep the endgame in mind and cut your losses when necessary
As developers, we’ve all been there. You start something, estimating it will take “this long,” but it ends up being much more complicated than we had anticipated. We find ourselves sweating through unexpected complications and missing deadlines. For example, you may have embarked on a task to refactor some inefficient-looking code. After a while, you realize that this is a bigger project than you had anticipated, it’s taking much longer than expected, and endangers the system in a whole bunch of places. Or, you might be trying to fix a deadlock that gets triggered under very special circumstances. You invest way too much time trying to reproduce it and then realize, there’s no easy fix. Maybe it’s a better idea to just remove the possibility of that offending scenario from occurring. The point is, there are times when it’s better to stop, accept that you’ve invested enough time on the project, and move on to more productive things. Remember, your endgame is to make a better product or service, not produce perfect code.
Don’t forget to breathe
Yes, we all want to be efficient and effective, get more done in less time and all that. But sometimes, it’s equally important to take a step back and take a deep breath. Staying calm and planning your way forward is key to being productive. That doesn’t mean you should give in to all the distractions that we are inundated with all the time. Your work-life balance should manage that for you. But it does mean that at regular intervals, you should take a moment to reflect on what you’re doing before you go at it with full force again.