|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
| Sunday, November 26, 2006 |
  The Upsides of Germany | 
Posted - 11/26/2006 6:24:59 PM | I decided to break out of my hefeweizen rut tonight and give a stab at something darker (the steak just seemed to call for a darker beer). I asked the waiter for his recommendation and he came back with a Grimbergen Optimo Bruno.
I didn't realize until later, when looking it up on Ye Olde Interwebe, that it's actually Belgian and not strictly German. I am, however, willing to forgive that grave transgression, because it's one hell of a good beer.
It's definitely dark, but not excessively thick or heavy. The flavour is subtle; it wasn't actually until my second beer that I realized just how much detail and nuance was available. Until then I'd been ready to write it off as a rather mediocre brew, but I guess something about the after-dinner atmosphere and gentle settling of the palate brought up the richness. I'd definitely recommend enjoying this brew slowly after a meal, maybe with a little bit of white chocolate for contrast; drinking too quickly or between bites of food (especially strongly flavoured food like steak) will obliterate the details of the beer.
At 10% ABV, this sucker's a powerful beer, which explains the rather diminuitive serving size. It may also have had something to do with the uncomfortable warmth of the hotel room after the meal.
It seems to be rather hard to come by outside the region, but if you can get your hands on it, I highly recommend it. If not... it's absolutely worth the trip to Europe for a couple of bottles.
| |
| Friday, November 24, 2006 |
| Games: Then and Now OMFG On Topic! | |
Posted - 11/24/2006 5:36:11 PM | How It All Started
Games burned themselves permanently into my imagination at an early age. It started with classics like Zappa Roids and chunky, solid-color-blocks imitations of Pac Man. The Kroz series factored in heavily; the blunt and simple yet evocative ASCII graphics held a fascinating charm. Despite the draw, though, it was fiendishly hard, and I never was much good at it; to this day my older sisters are the only people I know who successfully finished an episode.
The turning point was Commander Keen. I will never forget one afternoon when my father and I used the old DOS EDIT app to look at some of the data files from Keen 4. One glance at the pages of cryptic, gibberish symbols and I was permanently hooked - I can't recall for certain, but I wouldn't be surprised if I swore to myself that afternoon to become a game developer some day.
It didn't take long for me to get my hands on some rudimentary tools - a Sharp PocketPC with embedded BASIC dialect; the copy of QBASIC that shipped with MS-DOS in those days; and eventually a growing collection of books and sample code snippets scrounged from wherever I could find them. Keen was the first game I tried to emulate, but the graphics and physics were far too advanced for QBASIC. I settled for Kroz, my other gaming obsession, and churned out dozens of clones and variants, eventually moving up to fully scrolling environments and (gasp!) 256 colour "graphics".
I remember the day I got ahold of a copy of QuickC from somewhere or other. If QBASIC (and, later, Visual Basic for the oh-so-exciting new Windows 3.1) was great, QuickC was crack.
The rest, as they say (at least when "they" are considerably more famous and successful than me), is history.
... and Now
Quite a bit of time has passed. Games are so far beyond the days of three-colour ASCII squiggles, and even pixelated sprites. Doom, once a veritable visual orgasm in its own right, looks dated and almost laughable.
The new generation of games is nothing short of astounding. We've been drooling over Gears of War here at the Egosoft office; the word has been abused to the point of nearly lifeless cliché, but at least in the original spirit of the term, Gears is awesome.
My feelings towards Gears are somewhat love/hate right now. The gameplay is simply peerless. The controls are simple and elegant; the only real hiccup (getting "snagged" on cover points while using [A] to run) is pretty minor and can actually be used to your advantage. The UI is clean and has some slick features like the "point of interest" button. The weapons, while not particularly new (as if anything could be new in the FPS genre), are deeply satisfying.
There's so many things to love: the blind fire, the spurts of blood on the camera when you chainsaw the hell out of an enemy, the way friend and foe alike dodge and weave around the environment, the grenades, the really insane enemies (no spoilers), the little reloading mini-game, even the smooth and almost undetectable streaming loads... it's a truly excellent game. As a gamer, it's blissful. So much so, in fact, that I actually bought a 360 just to play the game (although to be honest I was planning on getting one soon anyways).
My developer side is awed and deeply respectful of what's been accomplished in Gears. The skill and mastery of the guys at Epic is evident everywhere from the displacement mapped surfaces and dynamic lighting to the crafty placement of enemies and cinematic events throughout the world space. Frankly, most of us are jealous. (There's one guy who pretends not to be impressed, but that's just because he lost a bet with me that he couldn't survive more than 2 minutes on Hardcore. He got drilled by the first enemy in the tutorial section.)
As enviable and respectable as Gears is from a game development perspective, though, it's also terrifying. Gamers love to talk about how gameplay trumps graphics and how they're not influenced by the prettiest or flashiest title on the market. Sadly, that's a load of bull; the numbers are pretty clear, and the whining (often disguised as wistful "if only this looked better") comments on game forums are even clearer.
Gears doesn't raise the bar. It takes the bar, crumples it up effortlessly with just one finger, spits derisively on the tortured metal, and then flings the remains of the bar into deep space. Not just puny old interplanetary deep, or even intergalactic deep, mind you - I'm talking deep space, like the kind of distance that makes our cosmic horizon look like a hair's breadth.
Or, to use the phrase that popped into my head after playing through the first couple of levels on co-op: Gears lines up every single person in the world and kicks everyone's ass simultaneously.
It's great when you're playing it.
It's not so great when you're working on a title that will eventually arrive in a world that is looking for the next Gears of War - or, in all probability, the game that "kills" Gears. Having to compete with that is mind-numbingly scary; and rest assured, every commercial game for the next-gen consoles and PCs of the next few years will have to compete.
I'm hopeful, though; but I can't talk about why 
Back Then...
Earlier tonight, I finished replaying an old (as in 1994 old) classic called Dreamweb. It's a dark, brooding, and twisted adventure game that seems pretty obscure but is universally praised by those who remember it. I already know the entire plot by heart (the game isn't that long) and there's really only one path through the story so the replay value in that sense is low - but the world is so compelling that even on my fourth replay it's a great experience.
This particular replay was inspired by finding something I've read about but never seen - a PDF scan of the "Diary of a Madman" supplement that originally came with the game. It's a 43 page, handwritten backstory document that explains a lot of the game's details in depth, and reveals some vital clues to solving the puzzles in the game. I've only managed to read about a third of it, but it's such a huge contributor to the atmosphere of the game world that I have no doubt I'll reread it just as eagerly as I've replayed the game.
That got me thinking about Ye Olde Days of Games... you know, back when games still came with 43 page handwritten supplements and that kind of stuff. I suppose the mass-market corruption of the industry is to blame, but whatever the reasons, I'm honestly pretty sad that such things are so rare these days. Even "Collector's Editions" usually just have some art and maybe a "Making Of" movie or something. If you're lucky you might get a little plastic figurine or whatnot.
But long gone is the era when the supplements were an integral and potent part of the experience, where paper and cardboard and some imagination would radically increase the visceral impact of the action on-screen. That, if you ask me, is a damn shame.
As I started developing a taste for more sophisticated games, I found the supplements invaluable. I read the manual to F-15 Strike Eagle III religiously and at one point had memorized large sections of it. I did the same with the manual from Sim City 2000. I didn't care too much for Myst; I don't have the patience to try and figure out what obscure and arbitrary hurdles some game developer wants me to jump over (which is odd because I loved the Monkey Island games and The Dig, but whatever). I did, however, devour the manual. I obsessed over the backstory documents from the Warcraft series, committed the Dark Forces handbook to memory, and still thumb through the booklet for Return of the Phantom on occasion.
For all the earth-shattering allure of Gears of War, it's still soundly beaten by an obscure, visually drab, tiny wedge of a game from 1994 called Dreamweb. Gears has no 43 page supplement which begs you to pause the game and scramble madly through the pages for clues about what you've just seen.
If there's anything that disappoints me about Gears, that would be it. It's a pretty small thing, at least in today's gaming market, and it's so common that I'm grown accustomed to it. (The Halo games, for all their supposed quality storytelling, had piss-poor backstory supplements. It took book licenses to actually tell anything interesting about that universe, and even the books weren't all that hot.)
... and What Next?
As much as I'd love to say otherwise, I don't think this trend will be reversed. The age of rich experiences augmented by extra goodies in the game box is over and gone. There's no real hope of changing that, I think.
I suppose we could bring a 50 page manuscript and a hand-sculpted "Ancient Artifact" to the publishers and beg them to release them... because, y'know, it'd really enhance the experience for all three of the people who'd bother to read the thing. One person may even manage to keep the collectible more than a day before his dog eats it. Definitely money well spent, right?!
I'd love to get home and unwrap my waiting copy of Gears Collector's Edition, plunk down on the sofa with a mug of cocoa, and spend an hour or so engrossed in the dark history of the Locust and the terror they've inflicted on the poor human race in the years since E-Day. I'd love to pore over the journal of Marcus that he etched carefully while being tormented in prison, glimpsing the mind and past of the coldly efficient death machine. I'd love to attach a little Hammer of Dawn fob to my keychain and pretend to zap the fuckers that cut me off in traffic.
Even more than that, I'd love to see the next installment in the X franchise do something like that - I think it'd probably benefit more from a little extra ambience than an action shooter. It'd be endlessly cool to crack open the box and see a handful of "photos" on cards, showing random and bizarre events in deep space, with cryptic scribbled notes on the backs. I often wish for the chance to whip up a short story that explains all the events and past of the X universe from the perspective of an insider, and helps bridge the gap between previous games and the next, to explain some of the changes and history. An extra track on the CD could have some audio recordings with clues and hints to key missions and story events; star charts, galactic almanacs, weapons prototype sketches... I could literally have a comfortable full-time job doing nothing but designing bonus goodies for the games.
I think if I stumble across a djinn or analogous wish-granting device, I know what I'm going for. I want to live in a world where games are seen not merely an entertainment business, but as the art form that they rightfully should be. I want to see stuff like Diary of a Madman every time I pick up a hot new title. I want to see these things become not mere supplements or even complements of games, but rather integral parts of the experience.
And I want to create that kind of holistic, immersive art - art that transcends the digital and reaches its ethereal feelers into the realm of the everyday - art that breaks free of the confines of a virtual space and peeks into reality, the books and pictures and charts lying on the coffee table and inviting us all to leap through the portal.
| |
| Wednesday, November 22, 2006 |
| Heh. | |
Posted - 11/22/2006 9:14:34 AM | I probably shouldn't laugh too much at this, but I just discovered a new file in our codebase called fixedass.h.
I'm a little worried about where my imagination has been going with that one...
| |
| Friday, November 10, 2006 |
| Fix Yourself or Quit Whining | |
Posted - 11/10/2006 5:48:29 PM | News Flash: Programmers and Managers Don't Get Along Perfectly
Pull up your favorite aggregator of programming and software-project content, and do a quick survey: what percentage of recent articles are in some way about bad managers, dealing with management, how to appease your developers, how to stop being a bad manager, etc. ad nauseum? For a fun variant, what percentage of the "all time hits" fall into that category?
If your aggregator happens to look like mine (or Joel's), I bet the percentage is very large.
Now, presumably, since you're here, you have some aspect of the geek nature. (If you don't, this blurb isn't for you, so you may find it confusing and weird and possibly a bit frightening; you've been warned.) When confronted with an interesting statistic, like "a lot of people are churning a lot of words about programmers and management", any good geek should toggle the curiousity bit and ask the all-important question: why is this so?
This is by no means a recent trend; very wise people have been writing really good stuff for, quite literally, decades. More recently, we've given over to assigning icky words (like "immaturity") to the situation.
You don't have to read very many of these writings (old or new) to notice something telling: they all say pretty much the same stuff. The obvious conclusion is that the situation has, by and large, not changed tremendously over time. We can think of lots of icky tags, but not solutions.
So, we have two points: there's something of a tough situation, apparently, regarding programmers and management; and this situation has more or less not gotten cleared up in the past decades of growth and maturing in the software industry.
We can posit a few explanations:
- This is a fundamental problem of human nature and will never go away
- This is a fundamental problem of human nature but some combinations of people will be OK
- This is an artifact of a comparatively very immature industry and will change over time
- Someone's gone and buggered something up
Let's look at these in turn. There is anecdotal evidence that programmers and managers really can co-exist. (I've yet to see this myself, but I've decided to think of it the same way I think about Africa: just because I haven't been there doesn't invalidate the compelling evidence that it really exists.) That rules out option number one and possibly adds a point to number two.
For the sake of ruling out number two, let's invent a fictional situation where someone beat the odds and actually changed things properly. It's apparently very difficult but more or less plausible, so we'll fudge a bit and say it could happen.
Number three sounds good on the surface, but there really isn't much substance there. On a cosmic scale, yes, software is a very new thing, so naturally it's got some rough edges still. But the problem isn't actually software - it's human interaction, specifically between managers and programmers.
We can rule out number three with a careful study of ancient history. Go rent a copy of 2001: A Space Odyssey and watch the ape-man scene carefully. You will note that some of the ape-men seem to be in charge and have some initiative; these are the ancestors of what have become modern managers. Other ape-men in the scene are clearly the thinkers, who pore over hard problems and eventually find the all-important solutions (the star of the bone-smashing scene). These are the precursors of geeks and programmers. By this, we see that geek-types and manager-types have had, at the very least, a few thousand years to sort out their differences, and the fact that they have as yet failed to do so means it's probably not going to happen by itself any time soon.
In any case, managers-vs-engineers has been going on in some form for a long time, so point number three crumbles: the young age of the software industry is no excuse. I'll wager a beer that Michelangelo had some anal-retentive monk chew him out for taking so long on "that bloody ceiling... how hard can it be to paint a few square feet of scenery, anyhow?" - and another beer says that, if he had the means, he probably would have written a bitter blog entry about it and submitted it to The Daily WTF.
So, we're all out of options... damn, I guess this problem has us licked. We'll all just have to go back to work on Monday and quietly die a little bit inside, knowing we'll never resolve the programmer-manager disparity.
What? Option four, you say? Ridiculous! Nobody's screwing anything up... well, the managers are screwing things up, because they can't manage our projects right... but surely if anyone is at fault, it can't be us, the programmers.
Clue-by-four, incoming.
Why the Programmer/Manager Problem is Our (the Programmers') Fault
Consider the roles of engineers and managers. Programmers make stuff happen, and managers cause as much pain-in-the-arse as they can ... well, managers manage. God only knows what they really do; I tried to read one of those "management guide" type books once, and all the suit-speak gave me a nasty seizure. I try not to think about it.
Typical programmer snobbery aside, managers work with people. This is such a horribly abused and decaying cliche of a phrase that I feel vaguely ill for even bringing it up, but it's the truth. The role of managers is to interact with their team, and keep things running smoothly.
The core of this is vitally important, so I'm going to emphasize it: managers already, as a daily course of action, have their priority on interacting with other people. This is documented at great length, and the aforementioned brain-traumatizing books on management all handle a relatively ubiquitous issue: how to deal with people. By itself, this is no particularly shocking revelation. However, the implications are profoundly critical to understanding the problem.
Since managers, by definition, are in the business of working with people, any failed interactions between a manager and his team must be the result of either managerial incompetence, or the fault of the other party/parties involved. Although managerial incompetence is certainly a real issue in its own right, it is not sufficient to explain every case of programmer/manager friction.
The conclusion is plain. Unfortunately, it's uncomfortable and deeply painful for us programmers to hear. We want to deny it - and, I believe, we've been actively burying the inner voice for decades.
We don't have manager-problems because too many managers suck at dealing with programmers. We have manager-problems because too many programmers suck at dealing with managers.
At this stage, I'm envisioning my imaginary blog-audience rising as one, surging towards my imaginary blog-podium, waving little notepads and yelling questions like journalists in the press conference on Doomsday. The excuses pile up. I recognize many of them because I've read them in countless places. Worse, I recognize a lot of them because I've used them myself.
- My manager just sucks
- Software is hard/an art form/a craft/not empirically measurable
- Programmers tend to be introverts anyways so it's OK if we suck at dealing with people
- I've stopped caring (usually arrives in the form of "only naive newbies in the field care, and you can't fix it so grow up and deal")
- Our domain is really special/extreme/hard and so your advice doesn't fit my case
- I tried to implement change but my manager shot me down
- If you can't change your organization, change your organization (i.e. if you can't fix your job, get a new one)
None of these excuses is false. That's why, for so long, we've been content to accept them, tell that little inner voice to shut up, and gone back to work. Sometimes the voice needs a little bit of alcohol to keep it quiet, and every now and then the tension becomes critical and we have to go and write blog entries about how organizations are immature and project managers are glitches in the system.
However, true as these things may be, they're rather piss-poor reasons to avoid the real issue. Defeatism ("my manager sucks/I'll just change jobs") gets us nowhere, and sometimes isn't even really practical (poor job markets, for example). Yes, software is hard, but we don't need to try and make it easy - the solution lies elsewhere (I'll get there in a moment). Yeah, maybe you got smacked down for trying to change the system, but a nice frosty pint says you can try it again, with a different tack, and probably see some success. And I work in one of the most notoriously bad industries for programmer/manager friction, so when I say the problem is not insurmountable, just save us all a lot of time and believe me.
The Solution: a.k.a. Fix Yourself or Quit Whining
OK, fine... maybe we are the problem. Maybe there's something we can (or should) be doing differently to make our managers understand us. Let's get pragmatic so we can brush the whole last 30 years of agony under the rug and nurse our wounded egos in quiet solutide.
- If your manager doesn't understand you, it's probably not because he's dumb.
This is not something most people enjoy being told, but the sooner we accept it the better things will be. I've always been a notoriously poor communicator, and still am rather bad at it. However, if there's one piece of advice my father really drilled into my head, it's that all the brains in the world don't mean a damn thing if you can't explain yourself to anyone. Next time you're in one of those miserable four hour meetings about why the schedule has slipped, think this quietly to yourself, take a deep breath, and start from the beginning.
Each manager will be different; some can understand technical details, others can't, and still others think they can but really can't. Learn which category your manager falls into, and deal with it. Put yourself in his shoes and make a concerted effort to see things from his point of view. Now explain your situation from that perspective. Sounds like a dumb team-building-camp cliche, but it works.
- Install a bullshit-propagation limiter.
Never, ever, ever, ever lie to your manager. Ever. I know this goes against the very deep grain of common sense, that says that the professional world is a political one, and you can only survive with a healthy dose of tact. Tact is good, but never let it become mistruth.
This runs both ways. If you catch yourself (or another programmer) feeding bull to your manager, call them on it immediately. Do so in a friendly and non-confrontational way whenever possible, but do it. Stuff like "Erm... sorry, I don't see how that's true, can you explain your reasoning to me?" usually works fairly well. Conversely, if your manager is feeding you bull, call him on it.
How you do this will depend a lot on your team culture, but there is always a way to bring up objections. Just don't frame them as objections - if you present yourself as the one at fault (i.e. "I don't understand your reasoning") you avoid putting the other person in a defensive frame of mind. Better still, you make the other person feel like they're helping you out - which, as an ego boost, is always a good thing.
Just remember: if you have chronic bullshit infections at your place of work, it's because nobody is stopping it from propagating. It's your responsibility to call bull when you see it - often, your manager doesn't realize it's bull, especially in technical matters.
- One half-assed solution is more welcome than a dozen well-specified problems.
This is rather backwards to us. Among my engineer friends (software and otherwise), we have a running joke: the worst torment for an engineer (or mathematician, for that matter) is a fully-specified problem that he can't solve. In programming, it's more or less a truism that if you can specify the problem completely, the solution is (comparatively) going to be easy.
Therefore, it is tempting to present very careful analyses of problems ("our build process takes too long to do by hand every day", or whatever) to managers. We figure we're doing them a favor: by cataloging exactly what is broken and how, we're specifying the problem, and therefore we can all move forward on a solution.
This is suicidal and outright stupid. I once had an exasperated boss ask me, almost word for word, "You're really good at finding problems, but can't you ever think of even one solution?" I owe him a hell of a lot of credit for that - it was a wake-up call I desperately needed, and it's formed the basis for my thoughts on the entire issue of programmer-manager relationships. As engineers, it pisses us off when someone with half the facts barges in and suggests a solution to our fully-specified problem; we know what we're doing, dammit, and quit offering your unsolicited advice on matters you know nothing about! This is a particularly serious issue in programming when one has a "hands on" style manager.
However, we need to understand why managers do this: their role is to promote the realization of solutions. Problems are bad to them, and fully-specified problems are evil of the darkest kind. Managers offer half-assed, random, untechnical solutions to our code problems because that's their frame of mind: solve things. In pathological cases, this is embodied by the all-too-familiar "we have no problems, only solutions" rhetoric. We need to shut up and listen to those words carefully.
Next time you have a problem, don't present it as a problem. Present a solution, even if it's a ridiculous, half-finished solution. In fact, in many cases, suggesting bad solutions can be helpful - because it will stimulate discussion. If you're good, you can then steer this discussion towards your ideal/preferred solution gently.
- Silent pain can only lead to prolonged misery.
If you have problems, never let them fester. Don't let them sit around and cause morale problems. A good benchmark here is casual conversation at or after work: if you catch yourself bitching to co-workers about some problem on more than two days (not necessarily consecutive days), then you need to air the problem out with your manager.
Just "shrugging it off", or "bucking up", or any other such denial-centered reaction will only make things worse. If you have an issue with a technical policy, for instance, there's a good chance your manager doesn't know it's a problem. In this case, if you just sit around and get bitter, all your manager sees is a bitter employee - and this is liable to land you in serious trouble. Instead, bring up the issue with your manager. If you deny your manager critical information about the problems in his team, you're actively preventing him from doing his job properly - and, in turn, you're furthering your own bad situation.
The normal rules of tact apply here: don't call your manager out in public or in front of other people; do your best to place yourself in the "weaker" position, i.e. as the one with the problem or who needs guidance; and generally try to avoid triggering defensive reactions as much as possible. However, if you've done this repeatedly with no results, it may be time to pull your manager aside privately and apply some tough love.
- There is strength in numbers.
If you have a problem that affects more than one person on the team (as most problems will), don't bring it up to your manager alone, if you can possibly avoid it. Don't present yourself as the sole squeaky wheel. This raises your visibility and is likely to make you come off as a whiny jerk who needs to get canned. It also minimizes the reality of the situation: that many people are hurting as a result of the problem.
Whenever possible, approach your manager with everyone affected. Have everyone prepared to agree with you and back up your assertions. Be warned, though - some people may (sensibly enough) not want to rock the boat, and others may back out on you in the moment of truth. Employ sneaky tactics if you need to, like getting written statements/emails from people, but prove that you're not just bitching alone. Prove that you're bringing up something that is affecting the team.
In many cases, citing trustworthy books and articles is extremely useful. It may seem scary to send your boss a link to a blog about bad managers - but if you can, do it. Show that this problem affects not only your team, but other teams as well. Even better, bring solutions to the table that have worked for others. This overcomes the impression that your problems are unique to the people on your team (and the logical follow-up that the team's people may need to be replaced).
- You probably won't get fired.
Aside from some genuinely pathological scenarios, it's usually not a career-ending move to suggest that not everything is perfect. A common reason for inaction is fear of rocking the boat. Just remember, though, the boat is probably a lot more stable than you think - and, after all, rocking it is the whole point; we do want to solve the manager/programmer problem, right?
- Don't expect anyone to come to you - you're not that important.
Don't wait for your manager to solicit input from you; it's rather rare for anyone to ask other people if they're doing things wrong. Similarly, don't expect your manager to make some huge effort to come to you and get things worked out. Never rely on "meeting half way" - always be prepared to go the full distance, and maybe a little farther. (This does not mean you should try to avoid compromising to arrive at a solution, however.)
This is important for two reasons. First, it ensures the problem can't be ignored or forgotten. Second, and more critically, it shows that you are serious (and not just whining for the hell of it) and, moreover, that you are committed to fixing the issue.
As a corollary, don't rely on subtle hints, subtext, or anything else. If you have something to say, be clear and explicit about it. Anything else is too easy for your manager to misconstrue or just plain write off and forget about. Always assume that your manager does not see the situation from the same perspective you do - he probably doesn't have the same assumptions. What's obvious and a natural conclusion for you will probably never enter his mind. Leaving yourself open to interpretation is an invitation to be misinterpreted.
- Assume your manager doesn't comprehend your job. That's why it's your job, and probably why he's not doing so good at managing you.
This should not be a difficult stretch of the imagination by any means; it's actually almost a prerequisite to finding yourself in the situation we're trying to fix. However, your response to it makes all the difference.
First and foremost, you need to make educating your manager your own personal responsibility. There are two reasons for this, one of which is likely to mean a lot more to you than the other: first, it's actually your responsibility as an employee and part of a team to keep the leadership well informed and making good decisions; managers make decisions based on the data available to them and their understanding of that data, so if you don't provide all the data (or if you don't explain it properly) you have only yourself to blame for the resulting bad decisions. This is a tough pill to swallow but it's critical.
The other big reason to educate your boss is that it improves quality of life - not just for you, but for everyone else under his command. Believe it or not, it also improves things for your boss - if you succeed in improving the effectiveness of your team, he's in line to get some credit (whether or not its too much credit is immaterial). So it's in everyone's best interests for you to do this.
I'm not recommending you slap your boss over the head with your favorite software engineering book or anything like that; just make sure you're clear on the realities of the situation. This may take some forcefulness - a lot of managers will instinctively assume that "this is a hard problem" is geek-talk for "I'm too lazy to work on this properly." First, apply the bullshit filter and be sure you're not inventing difficulties that don't exist. Next, stand your ground; if it's really a hard (or impossible) goal, be adamant about this. Once you establish some trust (read: once your manager learns to quit suspecting that you're lying about how hard things are) you should be in good shape.
If you don't try to fix it, nobody will.
It may not strictly be true that nobody else will fix the problems. However, if everyone expects "someone else" to come up with the fix, then truly nobody will do so. Situations can be hideously complicated and subtle; chances are there are a lot of reasons - some better than others - why nobody else is fixing the problem.
The bottom line, though, is that somebody has to be the first to take initiative. If programmers start taking the initiative to solve the management problem themselves, I fully expect that the problem will turn out to not be so insurmountable after all.
| |
| Tuesday, November 7, 2006 |
| Bliss. | |
Posted - 11/7/2006 10:34:08 AM | Technology prototyping... time to develop: less than 24 hours.
Simulation population: 50,000 naive agents.
Simulation tick size: 1 second.
Simulation ticks executed: 5,000.
Total time elapsed: 33.7 seconds.
Estimated tick simulation time (per 50k agents): 7 milliseconds.
As the office jukebox currently says at loud volume: Word Up.
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | | 23 | | 25 | | 27 | 28 | 29 | 30 | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
