Unicorn Programming Fairyland

This should be a short post because I am just trying to document a small observation. I don't contribute to stack overflow as much as I used to. Many times I suggested code that I wouldn't normally use on a daily basis. Well documented standards thoroughly explained in hope of making everyone a better programmer. But if I was to solve the same problem, chances are I wouldn't use my own approach.

Ask any programmer and she will tell you the tale of the awful code she has to deal with at work. But who writes amazing code anyway?

I have to admit, I hate when I see jQuery in the code. I automatically assume that whoever used it used it wrongly. And yes, I see a lot of bad practice thrown all over the code all the time. If I had time, I would remove all the non-sense and replace it with well documented solutions anyone could read. When I write code however, it doesn't take very long before I start writing bad code. Sometimes I even do it on purpose.

[...] the server refused to run my cron jobs. I checked error logs, permissions, groups, everything I could think of. I couldn't make it work. The day of the deadline was approaching. In desperate times, drastic measures will be taken.

Monday morning, I sent a group email welcoming the brand new API from Gstat. The developers tested it and were very happy with the results. Everyone was happy. Except me. I did something I was not proud of. I created a hack in the very system that I had designed.

I'm sure there is a lot of code from stackoverflow that end up on the DailyWTF. Because, no matter how hard you try someone will think it's the worst he's ever seen. And to make it worst, he will show you why your code is bad. (And worser!) he will show you the correct way of doing it. Now two things to note about this person.

1. This person writes code just as bad as you.
2. This person never worked on a real project. (or works in the magical land of unicorn programming)

It is easy to tell people how things should be done. Think about a User Authentication System. If you tell anyone that you want to build one from scratch, you will be shunned. Your name will be pronounced in a sour prayer. You shouldn't build your own user authentication system. Use one of the many well tested solutions already available on the internet for free. Some are even open source.

But, in the real world, people build log in systems. We can argue that we ought to not encourage people to do so, believe me I understand you, I even yell at people to stop creating new JS frameworks. But in the end, people do. And they have to deal with the bugs and whatnot that comes with it.

At my last job, I insisted they not rewrite the service the whole department was running on. I had all the great reasons and even refused to participate. The numbers were clear, we needed to to focus on the website and our users instead of a perfectly working system. They did it anyway. The old code was thrown away like a fowl matter never to be mentioned again. Their websites have less visitors then my blog today, but they did it anyway. Maybe if I had participated I would have added my fair share of bad code, and who knows they might have still had some customers.

The point is, “In theory, it should work in practice. In practice, the theory doesn't work.”.

Good code, standards, best practices are like someone saying "A true leader leads by example." Does it mean that your local congressman should wake up at 6am and wear his blue apron, drive the kids to school, clock in at Walmart, and see how it feels like to not have insurance? A romantic idea certainly, but it's not going to make a difference.

We advise to write code as if we live in Newton's frictionless vacuum world. In the real world, you write horrible code and then you ask some guy to write even worse stuff to make yours work.

The first lesson is: Nearly every game ships broken. We're talking major AAA titles from vendors who are everyday names in the industry. In some cases, we're talking about blatant violations of API rules - one D3D9 game never even called BeginFrame/EndFrame. Some are mistakes or oversights - one shipped bad shaders that heavily impacted performance on NV drivers. These things were day to day occurrences that went into a bug tracker. Then somebody would go in, find out what the game screwed up, and patch the driver to deal with it. There are lots of optional patches already in the driver that are simply toggled on or off as per-game settings, and then hacks that are more specific to games - up to and including total replacement of the shipping shaders with custom versions by the driver team. Ever wondered why nearly every major game release is accompanied by a matching driver release from AMD and/or NVIDIA? There you go.

I start to think about it every time I say some programming language is bad. I bet people cringed when some programmer brought in a square punch card instead of the traditional rectangular one in the old days. I don't even know if such thing existed. It doesn't matter.

Anyway, make code that works. Then when you have time try to optimize it. OK?

Good.

---