8 Habits Of Bad Programmers
Table of Contents
If you can’t be a level 10 programmer, be a 9 life programmer. This is someone who is too difficult to fire because they know the secrets of the company‘s application – and they don’t share.
To do this, be prepared. Junior developers will ask you questions. You will lead them in intricate guessing games, sometimes with dismissive snorts and cryptic comments like “we obfuscated this.”
Yes, you could share your knowledge, learn from each other and grow together. But if the goal is to maximize operational safety with minimal effort, your optimization leads here.
When in doubt, add another design pattern
As the sages say: “All problems in computer science can be hidden with an additional level of indirection.” Using new bridges, adapters, proxies, user interfaces may not fix bugs in your code. But they will absorb them well, turning your disadvantage into someone else’s problem.
Also, a confusing error means you have a plausible excuse. Who knows who is to blame?
Worship the new
New technologies excite everyone. Old things may still work, but overnight it is embarrassing. Remember, “it still works” is secondary to “does it impress anyone at conferences?”
If you’re smart, you might get paid to write the same software multiple times, using different libraries and frameworks each time. And if you’re really nimble, you can upgrade to the new platform just before calculating the cost of your own spaghetti code. Constant change = a reasonable chance of getting ahead of your mistakes.
Don’t let testing get in the way of more code
If you want to be productive, you have to pump these numbers. Testing is definitely not productive. Do you know what’s productive? Instrumental code generation. I’m telling you. You need a lot of stuff, whole sets of data classes, automatically generated from your database schema. Next week, you can change the schema and run all the tools again. This will now make a big commitment to your code.
In any case, testing is a decrease inefficiency. Remember, Agile programming means you don’t have to apologize.
Write once, then don’t touch
The code is unpredictable. But when it works, it looks like a delicate snowflake neatly perched on the Jenga tower in the middle of the game. For now, admire your creation. But don’t risk changing anything.
It is worth remembering the Pottery Barn coding rule. “If it breaks when someone else is holding it, then that is his problem.”
If at first you fail, copy, copy and paste
If God (insert your favorite deity here) wanted us to suffer, he would not have used Ctrl + C on our keyboards. No problem to copy and paste correctly. Your job is to piece together a combination of keywords that will lead you to the code snippet associated with the conditional StackOverflow. Add this to your codebase and get yourself a free code!
Comments for suckers
You wrote this in code. Why repeat this in the comments? (The only exception: if there is a function that is a little tricky to implement and rarely used, add a TODO comment and mark it in your list.
This is an end-user error.
That’s what they wanted. No, they didn’t specifically say “make me a 10 by 6 grid of buttons to run different commands” (actual example from a real company). But they said that all of these commands should be available with one click. You are a programmer, so you know all about inference.
If anyone asks you, remember this: not only is this user interface the best, but also the only one possible based on the specs given to me. Don’t even try to recommend changes – the client will never agree. Wait, here’s a new feature request. We need one more button.