Good Developers vs. Great Developers

Have you ever taken your car to the shop only to find that when you arrived the very problem you needed resolved seems to have vanished? Gremlins aside, you then make an audible attempt to mimic your car. The look on the mechanics face, that feeling of well…silliness looms, you’re probably frustrated or embarrassed. If so, then you already know what it’s like to report a bug or issue to a software / Internet developer, you’ve been trained.

To be fair, it shouldn’t seem shocking that developers first assume we users are wrong, let’s face it, many times we can break what can’t be broken, we click what shouldn’t be clicked and cause one to wonder if common sense applies. That being said, there’s a difference between good and great developers, the difference is very simple. Good developers, in most cases, hear a compliant and immediately suspect the user but begin to explore their minds and tool chest of potential causes, resolutions and revisions to prevent recurrence. Even good developers can assign blame in an unforgiving and egotistical fashion, after all, if you know your code is good, it’s good right? Well maybe.

3193118489_581b460b2e

Unfortunately dismissal is a nasty disposition of most technical minds. Similar to a doctor, most don’t second guess their opinions as they are the experts. But how would a software engineer feel if the next time they went to the doctor with a visibly broken arm, they were dismissed as having a slight bump or sprain? Imagine, no x-rays, no cast, just a flat out misdiagnosis and release.  This happens EVERYDAY in the development world as system designers look but don’t “see”, they hear but don’t “listen”. The impact in many cases isn’t a broken limb, it’s a lost client, broken business, and the death spiral continues. But what about great developers?

Great developers accept from the baseline that a user is truthful, they believe in the user, they know they aren’t malicious and are genuinely reporting their perceptions while accepting that the user’s problems are frustrating and very personal. The best of the best, don’t take a problem report to heart, they don’t accuse the user of wrong doing or misuse, they step out of their mindset and attempt to view problems with fresh eyes. They ask questions, they pause and listen, “What is the expected result?”, “What was the actual result?”, “Was this issue caused by code?”, “Is there an anomaly?”, “Is there a hardware or network issue?”, or “Was there an individual or use problem?”. Most important in the troubleshooting methodology of great developers, the last person they blame is the individual. Great developers know that anything can and probably will happen, so instead of pointing fingers, they take responsibility to first ensure their work isn’t the cause.  After all there’s a certain level of narcissism in us all that wants to be right. Great developers don’t assume they are right, they prove it by becoming a user, they demote themselves to a lowly tester over and over, they avoid the easy road of dismissing a user. Great developers demonstrate the root cause of a problem, they show, they don’t tell, they aren’t afraid to teach, they are humble enough to hear.

Image by James LeVeque
Creative Commons
http://www.flickr.com/photos/jleveque/

Leave a Reply