Habits of Productive Software Engineers that I Learned from Experience

Debby Nirwan
Feb 13 · 5 min read

Attending mind-numbing meetings is not one of them.

Image for post
Image for post
Photo by Oskar Yildiz on Unsplash

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

Image for post
Image for post
Photo by Markus Winkler on Unsplash

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

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

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

“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

  • Communicating ideas to less technical members of the team
  • Describing complex algorithms
  • Describing complex scenarios with illustrations

They Study and Review Codes

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

Image for post
Image for post
Photo by Christina @ wocintechchat.com on Unsplash

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.

Finals Thoughts

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

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store