The Lazy Developer Paradox

Developers are Lazy. Yes. I said it, and for this reason alone, it is absolutely true. It may be insulting, or prejudice, but there is no doubt about it. Developers just hate working.

I am referring of course to software developers. Not Real-Estate or Photograph developers. They might be lazy too, only I wouldn't know anything about that. All I know is what I know (duh...). And I am a code developers for some time now.

A real developer will understand immediately what I mean. And she will not be surprised if I added that this same developer will code for days without food or sleep when the challenge is in front of her. And the root for this behavior, is one. No matter how'd you spin it, the main drive, or spark, or dark urge in the developer heart is that he simply DO NOT WANT TO DO THE WORK!

Now, if there is still a reader out there that do not agree (and I'm sure there is, because people are inherently evil), I'll lay out the example that supports my claim.

I used to work in a code factory (a.k.a: software-company) that made this one software product, and sold it all over the world. In those days, software used to come in expensive cardboard boxes, filled with many plastic diskettes numbered "one" to "lots", and a 20 lb user manual. All of these had to be introduced in the language of the country it was sold in. No french man would have payed good Franks to have his computer insulted by an English speaking User-Manual.

I worked in the "translation" department. Not that I know any language other then my mothers-tough (hell, I'm not even sure I have my mothers' tough). What I had to do is take out the English content out of the user manual, and the Software's menu and the Diagram captions, wrap it all in a neat little translatable package, send it to the translation-factory (or whatever these poor university graduate slaves were called), receive it back when they finished, and push it back into the Manual/Menu/Caption relevant areas.

I was bored out of my mind. It was repetitive, mind numbing, HARD work. When I could not stand it anymore, I wrote a small VB tool that just did it all for me. It opened the Adobe file editor, copied the text, converted it, merged it with the software menu, and repeat and rains. It was a silly piece of code, but it worked. It did the job a bit faster, and it allowed me not to do it.

Yes.
I was completely off the hook.

No more hard work.
All that was left to do is press a button....

And learn Visual Basic.
And Adobe-Publisher DDL.
And Trans-Script file format.
And Windows-Resource-File format.
And Debug, and Improve, and Fix-Bugs and Redesign and Refactor and on, and on, and on.
Forever....

So here is the Lazy Developer Paradox:

Developers (well, to be honest, at least some of them) write code to do their work for them. Especially when it is a simple task, with little-to-no mental challenge, and too much repetitive actions. And all these developers come across the same inescapable conclusion: Writing code that replace you, is VERY VERY HARD WORK.

And then they write code that write the code for you.

And this is how the next generation of programing language is born.

Helpful Errors

"Errors. The grate unknown. No single discipline may cover this weird and mysterious creature for all technologies...
...because what is error-handling after all? It is a curious man looking through a keyhole, the keyhole of mishap, trying to know what's going on." (Jacques Yves Cousteau)

I'm working on a new code base, and see this "errors.*" code file, And some of the errors (although, I'm happy to say, not most), reminds me an old joke:

A pilot needs to land a plane in Heathrow. It is about 4:00 AM, the fog is like a thick blanket, and his navigational equipment is a bit off. To put it in the simplest terms: the pilot is lost.
He flies around for some time, lower and lower, looking for some kind of landmark to help him find his bearings. Suddenly he notice a man looking at him out of a window. He slows down, roll down his own window, and call to the man:
"Excuse me, sir. Can you please tell me where I am?"
"Of course" - answer the man - "you are in a plane".
The pilot feels relief, turn 23.6 degrees left, continue for 13.51 miles, and land on runway 24B, just south of Heathrows' Terminal 5.
The control tower, that was aware of the pilots' predicament, asks him:
"How did you find your way?"
The man tells his story, and adds: "As soon as the man in the window answered, I knew I was over the Microsoft building. It is exactly their kind of help..."

So lets' imagine this scenario:
1. I sign-in into my e-commerce service.
2. I add some items to my basket.
3. I proceed to the checkout, and try to pay with my credit card.
4. The service return an error, saying: "CloseOrderValidationFailed".

What should I do? Should I pay again? Should I remove an Item? Should I join the navy?

CloseOrderValidationFailed is one of the errors in the "errors.*" file I looked at. It have a message, and status and code. The only thing it lacks, is meaning.

So what is a meaningful error? Here are some pointers:

• It should help the user. If the user see's it, and say "oh, right. my bad..." - it is excellent.
• It should never say "F**k you!". An error like "Payment Failed" is the same as saying "We do not serve people like you". Not only that it is not helpful, it is an insult.
• It should fit it's audience. You are in a bad place when your application display something like: "Error #26748. Please contact someone that know what this error mean!". Even if you know that the users that see this error cannot do anything about it, you must help him remain positive. And I do not mean "Please do not panic", but more like: "It appear we have encountered a problem (...appearance may be deceiving...). Please try to restart your application. If it do not help, try to restart your iPad. If you do not have an iPad, please contact us in the following address, and we will be happy to sell you one." - although it looks like a joke, most people will restart the app after the second sentence, and with some luck it will give you time to fix the problem on your end.

 Finally, some guidelines I constructed, mostly to help me when I need to design an error:

1. Talk about the "Why" rather then the "What": "Money withdrawal failed" is what happened. "Withdrawal amount exceeded the daily limit of 99$" is why it happened. Although it is helpful to know the former, I would rather be informed of the later.
2. Suggest a solution, even if it is an obvious one: "Cannot access the internet. Please make sure your LAN cable is connected properly" helped me personally more then once.
3. Be secured, but not frustrating: "Id check digit do not match RFC 3044" is definitely too much information, but "Make sure you omit leading zeros in the Id input" might actually save repeated head injury.
4. Be multi-dimensional: Error should be concise when displayed to the end user, and extensive when logged to the system audit. So "LoyaltyMembershipExpired" error will include an informative message saying "Your 'Pockimon-Go' membership expired. Please go to your town center to renew it", and also some other properties like "source", "account-id" and "stack-trace" that will be visible to the technician on the back-end.
5. Things get lost in translation: Any useful information that may be given by the error should be kept as close to the error source as possible. Do not fret to have your code, message, all your message translations and your formatting variables in the same error class (or near it).It is better not to relay on a client to convert your code into something readable if you can help it.
6. Be unique, but do not quench other information sources: Allow your errors to be unique in the system you manage, but always allow to include errors from external sources. There are cases when a third party system will articulate why it failed much better. Make it part of your error design.

And the most impotent thing: Never underestimate the need for good error design. From the error-class to the error-auditing - all this is an important foundation to a system that can last beyond the proof-of-concept phase.