How to program by coincidence – five techniques to ruin your programming carrer

No idea what I’m doing

The Pragmatic Programmer book popularized a term: programming by coincidence. According to the book, it means that you write code that you don’t understand. So it works but you don’t know why. Consequently, if when it fails, you don’t know why either.

I used to believe that the only use of this term was to insult your coworkers. Saying “You’re programming by coincidence.” literally means this meme.

I don’t believe that anymore. I discovered a couple of techniques that help smart programmers like yourself to program by coincidence. I’m sharing them with you for $200. Here they are:

1. Copy and paste

This is a classic one. Whenever you find a problem, then google it. If you find a page, copy the code and paste it into your IDE. See if it works.

If you see two lines of code, you will have the urge to look up the idioms in the API docs. Don’t do that. Just add the code and see if it works.

More advanced users can copy code from the current code base. This is very useful because you can copy tens of lines of code. You can keep deleting stuff until it works.

Pro tip: you can paste SQL code to a jdeveloper connected to the production machine.

2. Ignoring stack traces

What do you do when your code fails? You have a stack trace that doesn’t fit into the screen. Ignore it.

Never ever read the stack trace. You can read the first line if absolutely necessary. So you’ll know see whether it’s a NullPointerException or just AnyOtherException.

If it’s a NullPointerException, just add some null checks. Otherwise you can tweak a loop index. Or paste something. Or comment out a method.

Do whatever you have to do to make the exception go away. That something can break a feature – but hey, that’s somebody else’s problem.

Pro tip: never ever learn, how to read an exception.

3. Ignorance is bliss

Don’t learn the frameworks you use.

If you don’t learn your frameworks then you can think out of the box. Say for instance, you can paste JPA queries into your jdeveloper, then complain that this SQL doesn’t work.

You shouldn’t learn your version control systems either. Just find a good UI that helps you to get by. When you really messed up, somebody will help you clear up the mess.

4. Confidence

When you don’t know how a framework works, then you can guess. You can call these guesses assumptions so you’ll sound smart. The trick is that you never ever need to test your assumptions. Just say aloud what you think and program accordingly.

If your assumption fails then blame the framework. It’s difficult to understand, isn’t it?

5. No automated tests

You shouldn’t write unit tests either. Unit tests give you quick and accurate feedback. Unit tests could tell you which method does what.

Pro tip: if you have to write unit tests, then make them long. It can be more complicated than the code its testing.


Yes, it’s sarcasm. If it hurts then probably you need to revise your practices.

Unless you’re a beginner. It’s OK for a novice programmer to make these mistakes. Just try to get over them in a couple of years.

More antipatterns

Did I miss an antipattern? Please let me know in comments.


About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in programming and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s