The educational value of The Daily WTF
Jan. 25th, 2012 08:37 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stephbgThe Daily WTF is a website of "Curious Perversions in Information Technology" and I read it every day. I also count this reading towards the professional development hours^ I am required to compete every year to maintain my certification as a Computer Professional via the Australian Computer Society (ACS). You may ask how I could possibly justify this as an educational activity. I'll tell you why.
Have you ever read a Dilbert cartoon and thought "Wow, I hope I never do that"? Well congratulations, you've probably just learned a lesson in management, business ethics or human relations. This is one of the points of parody, to mock bad behaviour and hopefull discourage its use. Dilbert's author Scott Adams has written a number of management textbooks to drive these lessons home, and while the delivery is humerous, the messages are serious.
The key difference between Dilbertand The Daily WTF is that the latter is driven by actual case studies unmodified for comedic impact. Posts include images of bizarre error messages, tales of projects gone bad, failures in recruitment and human resource management, and frankly terrible code and its consequences. It's both funny and terrifying.
I'll be the first to admit that I don't follow the code-based stories as closely as the others. I'm no programmer and of course the subtleties would be lost on me. But I have a fair idea that a 500 line SQL query is a Bad Thing, or that spending three weeks writing an elaborate customised DateTime function in lieu of using a simple library function is similarly a Bad Thing. I get that torturing global variables can lead to maintenance trauma for the next poor soul in the job. All of these things are useful lessons to learn, so that if I'm working with a legacy system I can appreciate a variety of problems the developers may face. True it's sometimes hard to spot the new lessons amongst things I feel I already know, but those subtleties and variations all build into a useful body of knowledge.
The Error'd posts feature interesting and entertaining failures of technology, not all of which are technical in source. More often than not the lessons learned here are human ones. I am particularly interested in the outside-the-box troubleshooting required when the source of a technical problem proves to be a human. Maybe someone in the office intermittantly moves a pot plant and trips a cable, taking down the network at irregular intervals. Perhaps this behaviour corresponds to the same type of system use by this particular person, so it looks for all the world that something they do with the software is responsible for the technical failure.
How is that educational for me? I consider it part of my job to break things, to imagine as many ways as possible a user might misunderstand a function, forget things, skip steps, or just trip over their own eyes and fingers. I work backwards from this information to write detailed troubleshooting guides. It's important to document "The error meassge X means blah blah blah" but I also like to include "You might be seeing X because you did Y incorrectly. See Doing Y in the user guide." I find this particularly important because in the systems I've documented errors can produce some apparently unrelated effects. The more case studies I study the more options I have at my disposal to apply to my own work. "Is it plugged in?" is always a good place to start; from there you can go anywhere.
Anecdotes are also a useful way to gently push one's own agenda amongst workmates. Having appropriate stories to hand of the chaos caused by undocumented sysadmin fixes and mystery scripts is a soft way to encourage a creatively-minded coworker to document their tinkerings for posterity and the poor souls who must follow them. But yet another lesson learned from The Daily WTF is that people are infinitely variable, and one must be prepared to try both soft and hard approaches to communicate any kind of message. Miscommunication is rife, and it's best to assume the worst. You can never be exposed to too many human foibles. Add foibles to technology and you get a heady mix of Things That Might Go Wrong.
So, am I developing my professional skills by regular reading of a humorous site? You bet I am.
(^) For the record I claim one professional development "hour" per month from all my IT news readings, although I spend several hours per month in actual reading and discussion time. Funny sites such as The Daily WTF and Dilbert make up only a small proprtion of this total, but I firmly believe that they belong in the accounting and are a valid source of education.
Have you ever read a Dilbert cartoon and thought "Wow, I hope I never do that"? Well congratulations, you've probably just learned a lesson in management, business ethics or human relations. This is one of the points of parody, to mock bad behaviour and hopefull discourage its use. Dilbert's author Scott Adams has written a number of management textbooks to drive these lessons home, and while the delivery is humerous, the messages are serious.
The key difference between Dilbertand The Daily WTF is that the latter is driven by actual case studies unmodified for comedic impact. Posts include images of bizarre error messages, tales of projects gone bad, failures in recruitment and human resource management, and frankly terrible code and its consequences. It's both funny and terrifying.
I'll be the first to admit that I don't follow the code-based stories as closely as the others. I'm no programmer and of course the subtleties would be lost on me. But I have a fair idea that a 500 line SQL query is a Bad Thing, or that spending three weeks writing an elaborate customised DateTime function in lieu of using a simple library function is similarly a Bad Thing. I get that torturing global variables can lead to maintenance trauma for the next poor soul in the job. All of these things are useful lessons to learn, so that if I'm working with a legacy system I can appreciate a variety of problems the developers may face. True it's sometimes hard to spot the new lessons amongst things I feel I already know, but those subtleties and variations all build into a useful body of knowledge.
The Error'd posts feature interesting and entertaining failures of technology, not all of which are technical in source. More often than not the lessons learned here are human ones. I am particularly interested in the outside-the-box troubleshooting required when the source of a technical problem proves to be a human. Maybe someone in the office intermittantly moves a pot plant and trips a cable, taking down the network at irregular intervals. Perhaps this behaviour corresponds to the same type of system use by this particular person, so it looks for all the world that something they do with the software is responsible for the technical failure.
How is that educational for me? I consider it part of my job to break things, to imagine as many ways as possible a user might misunderstand a function, forget things, skip steps, or just trip over their own eyes and fingers. I work backwards from this information to write detailed troubleshooting guides. It's important to document "The error meassge X means blah blah blah" but I also like to include "You might be seeing X because you did Y incorrectly. See Doing Y in the user guide." I find this particularly important because in the systems I've documented errors can produce some apparently unrelated effects. The more case studies I study the more options I have at my disposal to apply to my own work. "Is it plugged in?" is always a good place to start; from there you can go anywhere.
Anecdotes are also a useful way to gently push one's own agenda amongst workmates. Having appropriate stories to hand of the chaos caused by undocumented sysadmin fixes and mystery scripts is a soft way to encourage a creatively-minded coworker to document their tinkerings for posterity and the poor souls who must follow them. But yet another lesson learned from The Daily WTF is that people are infinitely variable, and one must be prepared to try both soft and hard approaches to communicate any kind of message. Miscommunication is rife, and it's best to assume the worst. You can never be exposed to too many human foibles. Add foibles to technology and you get a heady mix of Things That Might Go Wrong.
So, am I developing my professional skills by regular reading of a humorous site? You bet I am.
(^) For the record I claim one professional development "hour" per month from all my IT news readings, although I spend several hours per month in actual reading and discussion time. Funny sites such as The Daily WTF and Dilbert make up only a small proprtion of this total, but I firmly believe that they belong in the accounting and are a valid source of education.
