Dungeons & Dragons and IT 243
boyko.at.netqos writes "An editorial in Network Performance Daily tries to take a (1d6) stab at explaining why geeky engineering types are also typically the types that enjoy a rousing game of D&D. From the article "The greatest barrier to creativity is a lack of boundaries. Counter-intuitive — almost zen-like — but we've found it to be true. This is why people play Dungeons & Dragons (and similar games), and why network engineers often spend time putting out fires when they could be improving the network."
Re:O RLY? (Score:5, Insightful)
Putting out fires vs "impoving the network" (Score:5, Insightful)
Bad Manager != uncreative IT workers (Score:5, Insightful)
I find it strange that a opinion on management problems is based on D&D, but that's just me. This didn't say anything about the problem where a network engineer sees a problem but is held back because the management can't envision the problem as a problem, never mind fixing it.
What I see more often is groups that are having trouble keeping up with required changes (SarbOx et al) to run around making things perfect. When a problem does happen, it is put out like a fire and work shifts back to making required changes rather than trying to make sure that particular fire doesn't happen again.
Realistically (Score:5, Insightful)
Other people can work on their own provided they are provided with scope, goals, etc.
A minority of people don't need any guidance or roadmap at all in order to do their work and inevitably they are the ones who do the most innovation because their thought process is not confined to space/boundaries defined by someone else.
Poetry too (Score:5, Insightful)
almost, but not quite (Score:5, Insightful)
Yeah. Why are computer geeks so often D&D gee (Score:5, Insightful)
Honestly. You were wondering why? Maybe because they're both geeks. Geek takes geek profession, news at 11! And D&D is to a large extent generational, anyway. Later it's the collectible card game or video game geek, and before D&D it was the, I don't know, transistor radio geek. You get my point. Not all engineers are geeks, as time goes on especially, but it takes a mentality that was often found in the, say, socially unacustomed?
That doesn't seem to be what the article is about. It seems to be more about how you can get geeks to work better within well specified rules, with D&D as an explanation or example. Not that I really agree; the cool thing about D&D with a real DM was that you could do whatever you wanted even if the rules didn't say how. It's only computer RPGs that have rigid limitations. But it's probably good advice in general anyway, to have some well specified goals and restrictions. Goals that aren't well specified is a fun way to mess with player's heads if you're an evil dungeon master, maybe not a good way to manage.
this guy has it backwards. (Score:5, Insightful)
D&D helped me be a better engineer by:
1. learning and working with a complex rule set.
2. Reading and comprehending specifications. The rulebook is several hundred pages long.
3. Problem solving within a strict set of boundaries, both individually and as a group
4. Failing a quest gracefully, without a hissy fit or seppeku, and without blaming the Damned Managers! (DM)
Of course, I also found that many people like playing D&D specifically to fight about and try to break the rules. I ended up working with many of the same kinds of people.
Maybe the manager should run his project more like a DM running a campaign. Then see how hard they work, in full costume.
I'll tell you why (Score:5, Insightful)
Improving the network? I wish! (Score:5, Insightful)
Good network engineers, sysadmins, infrastructure support folks, and so forth, don't avoid improving their environments. They usually don't have time to do so, because any down-time from disasters is considered wasteful. In the rare event of time to work on stuff, they're generally so burnt out they don't have time. After nonstop hours (or days!) of fixing emergencies, they often barely have enough energy to slump into their chairs, let alone improve the landscape. Basically, they don't have the time or energy to reduce their workload, except when opportunity presents itself.
Now bad network engineers (etc.) have another problem, and that problem is called tunnel vision. They're incapable of seeing anything other than the immediate task in front of them, so even when the opportunity comes up to truly solve a problem, they duct-tape the broken symptom for the umpteenth time, and end up creating even MORE work for themselves. (And for the rest of their team, not to mention giving users an unrealistic expectation of service.)
In come the productivity enhancing solutions. "Our product will reduce these six disparate reactive monitoring tasks you do now into a single proactive tool." There's a good chance that it will actually do what it says, but only after a test phase, approval, design, rollout (including installing clients on all 400 of your servers), and then tuning. For a medium-to-large scale environment, I'd throw out a rough guess of 9 months, consuming an average of 1/3 of an engineer's time. Given that you're looking at a group of probably 4 people for that environment, that's not insignificant. Still, the company takes a look at it--they bring in a box to build a limited-scope test, and look at it for a few weeks. Those weeks turn into a month and change, and the group realises that the tuning will take a LOT of time afterwards (because extensive tuning isn't part of the proposed rollout scope or timeframe), and ultimately decides to say no.
The vendor's conclusion: These guys would rather put out fires than solve problems.
Not to say that the connection between D&D and IT is invalid, but the firefighting/systemic improvement argument is total crap.
Re:Wait...? (Score:3, Insightful)
It's simpler. (Score:5, Insightful)
Now look at some of the RPGs and LRPs which have failed over time. Tunnels and Trolls, for example. Treasure Trap. These are games that have far too simple a system. They lack the structure or the coherence I've outlined as existing in those games that do well.
Some of the themed RPGs - the Dr Who RPG, for example - have not done well because there is too much structure or too great an imbalance. There's no room for optimization or one thread gets all of the useful time.
No, a successful RPG or LRP is one that mimics the tools that every engineer - software or hardware - uses every working day, along with the same tradeoffs, the same architecture and the same flexibility. RISC-architecture games (like D&D) generally produce faster, more exciting games than those that are CISC-architectured (like Rolemaster), but each has devotees. And I'll bet almost anything that the devotee mappings are almost identical for the processor design as they are for the game design.
To say that they are both geeks is missing something much more fundamental. I've shown that RPGs and engineering are essentially identical. What about other devotees - the DIY radio geek mentioned in the parent post, for example? Exactly the same elements are present, in exactly the same form. Instead of balancing which stat to bump up, you're balancing circuit layout vs. noise, sensitivity vs. squelch, or any number of other factors. Imaginative solutions? There are hundreds of ways to make a tuned circuit, depending on how much drift you want to allow or how exact you want the results. Tables? Well, you look up any component spec sheet and tell me what there's plenty of. There's no such thing as a 100 ohm resistor, or rather there are a few thousand, depending on the exact characteristics you are looking for.
Oh, you'll find geeks amongst the wargamers, as well. A good game of "Squad Leader", "Britannia" or "Decline and Fall" has every bit as much mathematical elegance and logic as a finely-honed encryption library or precision-made racing engine. Again, if you look at the wargames that have done badly, you find they are mostly games with too little in them or are so heavy that they are unplayable.
They all have exactly the same common elements and - this is the key part - they all read like a diagnostic manual for so-called Geek Syndrome. In other words, the "geeks", the games, the professions and the hobbies are not logically distinguishable. Different sides, same coin. To say that a geek is attracted to the game has no more meaning than to say that the game is attracted to the geek. It just doesn't make any sense to make that kind of distinction. It simply doesn't exist.
Re:almost, but not quite (Score:4, Insightful)
Re:For picking up girl^h^h^heeks! (Score:1, Insightful)
It only impresses other geeks, and even then not all of them. Most regular folk find givers of gratuitous information to be pricks, if not fabulists. The line is certainly fairly thin, with the fabulists occupying a rather large subset of the socially inept geek circle.
Re:Putting out fires vs "improving the network" (Score:4, Insightful)
E.X. if it's really easy for someone to fuck up some critical thing in the network, they will fuck it up....often. If you're constantly trying to undo every network fuckup, you don't have much time to improve the network that would prevent people from fucking it up all together.
But here's the problem. If you stop undoing every single fuckup and just let the network remain broken for a couple days while you work on a fix for the network, your boss just thinks you're lazy and aren't doing your job.
Re:Bad Manager != uncreative IT workers (Score:1, Insightful)
You do illustrate a point (Score:4, Insightful)
And there you have it, the much saner explanation of why people would rather stick to fighting fires than improve something: it's not lack of creativity, it's that someone will blame you if anything, no matter how unrelated, goes wrong. If there's a fire, you have your excuse. If you just tweaked the firewall on your own, and an entirely unrelated intranet (i.e., not even accessed through that firewall) server crashes, it's you who's to blame.
And it's not just the network. There are other things that don't just work and stay working, but actually need constant monitoring and occasionally tweaking, or you _will_ get a fire. E.g., if an application server's utilization is constantly climbing, someone _should_ monitor it and notice the problem long before it becomes basically "slashdotted". If you just wait until there's a fire, and just stick to keeping your grubby paws off it until it's too late, then, frankly, you're dong a crap job. E.g., if a database is doing more full table scans than it should, then your job as a DBA should be to notice the problem long before there's a fire. Maybe the cache needs to be tweaked, or maybe the indexes or statistics need to be rebuilt, or maybe you should just notify the developpers that their SQL statements are crap. Keeping your grubby paws off it until there's a fire -- e.g., everyone's transactions start getting timeouts -- is, frankly, doing a crap job. Your job should be to help prevent the fire in the first place. And that goes for the developpers and maintenance engineers too, btw, not just the IT guys.
Except there too you're to blame if you did anything and anything else went wrong. If you just optimized one of the company's programs or the database, you're suddenly the one to blame if anything even unrelated goes wrong. E.g., you optimized the templates for generating HTML? Congrats, now you're to blame every time the user sees an error page. Even if in reality at that time the messaging system croaked, or whatever. The question will always first be if it's your change that caused it. Sometimes even if some unrelated program running on the same server, if it happened after your deployment, the first assumption will be, basically, Post hoc ergo propter hoc [wikipedia.org]. It must be because of what you did.
Additionally, if we're talking IT, a lot of companies have implemented a thoroughly counter-productive policy where you can't do anything without writing an invoice to someone. The mis-guided idea is to gauge the need for an IT department and make those guys justify their salary. The result invariably is that noone does anything any more unless explicitly being asked to, by someone they can get money from. Suddenly if you need, say, an Apache server, you have to personally talk to the server admins, and to the network admins, and to the MQ admins, and the Apache admins, and everything else. You can no longer talk to just one guy and have him ask the others for the details, because every single one of those guys need to justify their salaries by sending you a bill.
At any rate, that's the end of showing any initiative or creativity right there. Why bother tweaking the database server on your own? It's outright counter-productive. It's something you could be writing a bill for, if they just wait until someone else requests it. Just stick your head in the sand until there's a fire to fight.
Basically, blaming it on lack of creativity is somewhat missing the point.
Some people would be creative all right, and are creative in their free time all right. They write fan stories, write their own cool programs or libraries, try to code their own game or mod, are "wizards" (coders) on some MUD, role-play, etc. They don't reall
Re:Realistically (Score:3, Insightful)
Of course it requires great minds to innovate, but it is rare that these people really work on their own without constraints. Some of them do however, and the
BTW, I personally believe I fall in the second category. I once in a while tried to start my own mini-projects but never could find something that could interest me for more than a few weeks and they all ended being only occasions to learn new languages or skills, but every day I get paid reasonably well to find innovative solutions to other peoples's problems, I won't probably never change the world or be famous but I have a motivation (money and reputation), and it really makes a big difference in the quality of my work.
The real reason D&D is so appealing (Score:3, Insightful)
Ask yourself, when is the last time you saw a D&D character drawing that featured an overweight or underweight, pimply guy with glasses? No, in D&D everyone is muscular and/or powerful, with a beautiful girl hanging off each arm.
It's not about creativity, it's about escapism.
Re:bad example on creativity (Score:3, Insightful)
Synthesis is about "remixing" (a good term since that's what many electronic musicians/technicians do) old ideas in new ways. I'd argue that good synthesis has been responsible for many original works in many fields. Everything in the common knowledge base builds on something before it. An apple falling on someone's head five centuries ago has lead to physical theories that ponder the beginning of time. The quote attributed to Newton is really applicable here: "If we have seen farther than those before us, it is because we have stood on the shoulders of giants".
Long story short, synthesis has been responsible for many new theories and works of art. No, it's not original in the strictest sense, but what can you truly consider original? Even your story about a talking cave and a dog living inside a troll is just a rearrangement of words from TFA. This post is quite original, but it uses a famous quotation and paraphrases history to make its point.