How to become a lousy developer

Being a good developer is so overrated nowadays. Why don’t you try being a lousy one instead!

Follow my clues…

Never learn more than once

So you found a way to implement something, to make some feature work. Good! That’s it then.

Don’t touch it. Don’t question it. Don’t try to see if you can improve it.

Why should you? If its not broken don’t fix it, right? And it doesn’t matter if it’s slow, if it’s unreadable or it’s copy-pasted from another part of the program or, even better, from some shady website out there. It solves the problem and that should be all there is to it.

Of course the corollary to this approach is: don’t read books, don’t read blog posts, articles, opinions and don’t watch webcasts. Why should you, you know your knowledge is the unmistakeable truth, so… don’t waste any more time! You learned it once, don’t make it evolve!

And by the way, you don’t need to learn new languages either. Groovy? Clojure? Scala? Bah, humbug! Look at those COBOL guys: still doing great!

Never challenge what you learn

Okay so you learned something after all. You searched a solution on StackOverflow, you’ve stumbled upon an article from Martin Fowler or you got so bored that you ended up reading “The Clean Coder“.

Well the damage is done already, so just use that knowledge and don’t challenge it. Yep, follow the damn thing blindly and never look back: who cares about checking if that knowledge if true, practical or simply whether it suits your style! Never learn more than once, remember?

It’s tiring to reflect upon some new insights, to approach it from different perspectives… Why bother: apply it, solve the problem, go back home with a smile and watch C.S.I. Miami. Another day well spent.

Never accept advice or mentoring

It should be kind of obvious, but anyway… Why should they be right?

You have already learned once how to solve that problem. It works. End of story. What would be the point of questioning the way you code? Why should you learn other ways of solving the problem?

It’s hard to reconsider what you know, and it hurts your ego to listen to any advice out there. So don’t.

Never try to make your code readable

Seriously now: why should you try to make your code readable? It’s not like you or anybody else is ever going to read it back to fix it or improve it, right? Probability of that happening is so low! Your code is great, it works, so let’s not touch it.

Besides, the computer doesn’t need to have readable code to run the program. Code is not written for other developers to read back. In fact, that’s more like an anti-pattern! Instead, make sure that you’re the only one who possibly understands it because that’s the best way of keeping your job. Check this set of slides about “Refuctoring”, and never look back!

Never write tests

Test Driven Development: what a riot!

Testing is for losers. You write your code using FCDD (Foolishly-Confident Driven Development).

It’s not like your code could be anything but perfect! And you never make mistakes: it’s the programming language you use that’s flawed, not you. Machines get it wrong. You want proof? Fire up Microsoft Word!

If the code works on your machine, it works everywhere. And since you won’t be changing your code, once it works it’s for ever.

Never do anything but code

Why should you analyze requirements, understand the business, write tests, learn how to deploy the thing beyond your own computer?

Besides, it’s not like they will give you any particular insight on how to write your code. What could possibly learn from taking any of those tasks?

Never help others

Never help others either: let them find the solution by themselves. They will ask questions about how you solved their issues anyway, and why should you discuss that: it works and you won’t change your mind about that.

Other programmers are supposed to be as lousy as you are, so they should not even accept your help. “Never accept advice or mentoring“, remember?

Helping others is time-consuming and will only make you doubt about your knowledge, and we don’t want that. Why? Because we shall …”never learn more than once“. Good, you’re starting to get how it works!

Conclusion

And with all these tips you should be off to be a lousy developer. Lousy but happy, I guess. Don’t thank me!

Cheers!

…

Okay wait, you’re telling me you DON’T want to be a lousy developer after all?

Hmm… Okay, but it’s going to be hard, you know. It takes some serious work to be on that path!

Still wanna go there?

Right, so here’s three tips to get you started:

1. Do the exact opposite of the tips to be “lousy”. Yep, all of ’em! Told you it was a lot of work!
2. Constantly do some introspection and criticize your approaches: is it working? Why is it working? Why is it not working? Is it possible to improve that? Etc. It’s hard on the mind, it’s tiring, but it will lead you to interesting discoveries!
3. Read “The Clean Coder” by Robert C. Martin. I don’t like pitching books or anything, but trust me: never has a book forced me to reflect on my work as efficiently as that one. It got me started on aspiring at being a professional developer instead of a lousy one, so it’s worth every penny.

Off you go now 😉