Slashdot Mirror
Dungeons & Dragons and IT
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."
... if somebody would please take their dragon and keep it outside where it belongs!
If IT guys are the pen & paper RPG guys, what profession are those LARPers (Live Action Role-Players) belong to?
Pushing the envelope is really what creativity is all about, or at least it's a driving force for many people. No boundaries == no envelope && no envelope == lack of purpose.
Having to deal with strange technical rules regarding reality is par for the course at Order of the Stick. There's something here that hits a note with any techie (well, frankly, anyone) if you've ever played D&D.
Guess what causes the fires? That's right, "improving the network". What does the study show about network engineer's inability to keep their grubby paws out of things that are working perfectly fine thank you very much.
How we know is more important than what we know.
I always wondered why Dispel Barriers and Dispel Creativity had the same material components.
Sheesh, evil *and* a jerk. -- Jade
FTFA: Knowing this axiom of human nature, network managers can manage their team more efficiently by challenging their network engineers with more specific forward-looking issues and, more importantly, making sure they're spending an adequate amount of time focused on these initiatives. If a network manager only calls out the engineering team when there's a problem, all that manager is doing is preserving the status quo, not improving.
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.
Support NYCountryLawyer RIAA vs People
A lot of people need to be told specifically what to do.
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.
- Toby
Why do you think the most highly regarded poems generally are in one of the stricter poetry families (haiku, sonnets). Lots of structure, but within the structures, complete freedom to exercise creativity.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
"The greatest barrier to creativity is a lack of boundaries" is not really true. What they try, and fail, to get at is that being "creative" is easier the more information you have about the problem domain. In TFA they compare difficulty in "writing a story" compare to "writing a story about ...". Because the second problem gives more information about the problem. This has been well understood for a long time.
In the example they give providing some information about the "problem" that needs to be solved (e.g. more redundancy? less packet loss? Reduce operating costs?) will probably give good results, not because it provides "boundaries" but because it provides "information" and changes the problem from a sythesis problem to an analysis problem. Of course creating this information in the first place is a non-trivial task.
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
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.
The enemies of Democracy are
I"ve always wondered why so many of the people that play d&d end up as IT professionals. I don't know how popular D&D is now. When I was in uni, there were more current or former D&D players in the programming classes than not.
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.
Until a level 21 Middle-Manager cast a spell of unemployment on me.
I tried to beg the level 27 Vice-President of IT and the level 35 CEO to help me, but like the level 21 Middle-Manager their alignment was also chaotic evil so they cast a spell of disability and a spell of career-ruining on me instead.
Faced with serious mental and physical illnesses, I became a level 1 disabled person, but kept all of my Programmer/Analyst feats and skills, but I just couldn't use them for employment any more.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Because in spite of being among the more intelligent and logical bunch, you'll find few who wish harder that magic was real. And we know better than most that it isn't. The game is a chance to step out of reality for a while and flesh out what we imagine it could be like.
Question everything
I read the article, and I've also been peripherally involved with NetQoS' products. Although the premise is fairly straightforward and mostly correct, he makes some insane extrapolations.
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
D&D, and games like it, allow you to become someone else entirely. It's been my experience that people tend to choose characters that fit into one of two groups. A. Someone who is their polar opposite (it's fun to do things YOU would never do, and not really have to worry about the consequences) or B. Someone very close to themselves. The "B" characters are not necessarily less imaginative, as it still allows the player a great deal of liberty, while being enjoyable and able to 'stick close to home'. For example, one might play a character who is super intelligent, possibly pretty wise, but lacks much physical strength and dexterity. The punchline? The character is a Fighter. Or perhaps a Mage with great physical prowess, but a few fries short of a Happy Meal. These types of characters are often the most fun to play, because they make for some rather interesting situations down the road.
In the world of anal retentive ACLs, Stack Dumps, tedious reports, and just plain dumb users, who wouldn't want to just occasionally fantasize about swinging around a 6' sword and lopping someone's head off, or blasting someone into charred oblivion?
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It can also be caused by the fact that the network is flawed, and needs improving but because it can't be improved there are more "fires", and because there are more fires, there's no time to fix the network.
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.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
Problem elsewhere.
A simple network that is very prone to fuckup can be managed by morons. Managing it is simple procedural activity governed by work experience. By just sitting there and extinguishing fires according to instructions you gain experience which allows you to be hired elsewhere to extinguish the same fires. This is a concept UK bosses understand and cherish as 95%+ they hire solely based on experience, not skills.
If you design a network that can take a serious beating and still function after, managing it requires qualified people with skills. It requires people who are capable and willing to understand how the system works to be able to fix it on the rear occasions where it goes wrong. These are in very short supply (and getting shorter) so you always end up facing your boss in a silly conversation along the lines of "How can we simplify this". Not surprising as he does not see "experience items" which he can hire on. He is accustomed to hiring based on "you have worked with this in Company C", you should be OK working with this here". He does not know how select the correct skills and how to hire as he is most likely a failed techie or a humanities person with an MBA and he is not willing to delegate the evaluation to techies. Further to this, he is very happy to override any technical opinion on this in the name of nepotism and politics.
So no wander that 95% extinguish fires instead of building fireproof networks.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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. 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
A polar bear is a cartesian bear after a coordinate transform.
It's not necessarily always true, though. Yes, D&D characters tend to be heroes, as that's really the point of the game. However, as a counterexample, I've been involved in a campaign for two years where the two main PCs aren't the Conan the Barbarian type. One is a fairly ugly half-elf with a real ego problem and the other one is a dim-witted cleric who loves his god a little too much to the point of making everyone around him think he's a weirdo. Both of them held low rank in the worst company in their country's military for years in game time, and a lot of their "adventures" were doing really crappy jobs for their superiors. Once you put a player through that for a long time, any glimpse at being better than the average Joe Schmoe NPC is an awesome experience. It makes it feel like they really have "paid their dues" and as such their getting stronger is not a result of just killing random monsters for XP.
Granted, this is an unorthodox campaign, heavy on RP and low on combat (although it does happen, and we did once have a combat that covered three sessions as there were 30 soldiers + catapults vs. 50 soldiers across two battlemats in an all-out battle scenario). We don't do XP either, the characters advance by DM fiat when it appears that they have learned enough to progress or when story considerations demand it. They started at level 1 (effectively level 0 as peasants, that level got traded in for a real class), and after 2 years real time they are finally to level 10 and are adventuring on their own. They had a lot of help along the way as there are only two players in the campaign so there are a ton of NPCs that have been effective party members over the two years. Heck, some of the NPCs have as much stake in the story as the PCs and pthe players switch off playing them at times as secondary characters. One of the original PCs died and the player took over playing one of the more interesting NPCs at that point and still uses him as his primary. You know it's a big deal when even the NPCs have their own character sheets and backstories. None of the NPCs are heroes, either, most of them were from the same military unit or in one case was a town guard captain of the dinky town by the military post that got burned to the ground after the combo of a war, orc attacks, and undead rampages took it out. He was kind of a Sheriff Andy Taylor of Mayberry guy who had his whole life thrown upside down and has now become very bitter.
It's a fun, different take on D&D. There are very few monsters involved, and the worst thing the players have had to confront in combat was a human army. They spend more time geting screwed over by politicians and dealing with their own personlity flaws that get them into trouble. Creativity does play a large role in it, as the players actions often determine where the story is going next. We are constrained by the world that the campaign is set in (Forgotten Realms), but that gives a good springboard for story events to occur. Somehow everything, even spontaneous stuff, always manages to mesh with the world as it exists in game materials (even the ones that hadn't come out at the time - that's the weird part, some of the stuff we thought we "invented" for the campaign has shown up in newer FR books, so we're inadvertently keeping canon). Granted all of us know FR pretty well so it would make sense that we'd take it in a similar direction as the game material writers.