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.
My wife and daughter are laughing at you. If I remember, we'll show your post to the rest of our gaming group, and they'll laugh at you too.
Me, I don't have time - I'm working on feat selection for my third-level warlock.
No Longer a Menace to Society.
Alexandria Morrigan born 2/22/01 l. 20.5in wt. 7 lbs. 5 oz.
"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.
Attention to all Slashdot authorities who think they are better than the rest of us:
You're not. Raving on Slashdot is *stupid*. It's the world's most useless activity. Get a job. Get married. Get a hobby that doesn't involve trying to save VIRTUAL communities. You're an adult for Spaghetti's sake.
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
Because if you hear voices in real life, it freaks people out. But if you say you hear them during the game, people assume it's normal.
Seriously: Geeks love stuffing their brains full of obscure facts and extracting them to demonstrate their vast mental superiority. Whether it's from a VAX VMS manual (which is actually worse than hearing voices in your head) or from the Dungeons and Dragons DM's Manual, it impresses others. Not ladies unfortunately, but it will impress other nerds. This is called "The Force Dot Net Syndrome" or "I can't win at the Jocks games so I will invent my own"
I'd love to play D&D, but have you seen those manuals. There are three thick core rulebooks, plus a zillion extra rulebooks and appenpums and addendiums. In a cave? Get the Wilderness Guide. A magical portal opens? Quick! The Planes Guide. It'd be a nice idea if they could describe the whole game in 32 pages, but there must be over a hundred tomes of 'essential' information.
Fortunately Blizzard, Mastercard and Peter Jackson have since invented things for those of us who can't be bothered reading.
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.
I don't think that article is long enough to be worth a d6 dagger... Medium sized daggers are d4.
I have no signature
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.
SJW: Someone who has run out of real oppression, and has to fake it.
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.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
There's a good strategy: do a crummy job to stay employed. Let me know how that works out for you.
Come review time, a good manager is less likely to focus on the 4-hour network outage 5 months ago that you could have fixed in 2 than she is on how much improvement there is in the overall performance of the network.
If you are doing a good job and things are running smoothly, then you need to make people aware of what you have been doing to keep it that way. If you keep quiet and nobody knows what you are doing, then you run the risk of somebody looking at you salary as a line-item on a budget and wondering why it is they need you.
I'll give you an example. Several years ago, I was running IT Ops at an F500 company. We made a small change to the trouble ticket system whereby we started sending out a monthly summary to people who had made requests, listing the requests they had made and their resolutions. We called this the What Have We Done For You Lately Report. While nothing else changed, the perception of the job done by the support team improved dramatically. On a scale of 1-5, overall customer satisfaction increased from 3.9 to 4.4 in a span of six months (surveyed quarterly) and stayed at that level even after I left the company.
Let me emphasize that. By writing an automated report that took a programmer less than a day, we improved customer satisfaction with the group from 3.9 (which is pretty good), to 4.4 (very hard to attain). Afterwards, I never had any problems asking for headcount or budget for that group, because people remembered what they were doing for them.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey