So how do you really determine efficiency in developers? By speed, source lines of code, or readability? Well, the answer may not be as black and white as you think.
Long gone is the time we calculated the number of lines of code to measure a developer's performance or productivity. We now understand that the opposite is more true. Finally! It makes sense after all: the less code we write, the easier it will be to maintain our application.
But still, there is a big gap between fast and slow developers. For producing the same functionality or application, some developers will take days when others will wrap it up in a few hours.
Let’s try to understand what are the differences between the two, why it matters, and how to improve our skills.
Obviously, if given the choice between working with a slow or a fast developer, companies will have a preference for the latter. And it’s easy to understand why. Things will just move faster, the work will be done quicker, and money will swiftly roll in. Why wait for days when somebody else can do it in a few hours? The only reason would be if the slow coder is much cheaper, which actually doesn’t sound like good news for the developer.
As a developer, working faster sets you apart from others, not only for the speed but also, as we will see below, for better efficiency. Less time doing the work means you have more time to learn (and most likely also learn faster), test your code, and help others. In the end, chances are that you grow more within the organization than slower developers.
It’s also important to remember that everybody around us is constantly developing their skills, improving on various levels. If we don’t, too, then we’ll quickly become outdated. This is something I’ve written about in an article about the concept of seniority in software development (a good read to complement this one, if you ask me). As a developer, stagnation is your worst enemy.
The more you optimize your time and master your tools, the more you’re able to wrap up something quickly and efficiently. And that feels great. I don’t know for you, but for me, taking pride in my work is just as important as the money I make with it.
Ok, enough with the whys. Let’s see what you can do to be more efficient as a developer.
For obvious reasons, we don’t want the quality of the product to be affected by speed. A high level of quality is still the standard. It’s a constraint and a constant that no company wants to change since low quality always brings trouble, bad sales, and in the end, death of the whole enterprise.
Considering that, let’s explore some reasons why a developer gets bogged down with their daily tasks.
This is probably going to annoy a lot of people because I’ll be rambling about the same thing over and over again. But the truth is, a lot of our time is lost reading bad code, fixing bad code, and hating the person who wrote it (including ourselves).
Avoiding bugs in the first place is an important part of becoming faster. Some people go with the mantra “there will be bugs,” and it’s true, bugs are unavoidable. But it’s also possible to significantly minimize their number. Believe me, having only 2 to 3 bugs in a sprint is something the client will value, much better than having 20 as this will have a huge impact on the development schedule.
Some may not realize this, but it takes less time to avoid a bug than to solve it later. After all, solving it later will most likely involve a lengthy investigation process.
Thinking before we code, the ability to follow the data path, and to visualize the different systems of an application are all important here. When we have a mental image of the application and the interaction of the systems comprising it, then we can visualize the data moving from point A to point B. And along with those, we’ll also discover a ton of requirements such as validation and transformation. With more experience, we’ll also be able to anticipate what can cause problems and add the necessary tests and validations before the crash occurs. This is all about training your mind to be able to write clean code.
Visualizing an application is much easier when its structure is simple and the different parts well-defined. The tools we can use to make our visualization easier are abstraction layers, isolated scope, and separation of concerns. Aside from that, there are also pure functions, low coupling, and reduction of side effects. All these tools are there to reduce complexity.
Learning how to debug a piece of code is also an essential skill to have for just changing a few things. Testing over and over again, however, may just mess up the code and architecture.
Usually, the best approach is to hunt down the bug by eliminating where it cannot be. Personally, I would try to avoid changing anything before I clearly understand what is wrong.
Also, remember that nothing is random or intermittent on a computer. Usually, it may appear so because of some external factors or unknown parameters.
When working with a framework, it's essential to use the provided classes and good practices for their intended purpose. Trying to force our way because it seems easier or because we are too lazy to implement something clean is a sure way to disaster. If some classes don’t give access to some context, there's probably a very good reason for it. So instead of forcing our way in, let’s read that documentation a second time.
Some people still think that writing some convoluted code will help them look like better developers. I have met plenty during my career who simply couldn’t write simple code. Writing complex algorithms just to show off our skills will only make everybody hate us and unfriend us on Facebook. So as I’ve already mentioned in a previous article, let’s keep things simple.
Yes, I'm going to annoy people again... this time with a paragraph about distractions. And I'm even going to suggest that we take a serious look at ourselves. You see, some studies reveal that most people are productive for only a small portion of the day... and the trend doesn't seem to be getting any better.
Let's conduct a small test, shall we? Set up a timer and try to focus on a single task for 20 minutes straight, with absolutely zero interruption. If you’re unable to successfully sit through that, then you probably need to fix yourself or your environment (but most probably yourself).
Interruption and distractions are everywhere today. As a matter of fact, the average American gets to see about 4,000 to 10,000 ads every day. No wonder around 90% of what many of us buy are from ads we saw on Facebook, YouTube, or Instagram. You see, these platforms just want our attention. They don’t want us to work. They want us to look at them. And if we don’t, they will remind us to do so with notifications. They are the pinnacle of narcissism.
Obviously, our employer will not ask us to focus on work for nine hours straight. That’s simply not doable. But avoiding too many distractions between two breaks is something we should all try to achieve. And if we really want to buy something to soothe our loneliness, a good noise-canceling headset would be perfect, especially for an open-space office.
Saying “no” and learning how not to be always online is the key here. So let’s start saying no to the useless as well as unsubscribe, block, unfriend, and unfollow. It will be annoying at first. But after a while, we will discover that good old feeling of achievement, success, and productivity again... not just the lies we’ve been telling ourselves until today.
Reading documentation is a big part of our daily job, mostly because it’s hard to know everything about every technology we use. Also, most of the time, we are not the first to face some problems, and so the solution is probably already on the internet, somewhere.
Knowing where to look for information is quite important. Ninety percent of the time, you can search for it on DuckDuckGo or Google (or Bing, if you are playful. Or you can ask Siri if you really hate life). And the first link will probably be an answer from Stackoverflow.
But the most essential part of that process is to actually learn something from it, not just copy/paste the solution and move on to the next problem.
It’s the same when we read some documentation to learn a new framework or library. If we just copy/paste the code instead of actually writing it, we are not helping our brain to remember it. And this kind of learning will be a regular task during our whole career, so better learn how to learn early in life.
If you don’t have a spaced repetition agenda, you’re doing it wrong.
I couldn’t stress this more: Know what is spaced repetition. Spaced repetition is how we learned everything we know by repeating the same thing over and over again until it became second nature. Our memory is limited, and our brains will only keep what we regularly use. So if we want to learn something well, we should do it regularly. Since our daily tasks won’t allow us to do that sometimes, adapting the spaced repetition principle will remind us to repeat our learning.
Always take notes so you can quickly skim through them without reading the whole article or watching the entire video again. Personally, I use Dropbox Paper, but Evernote or other tools will work just fine. Just make sure it offers a good search functionality and keep your notes organized.
Next, add an entry in your agenda reminding you to re-read your notes 2 days later. And on that day, create a new entry for 3 days later, then 5 days later, then 8 days later, and so on. Yes, these are the Fibonacci numbers, so it’s easy to remember. Myself, I use a task management tool called Todoist, but everything that has reminders will work just fine.
Lastly, every time you do a repetition, improve your notes, add information, and correct them if necessary.
After a while, you’ll be surprised that you’ll know exactly what’s in your notes. More than that, you won’t need to read those notes anymore since you’ll be able to just repeat them in your head. Amazing, right?!
Allow me to emphasize something here, all right? If we don’t know the basics then we should stop right here and start with that. For instance, did we learn Javascript using jQuery? Then we should definitely start learning Javascript again because we probably know nothing about it. Take it from me, not knowing the basics is the best recipe for failure.
Then to wrap it all up, we can follow some pretty neat websites like roadmap.sh to make everything easier.
You’d be amazed to know how many people still can’t type with more than 2 fingers on their keyboard, and without looking at it. Obviously, when we want to improve quickly, we pick up the low-hanging fruits, and they’re not always the most obvious ones. Learning how to use a computer is one of those low-hanging fruits. If we’re still looking at our keyboard and can’t use all our 10 fingers to type, then we should definitely spend some time learning that skill. It will make our work experience so much better.
The next one is about how to use our IDE (integrated development environment) properly. Often, developers pick the most popular IDE. They don’t realize that investing $20 or $50 in a high-performance IDE will save them days of work simply because they come bundled with amazing tools.
Some examples of time-saving features your IDE should offer:
Obviously, there are a ton more features that we should demand from our IDE, but I won’t list all of them here.
So just in case, you didn’t have the time for all that, my advice is simply that you…
Here you go, these are a few tips for you guys to make your life better. And after all that, remember to apply for one of our open positions... but only if you’re not already working with us! ;-)
Software Architect
Software Architect
Eric has been working as a software engineer for more than 20 years. As a senior architect for Arcanys, he works closely with the developers to instill the habit of learning, clean coding, re-usability and testing with the goal of increasing the overall quality of the products delivered by the teams.