The 7 Habits of Highly Ineffective Programmers

Are you committing crimes against code?

Matthew MacDonald

Dec 5 · 4 min read

It’s always good to refactor old code, put modified routines through rigorous tests, and brush up on the latest hot new JavaScript framework. But now it’s time to look at the other side — at the cowboy coders and corporate clock-punchers who keep alive some of the worst programming practices you’ll ever see. This is a list of the seven worst programmer rules. Sadly, you’ll regularly find them at work in the real world.

0. Keep secrets

If you can’t be a 10x programmer, be a 9-lives programmer. That’s someone who’s too difficult to fire because they know the secret lore of the company app — and they don’t share.

To pull this off, be prepared. Junior devs will ask you questions. You will lead them on intricate guessing games, with occasional dismissive snorts and cryptic comments like “we’ve obfuscated that.”

Yes, you could share your knowledge, learn from each other, and grow together. But if the goal is maximum job security with minimum effort, your optimizing function leads here.

1. If in doubt, add another design pattern

As the greybeards say, “All problems in computer science can be hidden with an extra layer of indirection.” Bolting on new bridges, adapters, proxies, facades, and factories may not solve any bugs in your code. But they will swallow them up nicely, turning your shortcoming into someone else’s problem.

Also, an obfuscated bug means you have plausible deniability. Who even knows who’s fault it is?

2. Worship what’s new

To every thing there is a season. If you’re talking JavaScript libraries, that season may last only weeks. But no matter the tech, eventually it’s time to move on to something new.

New technology gets everyone excited. The old stuff may still work, but overnight it’s an embarrassment. Remember “does it still work” is secondary to “does it impress anyone at conferences?”

If you’re clever, you can get paid to write the same software several times over, using different libraries and frameworks each time. And if you’re really nimble, you can jump to a new platform just before you have to reckon with the cost of your own spaghetti code. Constant change = a reasonable chance to outrun your bugs.

3. Don’t let testing get in the way of more code

If you want to be productive, you’ve got to wiggle those digits. Testing is definitely not productive. Do you know what is productive? Tool-assisted code generation. Spit it out. You need reams of the stuff, entire sets of data classes autogenerated based on your database schema. Next week you can change the schema and run all the tools again. Now that makes for a big commit.

Testing is a drag on efficiency anyway. Remember, Agile programming means never needing to say you’re sorry.

4. Write once, then don’t touch

Code is unpredictable. But when it works, it’s like a delicate snowflake perched carefully atop a mid-game Jenga tower. At this point, admire your creation. But don’t risk changing anything.

It’s worth keeping the Pottery Barn rule of coding in mind. “If it breaks while someone else is holding it, then it’s their problem anyway.”

5. If at first you don’t succeed, copy, copy and paste

If God (insert your favorite deity here) wanted us to suffer, he wouldn’t have put Ctrl+C on our keyboards. No problem is too hard for the right copy and paste. Your job is to cobble together a combination of keywords that will bring you a tangentially related code snippet of StackOverflow. Bring that home to your codebase, and you’ve got yourself some free code!

6. Comments are for suckers

You wrote it in the code. Why repeat it in the comments? (Only exception: If there’s a feature that’s a bit tricky to implement and rarely used, add a TODO comment and check it off your list.)

This tactic also helps habit #0.

7. It’s the end user’s fault

That’s what they wanted. No, they didn’t specifically say “construct me a 10 by 6 grid of buttons to trigger different commands” (actual example from real company). But they did say all of these commands need to be accessible with one click. You’re a programmer, so you know all about logical inferences.

If someone questions you, memorize this: Not only is this user interface the best, it’s also the only one possible based on the specs I was given. Don’t even bother to recommend changes — the client would never agree. Hold on, here’s a new feature request. We’re going to need another button.

(If this seems like an eighth point, then let me remind you that we do base-0 counting around here. After all, how else would people recognize that we’re Real Programmers™?)

---