8 developer habits that help you progress
Over time, I came to understand that one of the most important thing as a developer are habits. All the little decisions, the ways of doing things, the way you look at things. It may not seem like much from a day to day point of view, but this is the secret for huge progress.
Going into the unknown
Let’s be honest, I haven’t always done this. I was not that kind of person. I would take the task made for me. With my go-to language, on the part of the app that I know by heart. I knew exactly what i needed to do before I even looked at it. Choosing the easy way, when it becomes a habit, it’s dangerous.
One day, I decided I was going to do the opposite. As soon as the opportunity arises to do something totally unknown, I’ll jump on it. And the first time I finally did it, it was a disaster !
The time estimate ? I blew it up. It was a task estimated for one day or two. Took the whole week ! My company at that time was not happy, me neither. But something more important happened. Something that seemed impossible and out of reach for me became commonplace. And that changes everything.
If you get into the habit of getting into uncomfortable situations all the time, nothing will be uncomfortable anymore. If you get out of your comfort zone, you’ll stretch it out. And doing it frequently will gradually make you feel better all the time. You really win when the uncomfortable becomes your new norm. It’s a lot easier than it sounds.
What I suggest you do right now is look at the to-do tasks at your job. Take the one with a title you don’t even understand. And throw yourself in there in angel jump mode. For damage control, let’s discuss how to handle the unknown.
Take time for understanding
For a long time, upon receiving a new task, i would start to write code immediately. The goal was to go fast. What could be faster than coding the solution right away ?
And I totally understand if you do that, too. We’re pushed by tight deadlines and we’re judged on our speed. But it’s the worst possible habit. It’s really gonna hit you in the face sooner or later. To avoid that, you need a plan.
The habit I’m advising you to follow is very simple. Don’t do any lines of code until you have a complete solution of the problem. It doesn’t mean you have to go into detail and write a novel.
It just means you at least know where you’re going. You understand, define and solve the problem up front. You invest time in understanding! The code part will only be the application of a problem that has already been fixed.
What you can do right now to start this habit is making diagrams for everything. Before coding, paper/pencil, or better : whiteboard. Just draw your solution. It’s terribly efficient!
Always keep it simple
I’m still amaze when i run into hyper-complex code for basic needs. We have this habit of making everything complex when we code. We have to abstract, decouple and above all show that we know how to do complex things. Once again, it’s a shitty habit.
What I’m advising you here is a change of mindset. You have to get into the habit of asking yourself how to do the simplest things all the time. Cut out the complexity, make classes with less responsibility, more functions, shorter that do one thing. Do everything you can to make it simple and readable. Your whole team should instantly understand what’s going on in your code!
You can apply this very simply today by making a conscious effort to simplify everything you code. The main advantage of doing this is maintainability. It will save you and your entire team a lot of time.
Be careful with deadlines
I’ve dedicated an entire article to this subject because it’s such a source of anxiety in our profession. Your time estimate is a joke. A good estimate is almost impossible to come out with.
Problem is : you have to make estimates. A lot of them, all the time. Like most developers, you tend to underestimate those timelines. It puts you in a world of shit. And you regularly find yourself having to justify your estimate.
To overcome that, I’ve established two habits. The first habit is that I always ask for more information. More details, more precision, more context, more history, for whom ? why? is it possible to simplify ? is it possible to deliver using steps (alpha, beta and so on)? Yeah, I’m a big pain in the ass. But any information is critical and could save my life.
The second habit is that I never give a fixed estimate. Always a range, a min/max. If I think it’s going to take two days, I say it’s going to take between two to four days. And if I have no choice but to give something fixed, then I say four days. Fuck it if it’s too long, that’s my estimate.
When I was first introduced to Git, I was told that it was the basis for any respectable developer. Not knowing absolutely everything about Git was a disgrace as a developer. It put a lot of pressure on me. So I read the whole doc and tried to swallow it all in a few hours. Of course, the next day, I was staring at the void like an idiot after git status.
I see a lot of people trying to do the same thing. Learn as much as possible as quickly as possible. You have to understand that your brain doesn’t give a fuck if you want to go fast. It’ll come out as fast as it went in. People don’t want to believe it, but it’s true. You turn into a goldfish when you get too much information too fast. You can run as much as you want, you’ll forget all about it.
So how do you learn a lot of things then? Just study by reasonable lengths, give your brain time to print out the information, and come back to it the next day. To do that, you can apply today a habit I picked up years ago that has worked miracles.
Every time I hear a term or concept I don’t understand, I write it down in a google doc. When I have some time, I open this google doc, I take the first term/concept and I learn about it. And that’s it, I stop there, we’ll see another day for the rest. You don’t realize how good it is in the long run. And it’s in the long run that you have to invest your time. Development is a marathon, not a sprint.
Another habit I’ve picked up is doing the same thing, but with bits of code and commands. I have long snippets on GitLab filled with complicated commands and other boring syntax to remember. I use these snippets every day and it frees my head for something else while remaining efficient.
Taking a step back
At the beginning of my career, very frequently, I insulted my computer out loud while working. Yeah, so without context, it’s weird. Like all developers, I had bugs in my applications. Being stuck for a long period of time, my frustration was so high that I ended up losing it.
Tenacity, perseverance and resilience in the face of a problem are essential for all developers. I’m sure you’ve already lost your temper in front of your PC. We all have.
The secret is to step back and keep a logical and methodical approach. Most of the time, when you go crazy over something, you’re so into it that you can’t see anything. When you get angry, you lose the focus that allows you to think normally. You need to approach things coldly and methodically. You can practice a very simple first habit to start with.
Next time you feel this, instead of imploding, get up and do something completely different. Every time I do that, I’m gonna get coffee and/or piss off a colleague. When I get back to my seat : my brain is reset. I’ve taken a step back from what’s going on and it’s immediately clearer.
Then my second habit is to reduce the parameters and context of the problem to an extreme level. In a methodical way, I remove the complexity of my problem to arrive in a simple context that works. Finally, I put back parameters one by one until it crashes. When it crashes, I find the culprit, I fix the bug and I don’t insult anyone.
Creating concentration tunnels
I often hear that to be an effective developer you have to be able to focus NON-STOP on a topic for several hours. I’ll tell you right now: it’s impossible. If you can hold 25 minutes on a single topic without flinching, it’s already incredible. I think it’s more efficient to create concentration tunnels (20 to 30 minutes) and to take breaks between each tunnel.
I’ve developed several habits over time to do that. The first habit I’ve established is the Pomodoro. Concretely I set a timer of 25 minutes and I work without pause and without interruption during this time. At the end of the timer, I take a 5 minute break, no matter where I am. You become absolutely imperturbable during the tunnels and it changes everything.
Another super simple habit that you can put into practice right away: the next time you want to concentrate, turn your phone over or put it somewhere you can’t see it. You don’t realize how much the notifications on your phone are messing with your brain. Seriously, just try it for one day and see, it’s unbelievable.
Control your ego
I mean, I’m bound to end up on the ego. The unbelievable developer ego is very real. If I dedicated an entire article on it, it’s because there is something to discuss.
The main problem for a developer with an overflowing ego is that he has no room for improvement. If you can’t control your ego, you feel you have nothing left to learn. If you don’t learn, you don’t progress. If you don’t progress, you regress. And believe me, you don’t want that as a developer.
Besides, beyond your progress, if you’re really full of ego, you’re an asshole. You piss people off and nobody wants to work with you. That’s not good for your career either. The good news is that you can easily control that oversized ego.
The very easy to practice habit is very much in line with what I advise you in the first point. Get out of your comfort zone and fail. Nothing better than a good old fail to put your ideas back in place and start afresh on your personal progress.
It’s a lot to take in all at once, but believe me, it’s worth it. I read a book that gave some tips on how to absorb good habits. The secret is to take it slowly in stages by applying part of the habit a little bit every day. It’s called Atomic Habit, it helped me a lot, I highly recommend it! I promise it will pay off in the long run.