By Tom Hombergs

Have you ever sat down and taken an inventory of your habits? Habits are what make us who we are.

Good habits help you to become who you want to be. Bad habits will slowly turn you into someone you don't want to be.

After more than 12 years as a software developer, I've grown some habits that I'm proud of and some that I'd rather get rid of.

Most of the time, I wasn't aware of my habits, but looking back, it's pretty clear to me which habits were helping me grow and which were hindering me.

This drove me to take an inventory and write about good developer habits to maybe inspire you to do the same.

If you're starting as a developer, have a look at the habits outlined below and ask yourself if they would help you become who you want to be. Be conscious of your habits and actively nurture them to become a great software developer.

Volunteer for Things You Don't Know

At the start of your career, you don't know a lot. You come into that new project and feel like an impostor because they're paying you money even though you don't understand half of the acronyms, technologies, and frameworks they're throwing around in each meeting.

And you only faintly know the other half because you googled them.

Replace "At the start of your career" with "At the start of any new project", and you have a pretty good summary of a software development career.

Every new project, we start over. There are new people to meet, new requirements to understand, and new frameworks to learn. Every single time.

This is why it's important to learn new stuff. If you just keep doing the things you know, you'll never be confident about starting a new project. There will always be the fear of the unknown.

If you make it a habit to volunteer for tasks you don't know anything about, you will constantly learn new things.

If the build needs fixing and you've never worked with the build system, get on it! You'll learn about build management.

If there's a bug in the JavaScript frontend and you've only worked on the Java backend so far, fix it! You'll learn new Javascript idioms.

Doing stuff you're not confident about doing is a great way to grow. Be sure to manage other people's expectations towards you, though. Don't pretend you're an ace. Tell them you haven't done it before but you would like to learn.

Ask to Pair Up

If you're stuck and can't get started with a task because you're unfamiliar with the context, ask someone with experience in the topic to pair up with you.

A pairing session is a great way to kick off the work on a task. Discuss the requirements with your partner until you have an understanding of what is expected. Then, discuss the solution.

What's the context? Which codebase(s) do you have to touch? What are the explicit and implicit conventions in the codebase?

But you can take pairing even further. Instead of just pairing up to kick off a task, schedule more time with your partner. After kicking off the topic, start working on it together. You drive, your partner gives advice, then the other way around.

This way, you even get to learn how your partner thinks and solves problems. You can only profit from it! Even if it's just a new IDE shortcut you learned.

A note on working from home: due to working from home, I struggled with things that would not have been a problem before. I hesitated to ask teammates to pair up with me. What was a simple tap on a teammate's shoulder in the office became a high barrier when working remotely and communicating with video conferencing software.

If that is a problem in your team, talk about it with your teammates (in a retro, for example) and it will be much easier afterward. Turns out it's just a habit to re-learn.

Talk about What You're Doing (and What You're Not Doing)

I don't remember how often I have eagerly taken on a task, thinking I'd be done within a day, but I end up still working on it a week later.

It gets better with experience, but I still find myself making too optimistic estimations. There are just too many reasons to make an optimistic estimation:

• the pressure to deliver this new feature quickly because the deadline is looming,
• the pressure to look good among peers,
• things just not working as I expect them to (this is the one that's most commonly throwing me off, even with years of experience),
• and a lot more ...

Chances are that most of your estimations end up being too optimistic. What can you do about that?

You can manage expectations along the way.

Continuously talk about what you're doing and what is holding you up. With "continuously" I don't mean that you should provide a status update to the whole team every 15 minutes. But make sure the relevant people know where you stand at the start or the end of the day, at least.

So, if your manager / team / project manager / product manager / stakeholder expects results from you, give them a quick update every day: "This is what I've been doing. This is the next step. This is a problem I'm facing. These are the options."

This will let everyone know of your progress. No one will blame you if you're hitting a wall, as long as you kept them in the loop.

This will make discussions of the type "Why did that take so long?" a thing of the past. As an added benefit, the status update will trigger discussions that can help solve problems.

In the best case, this status update is ritualized in the team. It's commonly called "daily standup" where every team member quickly updates the rest of the team about their progress and problems.

But even if you have a daily ritual like that, take a couple of minutes to think if anyone should be updated that is not part of the daily ritual. Should they be included? Or should they be updated through some other mechanism?

Make it a habit to regularly update the people that have an interest in the results of your work.

Write a Blog

I'm probably not the first person you've heard saying this, but I'll say it nevertheless: write a blog!

It doesn't even have to be public. It can be a couple of pages in a company wiki or a collection of GitHub repositories with example code and a couple of lines of explanatory text.

Why?

Because writing with the intention to teach others (even if it's just future you) is a great way of learning and growing.

Write about how you solved a gnarly problem. Write about how to use that new and shiny framework you always wanted to try. Or write a journal of what you did each week (this will also help with the "talking about what you're doing" habit because you can look up what you've been doing).

I have started a blog a couple of times. It's hard to keep the motivation up in the beginning, because no one will read your blog posts. It feels strange to write into a void. So I stopped.

Then, I started my current blog 3 years ago, writing without an audience for half a year. I noticed only then that my robots.txt file didn't allow search engines to index my blog!

So I changed my robots.txt file and people actually started to read my stuff. Not many, but it gave me the motivation to continue. So, I pulled through, tuned my writing skills along the way, and grew my blog to > 200,000 page views a month.

All because I started writing about frameworks I wanted to learn and problems I had solved so that I could look my articles up again when I needed them. Not because I wanted to create a big audience.

Blogging is a chore at first but can grow to be very rewarding if you stick to it. If you do it with the intention of learning and teaching, you will not only learn a lot, but other people will notice your blog eventually and it will open a whole world of opportunities.

Have a Notebook and a System

I've only recently grown to be a big fan of notebooks. Not a computer notebook, but a real, paper notebook. I take it (and a pen!) wherever I go, so I can take notes about whatever strikes me as important at any time.

I take notes when I listen to a talk, or when I'm waiting for the bus, thinking about what I could make for dinner this week.

I also use the notebook to maintain lists: books I want to read, frameworks I want to try out, features I want to add to my side projects. Most importantly, I use it to take notes while reading books, because that conserves the learnings from the book.

I'm writing down everything that weighs on my mind. If I don't write it down, it will keep my mind busy, sometimes to the extent that I'm getting anxious and have trouble sleeping.

The reason I'm getting anxious without my notebook is that I don't trust my memory. If you have a great memory and can recall everything that you have thought about a week ago, you probably don't need a notebook. If your memory is as patchy as mine, though, it will make a world of a difference to your peace of mind.

To build trust in your notebook, you need a system. You need to convince your mind that whatever you put into the notebook will not be lost.

Create an index on the first couple of pages of the notebook to make the information retrievable. Then, make it a habit to review your notes regularly and process them.

To process the notes I'm taking while reading a book, for instance, I review the notes whenever I'm done with the book and write a book review on my blog. Almost no one reads these reviews, but the process of writing the review makes the things I learned stick so much better.

Keep Notes about Your Wins

Having a notebook can also help with the next habit: documenting your achievements.

As I said, my memory is patchy at the best of times. I can usually remember what I had for lunch yesterday, but if I'm deep in focus and spending brain power on some gnarly problem, the halftime of my memory goes down considerably.

That's why I like to document my achievements at the end of the day. It's usually not big achievements, but small wins - like having beaten a bug, or having finished one of the many steps towards adding a new feature to the software I'm working on. I also document personal wins like having stuck to my morning workout routine.

I just create a list of bullet points each evening in my notebook, but it'll also work with a digital medium like a spreadsheet or whatever you're most comfortable with - as long as you stick with it.

Over time, the achievements aggregate. You might want to mark the ones that are most important to you so you can easily find them later.

Then, on an occasion like a performance review, you go through that list, find the achievements that are relevant to that occasion, and list them out to prepare. Performance reviews always work out better when you're prepared.

Having a list of your achievements also helps in every-day situations to talk about what you've been doing (see habit "Talk about what you're doing").

Have a Time Slot for Important Tasks

At the end of the day, I often feel I haven't accomplished anything. While it helps to document your wins or even just the things you did, you still need to actually do those things.

It happens quickly that you go from meeting to meeting and suddenly the day is over. After a meeting, you want to continue the task you started before the meeting, but just when you've warmed up, the next meeting starts. And after that meeting, you have to start over, because you lost the context.

Context switching is killing productivity.

If there's one thing I learned to be productive, it's having a dedicated time slot for things you want to get done. If you don't have a pre-planned time slot for a task, chances are slim that you will get started on it. It will be eaten up by every-day work or other planned work.

There isn't a single way to implement a time management habit, and, to be honest, I'm hopping from one productivity method to the next every couple of months. But the core is always the same: block some time in your day for the things you want to get done most.

I block an hour in the morning, before work, to write articles for my blog (or for other blogs, like this one). Most days, I also block an hour in the evening, when the kids are in bed, to work on any side project I might have.

Currently, I have a Trello board with one column for every day of the week where I put the tasks I want to do in the morning and the evening. Once a week, I update that board with the things I want to do in the next week, so I don't have to waste my precious blocked time with thinking about what to do next.

I have a very similar Trello board for my software developer job. Every morning, I think of the things I want to do and put them into the column for the day.

I also block at least 2 hours of focus time in my calendar every day, so that my co-workers don't try to schedule any meetings at that time. That's when I get through my list of tasks.

It doesn't really matter how you manage your time, but it's important to do it and to make it a habit. Otherwise your days will be eaten up by things that are not important to you.

When Stuck, Take a Break

As software developers, we tend to get stuck a lot. And boy, does it piss me off when I'm stuck and don't see a way out.

It's such obvious advice to take a break when you're stuck, but it's so hard to do. "I'm so close to solving the problem, I can't take a break now!"

Also, taking a break now would mean I would have to warm up to the topic again later. Why should I deliberately switch contexts when context switching is the number one source of wasted time?

When you're stuck, you're not thinking straight. You're thinking about how stupid it is to be stuck with this problem, how easily your teammates would probably solve it, and why they always get the easy tasks. But you're not thinking about how to solve the problem.

Take a break and work on something else for a time. Or even better, try again the next day. Getting some distance to the problem will allow you to see solutions you were blind to before.

If you haven't tried this before, you won't believe how often a problem is "just solved" the next morning. Mostly because you see a path to a solution that you haven't seen before.

Now, it's easy to say to take a break, but how do you identify that you're currently in "stuck mode" and then persuade yourself to quit working on the problem for a time?

I'm honestly not very good at this myself, because I usually WANT THIS DUMB TASK OUT OF THE WAY so I can show that I've achieved something!

But what I found that helps me is to divide my day into 30-minute slices and have a quick recap after each of those slices. This technique is called the Pomodoro technique based on those tomato-shaped kitchen timers.

After each pomodoro unit, I'm asking myself if I'm still working in a "solution mode", or if I'm stuck and should work on something else for a while.

A nice benefit of the pomodoro technique is that you can use the end of a unit as a trigger for other habits.

I use it as a trigger to stand up from my chair to stretch my muscles and drink some water, for example. This is sometimes called "habit stacking", because you're stacking one habit on top of another, and it's very effective.

If you want to read more on habits, I can warmly recommend the book "Atomic Habits" by James Clear.

Don't Chase Silver Bullets

I wrote a book on a specific architectural style and I regularly get emails saying "I love that architecture style and I want to apply it to all of my projects! How can I do that?".

Can you guess my answer to that question?

There is no single architectural style that applies to all problems out there.

You build a plain CRUD API when it's a small project. You build a more sophisticated Hexagonal Architecture if you have a complex domain model. And you apply any of a hundred different styles when you're building microservices in a specific context.

Similarly, there is no single framework you should use for every single project. And there is no single best programming language or coding style.

Don't fall for silver bullets. They don't exist.

Having an opinion is good if it's backed with good arguments. "This is the best architecture style" or "I've always done it like this" are not good arguments and people will see through them.

Just imagine you have a developer on your team that has an opinion on everything and always wants to do things their way, "because it's the best way". You would get tired of that very quickly. Don't be that person.

Build Those Habits!

Wow, this article got longer than I expected. I hope it provided some inspiration on what to think about when growing your software developer career. I certainly haven't mastered all of those habits, but I'm trying to get a bit better every day.

Pick the habit that resonates most with you and try to consciously apply it in your everyday work.

Let me know on Twitter how it works out! I'd be thrilled to get your feedback.