Don’t make me write bad code bro.

Be hyper critical of your code.

It’s easy to let the little things slip. Those little things turn into big things when they add up. Writing new code is much easier than reading old code. Make it as simple as you can for the next guy. Even if the next guy is “future you”.

Don’t avoid doing something because it’s “hard”.

This is why you should do it. If it’s hard now, what will it be like to change or fix part of this code later when it’s completely out of your head. This is the wrong time to be lazy. Why is it acceptable to do a half assed job here? I think it was Jason Fried who said, “Do half a job, not a half-assed job”. Do that! (sidenote: “It’s hard”, is usually code for, “I don’t want to do this.”)

Don’t be lazy.

Putting off things or not doing them is easy. Making another pass to get the details is hard. You feel done, I get it, but you’re not. Clean up your code. Would you be ok if your barber did this for you? “I cut most of the hair.”, he says. “Why should I worry about the last 1–2% of getting the hair even? I have customers that are waiting. We don’t have time for the details.”

Avoiding 30 min worth of refactor work now will create more bugs and increase the cost of changing the code in the future. This get’s worse as time goes on. What would you possibly do with the extra 30 min or even an hour that would be more productive than making the code easier to read and more maintainable? It takes 20–45 minutes just to wrap your head around code that is of a significant size and/or complexity. Push through, finish the job, and take a break once you’re done. It’s not sexy or fun, but it’s part of the job.

The longer you put off refactoring the code, the harder it will be. The refactor will likely not be as good either since your head is no longer in the code. Granted, there are times when you may gain knowledge that could help the refactor. Just be smart. If you know the subject, know when you’re procrastinating or making an intelligent decision to punt until you know the subject better.

Use automated tools.

Be lazy here. Use lint and style checking tools. Use code quality services like Code Climate. Implement automated tests. Unit tests and acceptance tsets. Use a continuous Integration server. This should run on every commit unless specified. Tasks like these are ripe for automation. They’re monotonous and boring. Easy to skim and make an error. It’s time to remove human error. Take it out of the equation and automate things that happen over and over.

I was tired of constantly correcting code style and lint during pull request code reviews. It was a huge expenditure of time just to review a bunch of lint type errors. The code was complex and sometimes hard to understand quickly what it was trying to accomplish. It would require 3, 4, or more reviews and changes until it was acceptable to merge into the code base.

I didn’t like being the “anal” bad guy. I felt like I had to make excuses for something that the requester should have already done so I didn’t come off as a dick. I didn’t want to be that guy anymore. So I implemented a lint and style checker. It would check for things like our code style guide was followed as well as any lint policies for the given language (javascript in this case), and a complexity score was not breached. I never had to comment on these again. Any breach of these checks would cause a CI failure. I don’t merge a branch with failing tests. Period.

Watch out for people that will change the rules or make excuses about the lint’er or code style rules for their changes. Somehow the messy code they wrote is an exception. Likely not. I see it happen all the time. It comes back to being lazy and not wanting to refactor the code so it will adhear to the rules. I support changing rules, but not because “it’s hard”.

Don’t let others push you into doing the wrong thing for no good reason.

People pushing to skip refactoring and testing steps are the first ones to blame the engineer for mistakes or shortcuts. You as the engineer are responsible. PM’s and stakeholders will always hold you responsible regardless of the technical decisions they made in your name. Save them from their own ignorance or avoidance. Do the right thing.

When I started consulting early on, I learned the clients rarely know the details of what they want. They have a big picture, but they rarely (read: never) know how to properly implement. Project managers and stake holders are very similar. These people love shortcuts. They tend to think about immediate results, forgetting that it costs 5 times more later. As if somehow this is a one time cost. We’ll magically make this up later when we have plenty of time. This cost is technical debt. Many times the developer is expected to make this up somehow. (I personally use unicorn dust to magically create more time).

Make it as easy as possible to edit and fix bugs later. Finding and fixing bugs is one of the hardest thing we’ll do. If it wasn’t, we wouldn’t have put them there in the first place. Fight to do the right thing. If your environment doesn’t support it, find a new environment.

Bugs usually happen at a critical time. Why would we make this any harder or take any longer than necessary? Who will pay for this? Be adamant about making the code as simple as possible. Fewer, less clever lines. Reduce cyclomatic complexity. Small, reusable parts that are well tested. It’s easy to keep 5–10 lines of code in your head. When is the last time you could keep a 200 line file in your head? Small chunks, modularity. There’s nothing new here. Basic OOP and functional programming both cover this concept.

Stop making excuses to be lazy.

Argue for the right thing. There will be times when you need to compromise. A lot of times. You’ll know a real emergency when you get to it. Stop letting excuses like, “we move fast and deliver”, be a hinderance for doing things right. That’s bullshit. Move fast and deliver quality product.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.