Habits of Productive Software Engineers that I Learned from Experience
Attending mind-numbing meetings is not one of them.
Waking up in the morning, feeling refreshed after a good night’s sleep, and more importantly, you know what you want to do today.
Starting your day at the office attending 15-minute stand-up, to share progress and issues you and your team faced the previous day. 15 minutes sharp and the stand-up end.
You are clear about the priority of the tickets assigned to you, you work on them in order from the highest to the lowest, but today you will focus on working on one of them.
You start your day, everything goes well and you end your day satisfied looking at your code and documents.
Typical Day of Average Software Engineers
The reality is that you rarely end your day feeling satisfied with what you have completed. Most days end with you feeling anxious because the deadline is coming and your code is still not working as expected, let alone the “fit the architecture” thing.
In my experience, decades working with different levels of Software Engineers in different companies with different cultures, I’ve seen those who performed well and those who were below the bar.
This article describes the five habits of those who performed well, based on my own experience.
They Love Coding
At first, this seems obvious, if you have chosen this career, why won’t you love coding?
What I really mean here is that they love solving issues, they feel excited finding bugs, and they can spend hours trying to write the best code that works, and most importantly feeling happy doing it.
This is a must-have for a software engineer.
This is where a software engineer is expected to enter a flow state and produce quality code while feeling happy doing it.
They Test Their Code
This is about craftsmanship. You love what you’re doing, you can spend hours on coding, and you lose track of time while doing it because you are so focused and all your senses are working toward the code.
But, that is not enough.
If you love coding, you don’t just say “you love coding”, but you act on it. You perfect your crafts.
What I’ve seen is people will improve their coding skills if they consistently test their code.
Testing code is not only a matter of testing but it is about knowing what you create.
- Are your interfaces right?
- Are they handling edge and corner cases?
- Will they work well with the other parts of the system?
They Prioritize Readability over Code Optimization
In the book “Clean Code: A Handbook of Agile Software Craftsmanship”, Robert C. Martin says
“Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code.”
Which is true. A lot of time is spent on reading code. Not only your team codebases but also open-source software, code snippets on Stack Overflow, etc.
It makes sense that they prioritize readability because that is what matters. The code works and is beautifully written.
Don’t get me wrong on this though, this isn’t about choosing and writing the right data structures and algorithms but about writing ugly syntax for showing off.
Code is just another type of document. We write a document for others to read, so it doesn’t make sense to write something to intimidate our readers, we want them to read our document and understand not to run away.
And in fact, one of the readers will be the future you. You will be ashamed if the future you which will be smarter than today’s you look at your code and think “what is this crap”?
They Write Design Document
The next habit is equally important, writing design documents. The design documents are used for:
- Communicating ideas to less technical members of the team
- Describing complex algorithms
- Describing complex scenarios with illustrations
They Study and Review Codes
In order to be converse in writing code, you need to know how others write it, how people before you have done it, so you don’t need to repeat their process and spend time to reach the same thing. In other words, you don’t need to reinvent the wheels.
Studying the styles and patterns is important, especially in the early stage of your career. Understanding the reasoning behind architecture selection, patterns, and styles is important to add to our skillsets.
Reviewing the code, i.e. Pull Requests is equally important. At a glance, it seems like an easy thing to do. But, if you do it seriously it is actually not. You have to understand, in detail, what the code has to do and review it line-by-line.
Loving this process of reviewing others’ code is a must-have for you. Like they say “the devil is in the details”. Everything seems easy from a high-level view, well it should be, that’s why it is called high-level view, it is only used to explain something to less technical people. But for you, understanding the details is inevitable.
They don’t Attend Meetings
To the contrary of popular beliefs, they don’t attend meetings, unless their expertise is needed or they need to clarify requirements.
Meetings are overused, they happen all the time, all day, and most of the time attended by too many people and have no clear agenda.
We all know that, yet many of us still attend them.
To be productive as software engineers, we need to have a long uninterrupted time working on our code.
Collaboration and alignment are indeed needed and important, but as Software Engineers if we want to be productive we shouldn’t spend our time on meetings.
Being productive is important because it will make us feel happy finishing our day.
Many of us are unaware that we spend our time focusing on things that are less important for our job making us unhappy because we are unable to achieve the goals that we set for the day.
If you cultivate these habits, over time, it won’t happen overnight, you will be a better software engineer and generally feeling happier:
- Spend most of your time on coding
- Test your code to perfect it
- Prioritize readability over code optimization
- Write design documents
- Study and review others’ code
- Don’t attend (unnecessary) meetings