7 Habits of Highly Effective Software Engineers

Stephen Covey’s 7 Habits for Highly Effective People is a business book classic. What if we took the idea of 7 Effective Habits and applied it to Software Engineers? Here’s my list  based on common habits I have seen amongst top performing software engineers in my career.

Actively prototype new ideas

Ideas and new technical approaches sound great on paper, but reality can often turn out different. To get a better understanding of the viability of an idea, great engineers will jump into prototyping and proof-of-concept sooner. Prototyping is a great learning and exploration tool. You will discover whether the approach you had in mind is feasible and truly solve your original problem, or whether there are constraints that you didn’t think of earlier. It’s better and cheaper to uncover these constraints before fully green-lighting and investing a technical approach.

There are also positive upsides to prototyping. You will often discover new paths and technical opportunities that you couldn’t have considered without engaging with the problem. These new opportunities can result in a more robust and innovative solution to your problem.

Effectively estimate effort

“How long will this take to build?” That’s a question that engineers constantly deal with. Effort estimations influences product roadmap, technical approaches and the value delivered to end users.

Teams with engineers that estimate well, create a sense of confidence in their work. Teams that have a habit of missing timelines create a sense of stress and uncertainty.

That said software estimation is hard and rife with biases. Despite attempts at universal frameworks, story points for example, software estimation continues to be more art than science. Estimations depend on the organization as well. An estimate for a work in one company will not translate to work in another company with a different set of processes and tech stack.

Great engineers get better at this by tracking the delta between their estimates and how long the work really took. Recalibrate your estimation with every repetition.

Quick and timely code reviews

The faster you review a pull request, the faster that code can improve and the faster it can get to production. Stale pull request that have been sitting around are a source of risk as the code drifts further away from the main branch. A quick code review gets feedback to a developer while the code and the associated concepts are still fresh in her mind.

Here’s a simple rule of thumb that can help you turn this into a habit. At the beginning of your day, before you fire up your own code editor, check the PR queue and work through all the items pending review. Begin your day with code reviews. This will unblock your peers. And if everyone in your team practice this, your code will also be unblocked and fully reviewed at the start of the day.

Proactively document code, design and processes

Documentation is like salt. Too little and you create knowledge gaps throughout your team, too much and you create unnecessary overhead. It’s best to think about documentation as part of the product deliverable. The project is not complete when the code is shipped, but rather when the code and documentation is complete.

Great documentation will help future engineers maintain and build on top of your work. A key reason for throwing away an existing system often is that no one around knows how it works, or the context and background behind the technical decisions that they see. Great engineers ensure they leave a strong foundation and legacy by documenting their work well.

Contribute candidly to technical discussions

Building great software requires a team that is open and candid about technical ideas. Everyone should feel open to thinking out loud and create an atmosphere that invites others to do the same. Take a good idea and continue to riff on it to make it even better. See a flaw in an idea? Call it out openly, explaining your reasoning. In general, stay detached from the ideas and work with you team to collectively synthesize them towards a better direction.

Get shit done

Results are only achieved when things get to completion. Day to day motion and activities alone won’t get results. You need to get shit done and ship to production. We have all experienced the waning energy when a project nears completion, where the finish line still feels far away as we run out of time. This is where we need to sharpen our focus, cut feature scope, maintain our level of intensity and push through the project to completion. Getting shit done is a skill and a habit that great engineers embody.

Stay curious

This final habit seems simple, but it is extremely powerful. Great engineers tend to have a natural sense of curiosity. They are curious about new technologies, new technical approaches to solving perennial business problems. And their curiosity isn’t limited to the technical, they often go further to understand the user and business context of the work they do and the impact they can have.

Thanks for reading. You can sign up below to stay updated on new posts to help you grow as a Technical Leader and Engineer.