Twenty-one ways to be a Crappy Software Developer
You can’t swing a dead cat on the Internet without hitting an article telling you how to improve your software development skills. Articles telling you about being a “better communicator”, be a “team player”, and “constantly be learning” are legion.
But you know what you never read about? How to be crappy. That’s right — this is an article telling you twenty-one ways to be a crappy software developer.
Why waste any time? Let’s get started.
1. Don’t format your code
Formatting your code only makes it more readable. Crappy coders know that unformatted code is hard to read and hard to maintain. Believe me, it will drive your fellow developers nuts if you constantly check-in code with wildly different formatting. And whatever you do, don’t use any indentation.
2. Use meaningless variable and method names
Meaningful variable names only make code more understandable. If you want to be truly crappy, use single letters for variable names. If you run out of those, use really short and meaningless abbreviations like MsgNand FuncMan. One of my all-time favorites is the DoStuff method name.
3. Don’t write unit tests
Nothing says “I write crappy code” quite like refusing to write unit tests. And the beauty of it is that your code gets crappier over time as the lack of tests lets even more bugs creep in undetected.
4. Couple things together as much as you can
Tightly coupling your code together adds all sorts of wonderful crappiness. First, it makes your code really hard to change and update. Second, it makes for really fun testing and debugging as a change in one portion of your application can cause wide-ranging and far-flung bugs to appear in strange places. What could be crappier than that?
5. Write huge methods
This is one of my favorites. Make sure that you have methods that do all kinds of different things. Bonus points can be earned for deeply embedding lots of if statements. Few things scream “This is really crappy code” than having to hit the Page Down button several times just to get a look at an entire method.
6. Write lots of God classes
Completely ignoring the Single Responsibility Principle in your code will make for lots of trouble down the road. Why sequester functionality into discrete classes when you can way more easily just add methods to an existing class? There’s no end to the mischief you can cause by making a class have multiple responsibilities
7. Don’t use abstractions at all
Hard code everything. Use implementations every chance you get. Ignore powerful language features like abstract classes and interfaces. These things only make your code easier to maintain, and a Crappy Coder doesn’t want that, for goodness sake.
8. Don’t learn anything new
Crappy Coders believe that all advances in software development ended on the day they started their first job. Trying to improve on what you already know merely ends up with you writing good code and using new and improved techniques. Crappy coders refuse to do this.
9. Write crappy bug reports
If “Works on my machine” wasn’t good enough, no one would have ever said it. Makes sure that when you file your report, it has a crappy description of the problem and doesn’t have any steps to reproduce the issue. My personal favorite is “This feature is totally broken”. This will ensure a really terrible maintenance experience for the developer that needs to fix the bug. More credit if that developer is you three months down the road!
10. Don’t bother learning your tools.
Look, if Notepad weren’t good enough for your coding needs, Microsoft never would have shipped it. Why bother learning to use Intellisense, keyboard shortcuts, or any other of those “productivity hacks”? They just tend to reduce the crappiness of your code and speed up your development process.
11. If you actually have to debug, always use the console.
Okay, so maybe you might actually have to fix a bug someday. I know — who wants to do that? But if you have, whatever you do, don’t use the debugger. Instead, just use calls to the console window or a quick ShowMessage call that pops up a dialog. That’s good enough for the accomplished Crappy Coder.
12. Create lots of side effects with your setter and getters.
This is always fun. Make sure you delete something in your setter methods. Change stuff when you get a value with a getter. This is a ton of fun, believe me.
13. Follow the FRY Principle: Frequently Repeat Yourself
A hallmark of Crappy Code is a difficulty in changing and updating things. Constantly repeating yourself in your code is a sure-fire way to make updating things difficult. Use tons of magic numbers. Why declare a constant in one place, where you can use a literal in 34 places?
14. Don’t listen to any experienced developers
Experience — Bah! Who needs it? What do those old fogies know anyway? Just because they have seen it all and made all the mistakes rookies make doesn’t mean that you shouldn’t make them, too. After all, how to get to be experienced if you can do things crappy in the first place?
15. Lose total control over the scope of your objects
Another classic — allow the scope of your class instances to get totally lost in a maze of method parameters. Reuse an object whenever you can — why waste all those new calls when an existing instance can be passed halfway across your application via a chain of seven method calls? Untraceable memory leaks are a hallmark of crappy coding.
16. Use lots of global variables
This may be the most valuable tip here. Never being 100% sure about the state of a variable is a sure-fire way to write Crappy Code. I mean, if you can’t figure out how and where and to what a variable’s value is being set, you surely can’t be expected to fix a bug involving unknowable state.
17. Don’t pay attention to the case of identifiers
I always love this one. It’s particularly effective in case-sensitive languages. Writing really hard to find bugs is a breeze when you subtly change the case of a variable name in JavaScript. Even better? Use l and 1 interchangeably.
18. Write tons of meaningless comments
Be sure to clutter up your code with lots of comments that provide no value, particularly ones that explain what you are doing where the code actually does that. For instance, put // Clear order list write before a call to OrderList.Clear. That will really crapify your code. This tip gets even better when the comments get separated from the code they were originally associated with.
19. Write lots of negative boolean expressions
Nothing makes the brain explode quite like a boolean expression with lots of not modifiers. Seriously — do this a lot and you’ll really make your code hard to read.
20. Use boolean parameters to make your functions do two things
This is classic — really confuse people with functions that can do two different things:
Then, you can call it using the ultra-unclear and totally crappy:
processOrder(False);
Extra credit for the double negative! Totally incomprehensible!
21. Check-in huge changesets
A hallmark of the true crappy coder is waiting like two weeks before doing a commit, committing a ton of different changes in one changeset, and then using “Checking in a whole bunch of changes and fixes” as a commit message.
Believe me, just doing this alone will make you a really crappy developer.
Conclusion
So there you have it. Twenty-one ways to write code that will ensure that your code is crappy.
Crappy Coding, everyone!
