Busting the myths of programmer productivity

What makes a productive programmer?

‍

The concept of ‘more haste less speed’ applies across almost every field, and programming is no exception. While coders have built a reputation of long hours of furious work fuelled by coffee and energy drinks to hit unrealistic deadlines, this isn’t a sustainable approach and not always the most productive either.

‍

Understanding how to be productive in a programming environment requires a more nuanced approach, understanding your own limitations,  as well the objectives of the company you work for.

‍

We sat down with João Ferreira, Senior Software Engineer at Foursquare, and Rafael Henrique Tibaes, Cloud Vision Engineer at Logitech – who both found their current roles through Andela – to understand if pure speed does make for more productive programmers, or if there are better ways to achieve your goals.

‍

Speed isn’t everything

‍

Tibaes believes that the idea that great software developers are ten times faster than the rest is something of a fallacy, as it automatically assumes that you’re referring only to the speed at which they can churn out code.

‍

“Coding faster doesn’t mean delivering results faster. The only place where coding really fast is useful is in a competition, but if you came back a month later even the developer might struggle to understand the code. So code written too quickly just creates a problem later that someone else has to solve.”

‍

He adds that the opposite is equally true. “If a programmer has taken a long time to deliver code they’re not being productive either. Just because you can write every element of the code in C, doesn’t mean you should.

‍

“What’s important is to reach an equilibrium between the speed of delivery, code optimization, and maintainability. Great developers are the ones who can think about these trade-offs and choose the path that best suits the momentum of the company.

‍

“A start-up needs to deliver a product to market quickly but will be forgiven for it not being perfect, but a large established organization has a longer-term view, but needs to ensure that systems and services work perfectly on day one.”

‍

Ferreira feels that there’s a good analogy to be made between coding and playing guitar.

‍

“If you look at those people who can play guitar really fast you think: ‘Oh, he’s a guitar god!’, but that’s not necessarily true. Sometimes they’re just showing off, but don’t have the musical knowledge to back it up.

‍

“In programming, it’s a challenge because you might have a manager who thinks that coding faster will get you the result faster, but in reality, you’re just writing code that will break faster.”

‍

How do you measure productivity

‍

For all programmers, the question becomes: How do you measure productivity?

“You can’t just use one metric,” says Ferreira. “You can’t just use time as a measure; you need to look at the quality of the code and how many issues there are once you’ve deployed your work. If the quality isn’t there then both you and your company take a hit.”

Tibaes reiterates that how you measure productivity needs to be linked to the organization you’re working for. “You need to understand your company’s goals and align your measure of productivity to that. Is the objective to get an MVP to market in the shortest possible time or is it to create a stable platform that has to support millions of users without falling over? Most companies are adopting Agile in one form or another and it maintains that you should do the necessary tasks to achieve the company’s goal, not do as many tasks as you can in the shortest possible time.”

Both Ferreira and Tibaes agree that feedback is critical in measuring your productivity. “If your only measurement is a deadline, then you’re using a dangerous indicator. In my experience, the best measure for productivity is asking people for feedback. I started to bug people for feedback and I didn’t just see what I was doing right, but people were enthusiastic about keeping the lines of communication open.”

‍

5 tips for junior developers

‍

Ferreira and Tibaes offered some helpful tips for those just starting out on their journey as programmers:

• Remember what matters.

Your health, your family, and the goals of your company. Working day and night might make for good stories but it’s not worth it if you’re suffering.

• You can’t do it all yourself.

If you want to be a superhero you need a team of superheroes around you.

• Choose the best tool for the task at hand.

Don’t try to write everything in C when Python can get the job done better.

• Don’t get stuck focusing on only one thing.

Even if you start your career with a goal in mind, keep exploring. There are many parts of this industry and you might find something you love even more.

• Don’t forget to eat, drink and sleep.

‍

Are you a developer interested in growing your technologist career? Apply to join the Andela Talent Network today.