Signs You're a Crappy Programmer (and don't know it)

You know those crappy programmers who don’t know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have? You don’t know any programmers like that? Come one, you know, the guys who are big on dogma but short on understanding. No, doesn’t sound familiar?Then here are some signs you're a crappy programmer and don't know it: * Java is all you'll ever need. You don't see the need for other languages, why can't everything be in Java? It doesn't bother you at all to see Python or Ruby code that accomplishes in 10 lines what takes several pages in Java. Besides, you're convinced new language features in the next release will fix all that anyway.(BTW, this can be almost any language, but right now the Java community seems most afflicted with this thinking) * "Enterprisey" isn't a punchline to you. This is serious stuff dammit. "Enterprise" is not just a word, it's a philosophy, a way of life, a path to enlightenment. Anything that can be written, deployed or upgraded with minimal fuss is dismissed as a toy that won't "scale" for future needs. Meanwhile most of the real work in your office is getting done by people sending around Excel spreadsheets as they wait for your grand enterprise visions to be built. * You are adamantly opposed to function/methods over 20 lines of code. (or 30 or 10 or whatever number of lines) Sorry, sometimes a really long function is just what's needed for the problem at hand. Usually shorter functions are easier to understand, but sometimes things are most simply expressed in one long function. Code should not be made more complex to meet some arbitrary standard. * "OMG! PATTERNS!" Developers who actively seek to apply patterns to every coding problem are adding unnecessary complexity. Far from being something you look to add to your code, you should feel bad every time you are forced to code up another design pattern, it means you are doing busy work that makes things more complex and is of dubious benefit. But hey, your code has design patterns, and no one can take that from you. * CPU cycles are a precious commodity and your programming style and language reflects that belief. There are plenty of problem domains where you have to worry a lot about CPU cycles (modeling/simulation, signal processing, OS kernels, etc), but you don't work in them. Like nearly every software developer, your biggest performance problems are all database and I/O related. The only effect of optimizing your code for CPU is to shave 2 milliseconds off the time to get to the next multi-second database query. Meanwhile your development has slowed to a crawl, you can't keep up with the rapidly evolving requirements and there are serious quality issues. But at least you’ll be saving lots of CPU cycles... eventually. * You think no function/method should have multiple return points. I've hear this from time to time, and usually the reason given is because the code is easier analyze. According to whom? I find simple code easy to analyze, and it often simplifies the code to have multiple returns. * Your users are stupid. Really stupid. You can't believe how stupid they are, they constantly forget how to do simplest things and often make dumb mistakes with your applications. You never consider maybe it's your application that’s stupid because you're incapable of writing decent software. * You take great pride in the high volume of code you write. Being productive is good, unfortunately producing lots of lines of code isn't quite the same as being productive. Users never remark "Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath." Far from being productive, spewing out tons of crap code slows down other devs and creates a huge maintenance burden for the future. * Copy and paste is great, it helps you write decoupled code! You defend your use of copy and paste coding with odd arguments about decoupling and removing dependencies, while ignoring the maintenance drag and bugs code duplication causes. This is called "rationalizing your actions". * You think error handling means catching every exception, logging it and continuing on. That’s not error handling, that’s error ignoring and is the semantically equivalent to “on error next” in VB. Just because it got logged away somewhere doesn’t mean you’ve handled anything. Error handling is hard. If you don’t know exactly what to do in the face of a particular error, then let the exception bubble up to a higher level exception handler. * You model all your code in UML before you write it. Enthusiastic UML modeling is typically done by those who aren’t strong coders, but consider themselves software architects anyway. Modeling tools appeal most to those who think coding can be done in conference room by manipulating little charts. The charts aren’t the design, and will never be the design, that’s what the code is for. * Your code wipes out important data. You wrote some code that’s supposed to overwrite application files with new files, but it goes haywire and deletes a bunch of the user's important data files.That last one, I did that. Just last year. Honest mistake and it never showed up in QE’s testing. Sometimes I’m crappy. Sometimes we all are. I have been guilty of most of the items on the list and still struggle with a few (especially premature optimization). So try not to take anything on the list too personally, but feel free to flame me anyway if it makes you feel better.