6th of September, 2017
3 Bad Habits Every Developer Needs To Be Amazing

He was fired for writing perfect code.

A user at hacker news, eqdw, shared his story about a developer who wrote perfect code. The stuff he wrote was the best by far.

So, why did this developer lose his job?

He absolutely refused to approve anyone else's unless it was perfect. He dragged his heels on a four-hour ticket, creating a week-long delay. As a result, his team missed an important deadline.

His bad habits hurt his team

When we think of bad habits, it's easy for us to assume the results are mostly negative. Here's the surprising thing about bad habits.

Some bad habits are actually good for you.

Not only that, some bad habits will help you to keep your job. Using these bad habits requires skill because they can hurt if they're misused. When handled with care, these bad habits are not just things you should adopt but things every developer needs.

Let's get started.

Bad habit #1: Writing very bad code

When I say, bad code, I'm not talking about code that doesn't compile. I'm not talking about code that doesn't work.

I'm talking about code that you know is clunky, old, and terrible to work with. Your boss knows it. Your peers know it. This is the codebase that nobody looks forward to dealing with.

It could be that it's from a difficult client. It could be that it's a legacy codebase.

This is code that will be enormously expensive to update; it might take weeks or months or even years to get it up to par. It could be that it has to work with other legacy code and the costs to replace that code make it even more prohibitive. Even rewriting it function by function would mean that everything you touch could break; everything would need to be retested and debugged.

Just a few months ago, I had to work on a Drupal 6 system for a non-profit organization. When it was first built, it was thrown together very quickly and with a very limited budget. At the time I picked it up, they were already getting bids to replace the site but the current, ancient codebase needed to be taken care of right then. Nobody thought it was neat or cleanly developed. Nobody thought it would be easy to deal with but the client didn't have the budget to make everything perfect.

So, I had to write what I knew was bad code to handle what they needed in the time they needed it.

Why should I do that?

Writing this kind of bad code is about putting your team first. It's about meeting that deadline, keeping that system stable and keeping the team in budget.

Writing neat, well-documented code is something you should be doing already. I'm not saying you should stop doing that.

But, sometimes, your team needs you to do what's best for the team first and what's ideal second.

Bad habit #2: Constantly changing the way you work

When I was young, I used to work for my dad in his home remodeling business. We had taken on a large project and needed extra help. One of the guys we brought on was Bob (which is not his real name).

Now, Bob was very skilled in his work but he had lots of quirks and was difficult to work with.

It came time to hang some gutters and Bob started fighting with my dad over how to hang them. Bob insisted on using gutter spikes but my dad insisted on using hangers and screws.

I only use gutter spikes. I won't do anything else!

My dad said, Then we can't work together, and Bob was fired immediately.

All of us have our preferences. We've got our certain workflow we really like. Just like the code you know is right, the way you do things might be right, too.

I'm not telling you to stop liking the things you like.

You might need to change the way you do things to match your team. I think it's okay to bring your ways to your team and see what they think.

For example, I'm very accustomed to the standard Git flow. This is supported straight out of the box in SourceTree and I like it.

But, when I brought that to my team, they had already unanimously decided before I was brought on to use _ instead of \ to separate the various types of branches.

For me, it was challenging (at first) to read the structure and handle cleanup but, for them, it made it easier.

My team needed me to behave just a little bit differently.

Your team will have its quirks too. They need you to flow with the team and be respectful when you do bring up things you think could be better.

It could be little things that need to change like your basic workflow.

It could be something bigger like the team's standard for code.

... or it could be something much, much bigger.

Bad habit #3: Cutting code

You've put days into building a particular feature. You've tried dozens of different approaches but it's just not working like it should. You know it's not going to work.

You press on and hope you can find a way, anyway. This is the best time to check your approach. Maybe that library won't work. Maybe the way you wrote that function needs to change.

Maybe it's time to cut your code.

Let's talk about the F-35 fighter.

The Lockheed Martin F-35 aircraft, clocking in at $400 billion to produce, is the single most expensive weapons system ever designed. It took 7 years longer to develop and initial costs ran 70% over budget.

You'd think, with all the extra time and money, that it would be the best!

But, it's not!

This aircraft is plagued with design flaws and is outclassed by a fighter from the 70's

And yet, according to Bloomberg, the project continued becoming "too big to kill".

Why? The military had fallen into the sunk cost fallacy. Unless you're the government which can literally print money and make somebody else pay the bill, going that far could not only hurt your team, it could kill the company you work for.

You've probably seen this on your team to some degree or another. It's an easy trap to fall into.

This isn't just some text you typed up. This is project or feature represents hours, days, weeks, months or even years of work. Part of your soul has been poured into it ... and it's not working; it's never going to work right.

I don't know about you but, to some extent, the projects I work on are personal to me. It hurts me to say...

This isn't working.

It's important to do two things when you're starting to hit that wall.

First, talk to your team. They'll have some really good insights that can help you see when it's time to cut your code and maybe even the whole feature. This is personal for you but it might not be for them. By talking to your team, you're putting them first.

Second, let yourself grieve as much as you need to. It's important to do what's right for the team but that doesn't make you a cold unfeeling machine. It's important to let those feelings come.

Let the feeling flow and then do what's best for the team.

Why so much focus on the team?

Your team (including you) produce the best results when there's a safe, non-toxic, and cooperative environment.

Mattias Petter Johansson, the writer of FunFunFunction, said that empathy is the key to achieving that.

When you empathize with your team, it's much easier to be respectful and kind when you need to discuss things like all three of these bad ideas (and when they need to talk to you, too); it makes you easy to work with.

When you're easy to work with, it benefits your whole team. When you're team is working well together, your bosses are happier, too.

And that makes you pretty amazing.

Chris Goehrs
Chris Goehrs Guest Author

Chris Goehrs is the co-developer of HookToWin.com. He's on a mission to help developers learn from his mistakes by sharing insider tips, tricks and strategies developers can use to 4x their performance.

You may also be interested: