|
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.
| Monday, February 27, 2006 |
  Verbosity | 
Posted - 2/27/2006 12:40:16 AM | It has been brought to my attention that my last post is ridiculously huge. I'm not sure whether to offer to pay hospital bills for those who endure reading the whole thing at a single sitting, or offer prizes.
In other news, shopping for good used cars is a pain in the butt.
| |
| Sunday, February 26, 2006 |
| Towards A Richer Toolbox | |
Posted - 2/26/2006 7:18:30 PM | Some historical context
NOTE: If you don't care about my navel-gazing musings, you can skip to the good stuff, starting after the horizontal bar below.
Those of you who have followed my activities for a while (you sick, voyeuristic freaks!) know that a while ago I was working heavily on research for a realtime raytracing engine. The project was called Freon 2/7, for no really good reason, and basically started out as an attempt to achieve high graphics quality without taking all day to render. Specifically, the project arose as a result of my tinkerings with the POVRay raytracing system; I liked the images it could produce, but I hated the render times.
I started out some research, found some other people to help tinker with the project, and over the space of about three years started to produce some results. Those of you who are familiar with the demoscene know that realtime raytracing has been more or less around for many years - but it works by making many assumptions, and many sacrifices. The goal of the Freon project was to find rendering solutions that were fast, generic enough to be useful for things like realtime games, and most importantly high-quality.
Eventually, I made some interesting discoveries, like some additions to kernel-based photon mapping estimations for global illumination. (Sorry, too lazy to explain that for anyone who hasn't spent a couple years dabbling in light simulation theory  ) Early on, it became obvious that dedicated raytracing hardware was the solution. After a lot of thought and investigation, I determined (and remain convinced) that the future of 3D graphics will be in programmable hardware that is specifically designed around raytracing, not polygon rasterization. I even started the early phases of negotiating with hardware designers and investors to actually produce a prototype chipset.
However, I was largely foiled by two critical problems: lack of money, and lack of time. These problems were, in fact, two facets of a single issue; I lacked time because I had to spend my time doing things that actually earn money. Like having a job. When I buckled from my contractor habit and started my day job, the project basically died completely. What free time I had was already consumed by games programming, so Freon has been untouched for over two years now.
This has always bugged me a little bit, and every now and then the whole deal comes back to mind and I feel compelled to finish what I started. (I had made repeated oaths, to myself and others, that Freon would finally be the first big project I actually finished. Oops.) Even more pressing is the fact that today raytracing hardware remains an unexplored frontier. Five years ago, my plan was to have consumer-ready cards on the market and in the hands of developers by now. Full-scale games targetting the hardware were due as early as 2007. Back in reality, the only really viable raytracing hardware project remains something of a non-starter.
What's ironic (to me at least) is that I've watched the SaarCOR project make a lot of philosophical mistakes that I dodged early on. At the risk of sounding like a pompous ass, I correctly predicted that certain ways of thinking about computer graphics would hamper RTRT efforts, and require ridiculous amounts of hardware power. I have not widely discussed my work on Freon for two reasons: first, because it is somewhat heretical from an academic point of view, and I don't have the energy to defend my all of my decisions; and secondly, because I'm still a little smug that I've got ideas for far more efficient solutions than are currently being explored. I continue to feel compelled to work on Freon because I still wholeheartedly believe that I've got a unique - and intensely marketable - concept here.
I don't bring this up to gloat about how I'm smarter than a bunch of highly educated researchers. That would be rather stupid. I bring this up not because I've got it all figured out, and they don't, but rather because I made a massive failing early on. I made one of my own critical philosophical mistakes, and it ended up costing me an opportunity to have a tremendously promising product on the market by now.
Originally, I was opposed to programmable hardware. I didn't disagree with the concept, I just didn't see it as being a viable entry point. Programmable logic is hard to build, and build fast. Doing a dedicated circuit first is cheaper, and educational: it helps illuminate the bottlenecks and weaknesses of a design while the design is still fairly easy to change. So, when I first started writing the Freon emulator software, the idea was to lay out the algorithms for a photon mapping engine in C code, and then translate that to hardware via tools like SystemC. It was a good concept... for a trivial and boring circuit. Realtime graphics is not trivial.
The mistake I made was in clinging to the "generic" requirement, and trying to make it fit with the "dedicated circuit" requirement. I wanted something that could rival (and, of course, surpass) the capabilities of rasterizer hardware. After all, if the raytracing card couldn't look better than Doom III, nobody would buy it. What I failed to realize was that programmable shaders have long since made dedicated circuits obsolete. Today, a single top-end video card can do some amazing things with shaders - things that were once the domain of raytracers. Things that I was counting on being able to do, that Doom III couldn't, so that I could sell my hardware.
Over the past two years it has become painfully clear that I screwed that whole decision up, royally. A dedicated circuit can't be extended and hacked on like a programmable one. A 1960's era telephone will never do more than relay sounds from one point to another; a 21st century cell phone can do all manner of things. The difference is programmability. A dedicated, inflexible raytracer card will never compete with a programmable rasterizer card, in the real world, because programmability is simply too powerful. Maybe the raytracer can do more nifty effects now, but in another year, someone will figure out how to do those same effects on a Radeon, and now your raytracer has no marketable strengths. More games will work on the Radeon, so the raytracer loses, and probably dies altogether.
After having a couple of years to ponder the whole adventure, and after a couple of years of seeing my "only serious competitor" fail to do anything really astounding with the technology, I've come to the conclusion that there's still a chance for Freon - but it will come at the cost of a massive philosophical shift. That shift is to build a platform, not a product. I really hate those terms (they smell like marketing and buzzwords to me), so let me explain what I'm getting at.
Platforms
The term "platform" is a fairly familiar description of a certain type of tools. Specifically, in the programming realm, a platform gives us the ability to develop new, interesting things, by giving us some pre-packaged tools to work with. Platforms exist on many levels, and come in many different sizes.
A computer architecture, like the IA32 architecture, is a platform: it gives us hardware to run programs on. An operating system is a platform: it gives us an easy way to talk to the hardware, and lets us build more programs. C++ is a platform: it's a specification for a set of tools (compilers, etc.) that we can use to build a whole lot of different types of programs. .Net is a platform: it gives us a massive library of prefabricated tools that we can use to make our own programs much more quickly and reliably. Spreadsheets like Excel are also platforms: they can be used to solve a huge variety of problems.
Usually, though, that's where platforms stop - at the "programming tool" level. This is mostly a philosophical issue; someone invents a platform, and wants it to appeal to Just About Everyone, so they make it into a programming tool. (The Unix realm is heavily polluted with this way of thinking.) Programming tools are great, but there's really only so many of them we can handle.
Domain-specific platforms
If we look a little closer, though, we find that there are more platforms out there, lurking under the guise of applications. Interaction tools like Exchange and Lotus Notes are platforms: they are designed to allow other types of software to do interesting things, without having to do the groundwork. However, we often misunderstand these, and just think of them as applications; this misunderstanding can lead to a lot of hate (c.f. how pretty much everyone despises the client end of Notes).
Games are also becoming platforms, to an increasing degree. "Modding" tools let players change the way games look, sound, and work. Some modding tools even let people build entirely new games. Traditionally, we don't call these systems "platforms" - we use words like "engine" and "scripting" and "data-driven architecture." But the idea is the same; games designed for heavy moddability are designed, in essence, to be platforms, on which more games can be made.
Seeking a more productive balance
I think software development, as a field, could benefit immensely from looking at this concept in a new light. Platforms are usually extremely generic (Windows, C++, .Net) or extremely domain-specific (the Half Life engine). Platforms often fail because they try to do too many things, and the end result doesn't do much of anything (99% of the Linux distributions out there). Some things fail because they really should be platforms, but people see them instead as applications (Notes... and Freon).
What we need is a balance, a mid-point between these extremes. Game engines are a good example: tools like Torque and OGRE give us the ability to do many things, but still within a specific domain. Torque isn't designed to make spreadsheet applications. Excel isn't so hot at making games. Yet both are extremely useful in their respective domains.
Code reuse is one of the most hyped notions in modern software engineering. It began with structured programming and subroutines, and it's been raging on ever since. Yet how often do we really get it right? Maybe we reuse one class in three projects. That's good. Maybe we make a platform that virtually everyone can reuse, and we produce .Net. That's good too. But there are a lot more than three projects in the world, and very few people have the resources to produce another .Net. Most people probably wouldn't use another .Net; the one we've got works great.
What we need is platforms that are generic enough to be useful for a lot of things, but still recognize that they can't do everything. These mini-platforms need to recognize their own limits, and refrain from collapsing under the weight of their own bloated feature creep. Many such platforms arise out of a sincere desire to acheive good code reuse. Yet many of them could be far more effective if they were thought of as platforms from the very beginning.
I've worked on a lot of programming projects over the years. I've written games, accounting tools, business management systems, store inventory systems, collaboration systems, highly specialized applications. Every time I enter a new problem domain, I wish dearly for a platform - not quite a .Net that does everything under the sun, but some sort of blob of existing, swappable concepts that I can use to avoid repeating a lot of effort. The "Don't Repeat Yourself" principle is burned strongly into me, both as a piece of my personality, and a part of my work ethic. If I've already done it once, I shouldn't have to do it again.
This is not a new concept at all. However, it is usually pursued with wild abandon, and that leads to madness. We like to get carried away, and make our platform do everything for everyone. Inevitably, these attempts make people disgusted. Moderation is the key.
I run a sort of idle curiosity called Tiny KeyCounter. The project innocently counts every keystroke and mouse click on your computer, and lets you compare your numbers with other people. Despite being utterly pointless and stupid, it's pretty popular. At the moment, the server for the project is dead (hardware failure) and I'm strongly considering leaving it dead until I build the fabled Version 2.0 of the software.
I want to do a Version 2.0 because I want to add more statistics: things like how many miles you moved your mouse today. When I first started thinking about TKC2.0, I had some vague notion of making it a "distributed statistics platform" where the software could track any kind of numbers you want, and compare them all through a unified framework. The more I thought about it, the more I realized the idea sucks. Nobody would want to use it.
I still want to make it more flexible, though. I want to make a platform for tracking silly, meaningless computer usage statistics. TKC has been successful because it doesn't take itself seriously. The project admits (sometimes very loudly) that it's all more or less a big joke. A "distributed statistics platform" would totally negate that, and make the entire concept more or less worthless. What I need is a mini-platform: extensible, so that others can potentially expand on the concept, but humble enough to know that it should not attempt to become a panacaea.
The way to do this, I think, is not to just build programs that let you write plugins. TKC1.0 tried that, and nobody wrote any plugins. Writing plugins in C++, VB, C#, etc. is boring and takes work. Even writing plugins in embedded languages takes skill and learning. Instead, I think the mini-platform concept should embrace the idea of highly domain-specific languages.
The essence of the mini-platform notion is to develop a high-level, highly abstract language where the concepts of a domain can be expressed and explored freely. This language should exist not as a binding to an existing language, nor as a language that tries to let one write any conceivable type of program. The language should be specifically and solely for discussing the problem domain, and for doing interesting things inside that domain.
I want to do this same thing with Freon. I did a lot of experimentation with new and wacky rendering techniques and algorithms. Usually, changing from one algorithm to another meant massive code rewrites. Since I was trying to build a dedicated application, I lacked dexterity and flexibility in my design philosophy. I have a backlog of dozens of cool algorithms I want to try, but would take literally months to write from the ground up as new rendering engines.
Towards the end of the project, I started to realize just how desperately I wanted a mini-platform. I wanted a way to easily explore new methods of rendering. I wanted to be able to describe rendering algorithms at a high level, with lots of abstraction, but without having to build them an existing language like C. Now, almost two years later, I've figured out what I really needed: a programming language that was designed specifically and solely for ray-oriented graphics technology.
More interestingly, I think that's the future of the hardware, too. A dedicated circuit is a dinosaur that will not compete against programmable technologies. Even a programmable photon mapping engine is limited, though. What I think we really need is a hardware mini-platform: it speaks the language of rays, but does not restrict itself to one particular rendering method. Path tracing, Whitted raytracing, photon mapping, and some of my own techniques should all be possible on the hardware - and not merely possible, but naturally easy to build.
My opinion is that this same pattern could have very good effects in other areas as well. I think we're close already; a lot of software sort of accomplishes an existence as a mini-platform, without ever directly realizing it. I'd like to see some smart people apply some time and thought to this notion, and see where we can go by capitalizing on it.
What kinds of things do you see being useful as mini-platforms? How could existing projects be given more clarity, more direction, and more appeal by doing less? We've had the dream of highly extensible "plugin-centric" software for years, and code reuse is right up there with it. How might a mini-platform concept get us closer to those ideals?
If we set out to build a domain-specific language for every interesting domain, how much more efficient could we be? Most importantly, how many doors could we open for those who know the domain well, but not the existing platforms like C++?
| |
| Friday, February 24, 2006 |
| Time Management and Multiple Personalities | |
Posted - 2/24/2006 12:12:44 PM | Originally, I set out to do a sort of "Day in My Life" entry, that broke down what I do at my job on a per-hour basis. I started 2 days ago around 6:30 AM, which is when I woke up. [My sleep schedule has been totally random lately, which is partly really cool, and partly really disorienting.] I then logged what I was doing for the next massive chunk of time (close to 28 hours, not including an incidental nap).
Unfortunately, it didn't work out so well as a journal entry. Often I'd just totally forget to log what happened for a few hours, leaving weird gaps and mysterious inconsistencies in my accounting of time. Once I just fell asleep for 6 hours. Worse, most of the notes I kept were really trifling little blobs; they aren't interesting to anyone who isn't working on the project. After a while, I started just interjecting stupid thoughts and observations, and it became a mass of jumbled idiocy that was neither fun nor informative to read.
So I chucked it out. There really wasn't much use to it, and it wasn't worth the time.
That's not what I find interesting, though. One curious side-effect was how it affected my work patterns. I started to see little web-surfing breaks as massive chunks of time, rather than just vague "oh, look, it's getting dark out and I still haven't done any work." Quantifying the amount of time I spent working and goofing off really made me feel like an idiot for slacking around too much, so I ended up doing a lot more work instead.
That much wasn't too surprising - time logging is a well-known technique for time management. What was really different was the way my thought process was affected. In taking notes on what I was doing, I had to justify aloud some of my design decisions. Now these decisions are all made with discussion and agreement from the rest of the team, so they're by no means arbitrary and off-the-cuff things. Yet, when I started trying to explain them in a way that would make sense to an outsider, I started seeing all kinds of new opportunities to make even better decisions.
Discussing and verbalizing design decisions is not a surprising new technique, either; I've been doing it for years. It's part of why team programming (and micro-scale practices like pair programming) is such an effective tool when used correctly. It's a sort of extra mind to make sure that everything is sane and sensible.
So often, though, that extra mind is an insider, and if one insider is prone to make some oversight or bad decision, another insider is just as vulnerable. We all get so involved in the system that we can't see beyond it, and at some points, even peer-review won't catch the really deep, subtle, and subconscious assumptions that give designs the most trouble.
When I get into a system, learn it, and start to develop a zone-sense for it, I get a sort of holistic, top-down feel for how it all works. I have an intuitive feel for what will happen if I poke the system in certain ways, and that by and large is how I do design. For the most part, this works great; but the danger is that one can get too accustomed to that sense. One might know how the system works now, but when doing refactoring and redesign, that is not enough information. You have to know what else could be. A redesign requires you to step outside the system, look at all of the truly available options, and consider them objectively. Getting stuck in a rut of "how it already works" can be deadly.
So, the next time you go to adjust a design, develop multiple personalities. Create an imaginary friend that has never touched your system before, knows nothing about the design, and maybe even isn't a programmer/designer. Then justify everything you do to this imaginary friend. Avoid the temptation to make excuses and empty rationalizations; really sell this guy on what you're doing, and why it's the best possible choice.
| |
| Monday, February 20, 2006 |
| Death Marches, Vision, and Mutant Space Potatoes | |
Posted - 2/20/2006 5:52:21 AM | Writing is a funny thing. Every now and then, I get a weird sense that I have something to say, but I can't quite place what it is. Typically, I'll cast about for a few hours, trying to figure out what exactly it is that's making my brain itch; typically, I fail at this. At some point I figure out that it's just better to start writing about absolutely nothing, and see what comes out. After a few false starts, the original stuff manages to chop its way out of the jungles of my mind, and then I can spew it all into incoherent paragraphs for posterity.
I do not think that right now is one of those times. I think right now is primarily procrastination. So, I invite you to come along with me, and see where my brain ends up taking us. I have a feeling we'll both be surprised; I can't promise any satisfaction or enjoyment, though. There might be mutant space potatoes with ray guns.
Anyone who has ever worked on a software project, even a tiny one, knows about the Death March phase. It's that ugly, dreary chunk of time, usually at the end of the project. It's when everyone is sick and tired of the project, would rather do something else - anything else - and just wants to ship the damn thing and move on. Tempers are short, hours are long, and even the most rabid coffee connoisseurs quit whining about the burnt Folger's in the office coffee pot and drink it just because it has traces of caffiene in it. The Death March is the "make it or break it" period for a project; either you pull through and put out a win, or you sort of phase out and dribble out something that vaguely resembles that product you were dreaming about so eagerly not too long ago. In the worst case, the project may just get canned entirely.
Death Marches occur, in various degrees, in all projects in the software realm. I think they also occur fairly often in other realms, too, but I don't know much about those realms, so I can't say for sure. (This is not to imply that I know anything about the software realm, mind you - I'm just better at pretending to know things about the software realm.) That nifty little applet you're writing for Grandma is going to hit a Death March. Massive corporate systems have Death Marches. Games have Death Marches; in fact, games usually have some of the most publicized and well-documented Death Marches out there.
The reasons for Death Marches are diverse. People much smarter than me have spent much more time than I have thinking about and writing about those reasons. (I've only spent a couple of minutes thinking about it.) My theory is that the biggest cause is feature lock: eventually, you reach a point where you have to stop creating new stuff, envisioning new possibilities, and just finish the thing that you're already committed to. I can't pretend to really know why, but that transition point seems to mark a decided drop-off in enthusiasm and drive. Good project leadership is prepared for this and knows how to handle it. Bad project leadership is likely to just let the whole thing fall into the crapper and drown. (Pleasant metaphor, isn't it?)
Anyways, I'm not really smart enough (or edumacated enough in things like psychology and management) to know how to cure the Death March phenomenon. Hell, I don't think it can be "cured" at all in the sense of just making it go away; I think Death Marches arise from very real shifts in the emphasis of projects over time. I do know that good leadership makes all the difference in whether or not people actually die during Death Marches. (While I have not, in fact, seen anyone really die under bad leadership in a Death March, I know of many cases where people wished they were dead.)
What I'm interested in at the moment isn't so much the Death March phenomenon. I'm not involved in any Death March projects at the moment, so I don't have any fresh thoughts on the whole situation. I also have a bad tendency to totally forget things when I quit dealing with them actively, so I have no particularly pertinent recollections from past Death Marches to share.
The thing that's been brewing in my mind, making my brain itch so to speak, isn't Death Marches - it's a similar phenomenon, but much less documented, at the other end of the time scale. Death Marches begin when it's time to just buckle down and get the stupid thing done. But something else happens, something similar and yet more subtle, and much more insidious, at the beginning of a project. That Thing is what, I think, has been sparking a lot of my own procrastination lately.
I have no good name for it, so I'll make one up (you may wish to avert your eyes): Pre-Vision Boredom. During the most passionate, invigorated, and adrenaline-charged segments of game development, there's something that really keeps the team going; that thing is responsible for getting everyone to work early, keeping them there late, and keeping them raving about it in thoroughly excited tones. That thing is what makes it so awesome to be working on the project. That thing is why we love our jobs (even if the job isn't game development, but some other thing).
That thing is Vision.
Vision is the core of motivation. Communicating vision is the core of leadership. Project leadership is all about rallying the team behind a vision, getting everyone excited about being a part of something. Vision is the ultimate fuel for our deep human need to be a part of something larger than ourselves. Vision is triumphantly getting some chunky images on the screen, and knowing that when the game is all done, it's gonna be so freakin' cool. Vision is looking up the long, hard road of development towards the finished product, and being so caught up in the joy of that product that we stop seeing the road itself, and just walk.
Death Marches occur when vision starts to fade. The feature list is shrinking, and most of the cool stuff is done. The bug list is starting to grow - probably very rapidly, as alpha testing and usability testing starts in full force. Suddenly, the finished product isn't so easy to see anymore. The road starts to fill our sight, and without good leadership to keep the vision alive, the team is liable to stare so hard at the road that they fall face-first into it and crash.
This much is pretty well known. I'm sure some very eloquent and insightful people have said it better, in many places that are not my journal. But I think they've missed an equally dangerous, but much less visible, problem with vision.
The problem is what the team does before they catch the vision. At the beginning of a project, especially an expansion or sequel type project, this is a very real issue. It's something I personally have been hit hard with, especially without the infectuous physical presence of enthusiastic coworkers. Vision is so much easier to convey in person; it just seems to lose something when all you've got to refer to is the project Wiki and some IM conference logs.
One of the best bits of advice I've ever heard for self-motivation is to just start - don't worry about getting it done, just get started. Once you start, catching sight of the finished product - the vision - is that much easier. Once you've got the vision, wanting to finish isn't a problem anymore. But if you just can't see that vision, you may never really truly get started, and that's where problems arise.
I've almost caught it. There's some possibilities for this next project at Egosoft - largely of a technical nature - which are really exciting me. When I get into the code, and start doing real refactoring and documentation, real work, I can start to see the edges of the vision coming into focus. There's just so much potential, so much opportunity - but not quite yet enough to hit that critical mass and propel things forward into solid, dedicated work. There is potential for much good, yes, but there is also potential for a lot of failure.
Grabbing on to the Vision is everything. I think it is largely the responsibility of leadership to maintain, keep, and spread Vision. However, it is important to remember that everyone has to have a slice of the Vision to work optimally - and the best way to sell someone on a Vision is to let them play a part in it personally. Egosoft is absolutely exceptional for letting individuals play a part in the Vision, but we still seem to lack a little something in the realm of developing a coherent and compelling Vision up front.
I think that, for any team, the sooner Vision is ready for everyone to start being a part of, the better things are liable to go. Losing the Vision at the moment of truth is a danger, but it can be just as deadly to neglect the Vision when the first critical (and irreversible) decisions of the project are being made.
| |
| Thursday, February 16, 2006 |
| VS2005 Woes | |
Posted - 2/16/2006 3:48:38 PM | I'm having a very mixed experience with VS2005.
The look is nice, aside from the toolbars, which just look dull. (Why does Microsoft have this compulsive need to invent a new way to render toolbars every year?) I really like the new Start Page over the VS2003 launch mode. The installation was fast (compared to VS2003) and easy, without any weird Prerequisite steps. One thing I never understood about VS2003 was why the Prereqs CD has to be run first even though the "Disc 1 - Install" CD says to put it in first. Seems like a silly oversight, and at least that kind of goofiness is gone in 2005.
Other than that, though, I hate it so far. The install failed to properly register solutions to open in VS2005, so all my code tries to open in VS2003, which of course can't read the new solution files. The new "Repair File Assocations" feature is nice, but didn't work - .sln files remain stoically associated with VS2003. I had to do some manual registry tweaking to get that to go away.
So once I could actually open solutions, I went to do some compile testing to see how things look. I had to do some twiddling with Include and Library paths, which is somewhat to be expected with all the SDKs I use, although I must say I'm disappointed that nobody at Microsoft has yet realized that they can import my old settings. Every time I upgrade VS, I dream that I won't have to redo all of my personalization. Every time, I'm disappointed.
I had to go back through all the menus, toolbars, and little tear-off panes and arrange them the way I like. I can understand some things not being importable from prior versions, but it's just a nuisance to have to redo all of it. That's all one-off migratory pain, though, which I'm willing to let slide, disappointing though it may be.
The real kicker is that IntelliSense now sucks. Approximately every 2 minutes, VS2005 will "Update IntelliSense." This process takes about 35 seconds to a minute on a project the size of the one I'm working on, and totally pegs the CPU for the duration. It doesn't background it, doesn't thread it to keep it from deadlocking VS - the entire IDE is dead and the rest of my system is sluggish until the update finishes. There is no button or key that will cancel it as near as I can tell.
As if that wasn't bad enough, it also does this spontaneously during builds. What the HELL, Microsoft? How can you not think to disable CPU-intensive tasks during a build? I can't even change build settings for other build configurations while a compile is going on, but somehow it slipped your minds that "updating IntelliSense" during a build is really stupid?
But wait! It gets even better! About 60% of the time, this "update" process totally kills VS. That's right - dead. Locked. Frozen. Kaput. Open task manager again, end process. This has apparently already been investigated and fixed according to the public VS bug tracker. The "workaround" is to remove a DLL so that the entire IntelliSense subsystem fails to run. Err... sorry, no, that's not going to cut it. I may as well use Notepad at that point. IntelliSense controls statement completion, class hierarchy generation, and apparently a bunch of other stuff, because disabling it basically turns VS into a glorified brick.
I want to like VS2005. I really do. Hell, I want to love it. The function caller/callee diagramming stuff is just awesome, and the OpenMP support is very much important for our future plans.
Sadly, though, until we get SP1, I think I'm going to be forced to hate it.
| |
| Wednesday, February 15, 2006 |
| Cleaning Stuff Up | |
Posted - 2/15/2006 9:30:45 PM | Well, I found a reasonable service that would haul off my car and get me a tax-deductible charity donation receipt for it. So I don't get any outright cash, but I will get a writeup worth, at the absolute least $150, and likely substantially more. I get to find out the actual value once the car is auctioned off; apparently the tax law goes that I can deduct market value for the car, or some such. That'll be a relief, especially since I'm technically self-employed now, and tax writeoffs are welcome in any form.
I've also been doing a lot of cleaning and reorganizing around my flat. It's very refreshing to actually have the energy and motivation to do that kind of stuff, since I very rarely did during the Evil Day Job.
Cleaning up seems to be Theme of the Week in my life. In preparation for Projects Future, we've been doing a massive code analysis and refactoring process. The first phase of this is a dead code hunt; during the hectic crunch mode on the X3 project, a lot of code got shuffled around, orphaned, etc. So I'll be taking care of cutting out excess junk, as well as updating any code that relies on deprecated methods.
After that is a hefty physical architecture change, moving files into new directories, splitting modules into more finely-grained and aptly-named files, and so on. Once that is done we'll be doing actual refactoring to group together some bits of logic thhat are currently spread out across several modules, as well as eliminating some redundant routines and building a few centralized libraries to replace a lot of special-case hard code. A few previously hard-coded things will be converted to a more data-driven design as well, which will be immensely helpful in the balancing phases of Projects Future.
One of the most promising things that has happened is the adoption of some good project management and documentation tools. We've started using a pair of packages from Atlassian: JIRA for task tracking, and Confluence (a WIKI package) for doing broader documentation and specifications. Both are fairly nice; they won't dethrone massive teamware that already exists, but they cost a heck of a lot less, which makes them more than worth it. So far both tools have been perfectly adequate for what we need, and customizable enough that we can adapt them to our own methods. JIRA has already paid for itself just by virtue of the ability to see, at a glance, what works is being done and by whom. It'll probably be a while before we have any considerable amount of content in the Confluence wiki, but it's shaping up to be worth its (digital) weight in gold, too.
Atlassian's products seem to have one niggling little oversight: they require a lot of clicking to get around. On a high-speed server, though, that's not that big of a deal, and the ability to batch-manipulate tasks mitigates that problem quite nicely. There's a few things that could be done better, but the price is most definitely right. Considering what these tools replace (a nasty hacked amalgam of forums, email newsgroups, and tiny custom ASP scripts) it's a huge step upwards.
| |
| Monday, February 13, 2006 |
| Day... ah, screw it, I have no idea what day it is | |
Posted - 2/13/2006 1:51:15 AM | Well, my car is dead. There's a rod broken loose in the engine that's pretty much destroyed things, and the timing computer has tried to "compensate" by downtiming the engine so much that it barely runs. It currently sits, dejected and stripped of all my belongings, at a local garage.
They want to make me pay $25 to have it "impounded" and removed, which is total B.S., because there's a good $500 worth of salvageable parts and goodies left on that car, all of which are in perfect condition. Heck, there's four perfectly good door panels on the thing which I know from bad experience are worth a pretty penny. So I'm looking for a way to get some cash back out of it without having to actually do the work of dismantling the usable parts and selling them myself (which I have neither the time nor tools to do).
Incidentally, if anyone knows of any services that will pay for such cars, please let me know - especially any in the Atlanta metro area.
Random thought for the day: why hasn't anybody written a book on software engineering and production methods for games? Anyone with any real world experience knows that different types of software have very different constraints and requirements, and yet it seems like all the good engineering-practices books out there are aimed at business logic or shrinkwrap products. Seems like a prime opportunity for someone to come along and fill that void.
| |
| Thursday, February 9, 2006 |
| Day... something, plus... something else | |
Posted - 2/9/2006 6:32:49 AM | I've been up since 4PM yesterday, and it's great. It feels kind of weird to be winding down at 6:40 AM, but at least I'm no stranger to bizarre schedules.
I finally figured out how to start a GDNet Gathering group, so now all us other Atlanta area people have a group. Hurray. I really don't expect much of anything to come from this, especially since nobody else has set up a group yet. I mostly did it so I can stop worrying about the GDNet Gathering interface being smarter than me (that Create Group icon is really buried).
Nothing much interesting on the work front; doing some refactoring and code cleanup stuff, and a little bit of research on project coordination systems. Huzzah.
I'm starting to feel a little fuzzy in the brain, so as soon as my Mountain Dew wears off, I'm going to go curl up with my shiny new copy of The Mythical Man Month and absorb some good ol' wisdom.
| |
| Tuesday, February 7, 2006 |
| Day... Something. | |
Posted - 2/7/2006 4:11:37 AM | I was awakened early (read: before noon) this morning, about 9:30ish, and amazingly enough I've been running strong since then, with just a short hour nap sometime around 8PM. I'm sure my mother would kill me for doing this (she was always big on the early-to-bed, early-to-rise thing) but I definitely haven't felt more energetic, alert, or motivated in years. So far I'm giving this free-running sleep thing five out of five stars.
I sent in a proposal today for some new framework and rapid-development library code for missions in the X3 addon project. The ideas I've had are nothing new, just formalized so we as a team can finally get down to actually implementing them and benefiting.
Well, as it turns out, someone else has already been working on this for the past week... oops! I'm seriously going to have to find a solution to the out-of-office communication gap that I have right now. I basically blew two days of thought, planning, and prior-code analysis to build that document, and I was about to start implementing new code when I finally heard.
On the plus side, I'm starting to talk with the team lead and our resident web server guru/admin about implementing some new project coordination tools on our development intranet. I'm definitely going to be putting pressure on that now, since my first week of work got borked by precisely the lack of coordination that we need these tools to fix 
Currently it looks like my real actual project will be either in some code refactoring in preparation for Big Future Stuff (can't talk about it, use your imagination ), developing a new tutorial system for the game (those who have followed my rampages in the Game Design forum probably know where I'm going to take that one), or both. Those are things I've also expressed a lot of interest in, and frankly they're more fun than building library routines anyways, so no big loss 
For something not related to game development, I've been stockpiling books lately. One thing that I really hated about the Evil Day Job was being too drained to read (usually, if I tried to read, I'd fall asleep). Reading is one of my favorite activities, so I'm really happy to have a life arrangement that lets me get back to reading a lot.
I'm about 3/4 of the way through Gödel Escher Bach, which has been utterly fascinating thus far, even if I find some of Hofstaetder's beliefs a little questionable. I'm a sucker for mind-broadening literature, even if I think the author is a complete lunatic 
Fiction-wise, I found a nice hardcover copy of Dune for $7 the other day. I'd intended to read Dune for quite a while, and a cheap hardcover book is just irresistable to me, so I bought it (I also had some plane flights in my future, which are always best spent with a good book.) Anyways, I just finished it the other night, and basically went out and ordered the rest of the canonical Frank Herbert Dune books (all used, and paperback, since I'm a cheap bastidge). All told I managed to get the entire set of 6 for about $22 out of pocket.
I also just picked up a copy of Zen and the Art of Motorcycle Maintenance on Sneftel's recommendation. I've heard about it previously and it sounds like the kind of stuff I'd enjoy.
It's all rather slightly expensive after a while, and I have a dangerous habit of getting a lot of books and reading them all 80% and never finishing, so this is a bit of a risk; but in any case it's great to be able to do some Real Life again.
Anyways... I'd best cut this off before I end up making one of my usual epic monolithic blobs of a post that nobody has the stamina to read
(Ooops, too late.)
| |
| Saturday, February 4, 2006 |
| Day Three | |
Posted - 2/4/2006 4:46:45 AM | Well, day three was supposed to be Friday. Friday morning I woke up sometime around 10 AM feeling utterly horrid, and promptly went back to sleep. I seem to be fighting some typical winter-type bug; nothing serious, but definitely a pain. It's amazing how a low fever and a little achiness can get in the way of sitting in a chair and typing all day.
Anyways, I mostly slept and read today. I've done a little brief thinking about developing a more robust mission framework for the next X project, but mostly I haven't had the energy.
The sleep thing seems to go nicely with being sick, though; I've been up since about 12:15 AM. I might taper off and get some more rest here soon, but so far I feel a lot more energized and alert than I used to on a fixed schedule - and that on top of fighting a mild illness. Definitely hopeful for the future.
Crystal Lite sure starts tasting foul when it's all you've had to drink for the past 20 hours.
| |
| Thursday, February 2, 2006 |
| Day Two | |
Posted - 2/2/2006 7:09:40 PM | So Day Two is coming and going. I slept in until about 1PM today, which frankly I don't really care about, because I know I'll work late to compensate for it tonight - and in my new work environment, nobody else minds, either.
It's a bit hard to stay disciplined and actually work, when nobody is holding the Axe of Firing above your head all day, but so far so good. I haven't yet succumbed to the temptation to play games at random times, but it's starting to occur to me that why the heck not? so maybe tomorrow I'll do some of that. For the first time in ages I've felt motivated to clean and organize my flat, which is utterly amazing, especially since I've felt that way for three days straight now. I think this schedule freedom thing is going to be very, very good for me.
I've gotten my build environment fully up to date and can now build working debug packages of X3 on demand, which means I'm in prime position to start code work. My big job of the day was to go through my backlog of personal emails and bug reports and put together a tasklist. I'm waiting on word from my lead on what my priorities will be for the near future. I'm hoping to get to work on improving our interal task coordination and bug tracking processes; I'd like to build a whole new system (the ones we have work fine, but are suboptimal).
Anyways, I'm waiting on word back on what I should be focusing on. In the meantime, I'm collecting some thoughts and concepts on all the various stuff that I might get assigned to, just so I'm prepared to dive right in as soon as I get my priority chart back. This month is something of a probationary period for me (my final payscale and job title will be determined by my performance this month) so I'm really itching for a chance to prove myself properly. Nobody has any doubt that I can get the job done; really we're just experimenting to find out what I'll be able to do with no other demands on my time (i.e. without an Evil Day Job). I honestly have no idea how I'll end up, so this is kind of an exploratory procedure for everyone concerned.
Getting back to the subject of sleep, I've decided I'm definitely going to say the hell with rigid sleep cycles. I'd done some looking at biphasic and even polyphasic sleep schedules, but it seems to me that the medical realities behind such schedules really aren't well understood enough yet. For instance, there seems to be some debate as to whether or not polyphasic cycles are actually healthy/possible. I've got total freedom to try anything I want, but frankly polyphase cycles seem to be even more unforgiving than a traditional monophase sleep-when-it's-dark schedule. Even worse, there seems to be doubt as to whether or not polyphase schedules allow you to recover from physical stress (i.e. hard exercise) properly. Since I'm wanting to give my Parkour interests a strong shove with this new schedule freedom I have, it would be pretty stupid to adopt a sleep cycle that doesn't let my body recover properly.
However, by direct contrast, it seems like everyone has good things to say about free-running sleep phases. I'm a firm believer that any medical "science" that tries to make strict generalizations about the good of every single human being is most likely full of crap; everyone is different. As a corollary, everyone is going to react to differing sleep patterns and cycles differently. The idea of free-running sleep is that you never actually force yourself to wake up or go to sleep; you sleep when tired, and wake when rested. Seems pretty darn good to me.
In fact, the only objection I've seen to adopting free-running sleep patterns (so far) is that it's virtually impossible to reconcile the habit with societal patterns. That's perfectly fine with me, frankly; I have no obligation to be in some building between some arbitrary hours of the day; I have no particular aversion to being asleep or awake at times people find "weird"; and in the modern world of 24-hour supermarkets, I don't have to worry about dying of hunger. Seems like this is definitely the way to go.
As a matter of fact, I've basically decided to go for it. I slept in a lot this morning, so I'll probably be up until 3 or 4 AM working/goofing off anyways. Seems like a fine time to start adopting a free-running cycle. I'm already very well adapted to living on weird sleep cycles (as evidenced by my previous journal blatherings, and the fact that I lived through the Crunch Mode period) so I'm thinking that I'll probably be fine. Every now and then I'll probably have to stretch my sleep schedule to fit someone else's convenience (meetings come to mind) but that's not a problem at all. Worst case I can just go back to sleep afterwards
Really the only genuine problem I can see is that it may be hard to resist the temptation to oversleep a lot. I'll have to develop some strict discipline in getting out of bed as soon as I wake up feeling refreshed, because I currently have a bad habit of just snoozing for another 3-4 hours and eventually getting up feeling like crap. I don't see that as a particularly insurmountable obstacle, though; just a little challenge.
My hope is that, over time, a free-running cycle will tend to keep me awake as much as needed. The idea is that I'll only be sleeping when I genuinely need rest, so I should always be near-optimum in my sleepness/awakeness ratio. I really can't see any physical health risks, either, since the whole idea is to be attentive to my body's needs. There might be some psychological stresses involved, but my mind's so screwed up, there's no way that'll cause any permanent issues
So, as usual, I came here with about three sentences worth of stuff to say, and ended up spouting for far too long. Maybe, with all this extra time, I'll figure out the magical art of concise communication.
Or maybe I'll just keep reading Dune.
| |
| Why 9-to-5 Jobs Suck | |
Posted - 2/2/2006 1:07:37 AM | I made a mention in a comment on my last entry that I've been thinking about doing a nice rant on why typical, American Dream, 9-to-5 jobs are the evil spawn of Satan. Actually, I'm really only going to rant about why my particular 9-to-5 was so terrible, but there should be plenty of ranting material there.
So, labouring under the foolish notion that someone will have the patience to sit through me griping for thirty pages, here goes nothing.
Some Background
Before The Job, I was basically a freelance contractor; I'd line up work, do the job, get a fat paycheck, say goodbye to the client, and with luck never talk to them again. If I did talk to them again, I could count on getting paid again, thanks to some nice maintenance clauses in my contracts. It worked pretty good. I could work from home, do my own thing, live some life in between all the code and such.
Now, that works fine when you're a self-taught high-school dropout. Problem is, being a self-taught high-school dropout doesn't impress many people. (It's fun to say, though.) Legally, I have no education. Sure, I went to a wide array of schools, but most of them were international and only marginally legal, let alone accredited and widely recognized as valid institutions of learning. That's the price to pay for growing up in another country, I suppose. Anyways, the bottom line is that I've got no diploma, no G.E.D., nothing - just a handful of credits from a community college and a fat portfolio of Real Projects.
When you're a contractor, you can get away with that. Real Projects impress Real People, and when Real People see that you've had Real Success on something that looks an awful lot like what they want you to do, they (usually) will trust that you can do it. So being "unedumacationaged" isn't a terrible handicap. It does tend to limit one's ability to work for Fortune 500 clients, but I don't like working with the suit types anyways. I spent awhile convinced that I could make a successful career of this, continue taking some classes, and eventually everything would work out great.
Somehow, and I honestly don't remember entirely how, I decided that wasn't going to cut it. I wanted some Real Jobs to pad my resume, something with heft and weight. Maybe it was the allure of the suits and their dollars, I'm not sure. Whatever it was, I abandoned my last scraps of rationality and took a decent job offer at The Client. The Client was someone I'd worked with before, on two separate projects, and one maintenance update of one project. I have some loose family ties (of the in-law nature) to some of the Big Names there at The Client, who'd given me the contract to begin with (us experience-free high-school dropouts are more than happy to take that kind of contract). We'd both been fairly happy with things, so I got an offer of a permanent position. I should have known that the in-law ties were a bad sign, but I was young, foolish, and needed the money. (That sounds like a really lame textbook excuse for getting roped into a life of prostitution... hmmm...)
Anyways, I should have known there was going to be trouble. I'd always had a sort of rough relationship with my related contact at The Client. The company itself was a startup and still fairly small. Money was tight. The office space was a small, cramped suite, shared with another software startup. The salary was going to be well under market rate. But hey, what the heck, right? I was going to have some stability, some certainty, some concrete under my feet to take away that awful feeling of never knowing when your next contract might come.
So I took the job.
The Excrement Intersects the Fan
In August of 2004, I moved to the Atlanta, Georgia area to start the job. The apartment I have is about an 8 minute drive on average from The Office, which is probably a good thing, because in the coming 16 months I definitely would have killed someone if I had been forced to deal with a long commute on top of everything else.
Things started out fine. Better than fine. I had stability, a steady paycheck, and to make it all even better, I was living my dream. In the evenings, I'd go home and moonlight at Egosoft, working on a space game. Things looked pretty much darned perfect.
Something vaguely rankled, though. I can remember as early as spring of 2005 thinking that I was ready to get out. I was doing shrinkwrap software, and a little bit of internal systems work, so there was always a new challenge or area of interest to keep things fresh - so it wasn't like I was bored... right? Despite the apparent continual interest, I quickly found myself totally unmotivated. The problems I had to solve were either boring or trivial. I didn't care about the product I was working on. I didn't care about the company, aside from the fact that letting the company tank meant I had no paycheck. Inevitably, I quit working because I liked programming, and started working merely because I felt like I had to.
It seems pretty obvious, looking back on it, what all was going on. At the time, though, I had no idea. I figured it was just a weird adjustment, that maybe I wasn't used to having a rigorous, tight schedule, and that I'd get acclimated and build up endurance over time. Maybe the Egosoft night job was a bit much, too. I started to cut back on it a bit to try and control my stress load.
Counting Up to the Last Straw
Over the summer, I started working on other projects: an embedded network appliance (nothing interesting - dead boring, in fact, aside from a little bit of fun pattern recognition logic built into a hacked Linux kernel), and a Mac platform port of our main shrinkwrap software. On both projects, I was cutting new ground; nobody else in the tiny company had any experience on the platforms, or coding, so it was all up to me. Neither product was remotely stimulating, so again I returned to work every morning just because I felt obligated.
One morning, I layed on the couch (where I'd taken to sleeping), and simply wondered what would happen if I didn't go in to work. So I called in sick. I spent a fitful day laying around, trying to figure out why I felt so horrible. I was eating at least vaguely healthy food, getting a token amount of exercise, and sleeping plenty. Had to be work.
Over time, release on X3 drew close, so I started putting in extra hours on the project at night again. Things started to get really feverish, up until Crunch Time in the fall of 2005. I found myself working 80 hour weeks as a matter of course, stumbling in to work and zombie-coding my way through each milestone, then coming home and doing game work. I found that I really liked the night work, even though I was tired, frustrated, and overtaxed. Something about it was just right.
That made me even more confused. How could all that be right? At work, I was making deadlines, plowing through milestones, getting a lot done. None of it was giving me trouble - everything was fairly easy to finish. Mostly stuff was just time-consuming. At Egosoft, by contrast, it was chaos. The deadline slipped a couple of times, and we fought for every last waking man-hour we could wring from the development and testing teams. The Great Feature Axe amputated a painful amount of content and code from the game. We all pushed one final sprint. My weeks stretched to 100, 105, 110 hours. I ran marathon weekends of coding for two days straight. Testing, debugging, everything was a jumbled nightmare. Without the coordination and direction of being physically with the rest of my team, I spent a lot of time fighting uphill against the rapid-fire changes that come with the final few weeks of coding on a tight-deadline game project.
By all indications, Egosoft was a bad work environment - we were behind schedule, cutting features like mad, cutting corners, wincing as we lined up content for patches that would have to be released post-gold. Finally, the final, unmovable deadlines came, and we hit code freeze. One last dose of testing, and then we shipped X3.
In the next few weeks, I did a lot of deep thinking. From a "professional" management standpoint, the Egosoft project had been risky business. Some of the more conservative managers out there would probably have called it a disaster. Certainly if we'd been looking at annual performance reviews any time after the close of the X3 project, we could have fully expected to get fired from any large company. And yet, despite all of this, the project was a phenomenal success of management and leadership. Our team lead was brilliant, and pulled us all into a solid win. Despite our fears, and some rough edges, X3 has been a successful and impactful game in its genre. As a suit-led business, we were a wreck; as a game development company, we were golden. Frankly, most small, niche-game teams can only dream of the kind of success we've been fortunate enough to enjoy at Egosoft.
Where's the Beef?
This was more than a little confusing. The Day Job was going good, on paper, but I hated it. Egosoft had been a heck of a roller-coaster, and I loved it. Was it just a youthful, naive, adrenaline-junkie urge to work on the edge of danger in a talented and wildly driven team? Was it just that I deeply enjoyed the challenge of the Egosoft job, and found it more fulfilling? Or was there more than that?
As it turns out, there was a lot more than just that. Those things are all true, I think, and all made up important parts of my decision to leave the Day Job. But more than anything else, I left because 9-to-5 jobs suck.
Why 9-to-5 Jobs Suck: Or, How to Make Your Software Company a Personal Hell for Your Programmers
I started looking around for articles and writings on software companies, and programmers. Specifically, I looked around for stuff on why it was I hated my job so much. My good friend and flatmate visited at work one day and was totally perplexed as to why I left drained, annoyed, irritable, and exhausted every day. It was time for some Answers. Sure, Egosoft was a more attractive job, but what exactly made the Day Job so darn crappy?
- You're a Cog in the Machine
Pink Floyd said it best: you're just another brick in the wall. More than anything else, this was the fact that bugged the ever-loving heck out of me. I was there to make money for The Man, and The Man had absolutely no reservations about reminding me of that fact at every available opportunity. I think that this attitude is, at the core, the big cause behind most of the other reasons why the job sucked.
- You Are Not Worthy of Being Offended
Part of this was the personality of the management, but I think it was also a "rank" issue. As a menial slave, I had no entitlement to my own feelings. If The Boss made a terrifically offensive joke at my expense, I was obligated to laugh and not respond. If I sniped back in kind, I was out of line. The severity of this kind of interplay varied quite a bit, and by no means was it a common thing, but there was, on a daily basis, some kind of indicator that I was a gear in the box. I didn't have the right to be pissed off that I was being treated like a galley slave. God forbid I say anything about it.
- Do What I Mean
My bosses (both of them, at the small company) shared a common and extremely annoying management style: Do What I Mean. Virtually every time I got a task, I'd be given a short blurb-like sentence or four on what I was supposed to do, and then be told to go do it. At first, I interpreted this as autonomy, or empowerment, or whatever stupid work managers like to use. Turns out I was wrong.
I'd finish a task, carefully consider any questions I had, answer them to the best of my knowledge, and hand in the results. If I had any really big questions I'd ask before I committed to a course of action, presenting the alternatives, and suggesting what I felt was the best choice based on my analysis of the technical situation. In response, I'd often get told just to "finish it and we'll see how it looks," or something similar and equally annoying. Inevitably, I'd finish a task, and there would be a long line of reasons why it was "wrong." Usually, "fixing" most of those things meant heavy reworking of what I'd done.
I tried asking for detailed specifications so I could avoid having to tear apart and redo my own work three times until the brass was happy with it. This was met with flat refusal; the brass didn't have time to do specs. It was my job to make it wrong once, then change it until they liked it. Tweaking and three-pixel-changes were one thing; but more often than not some pretty major aspects of a system would be affected by all of the changes. It'd driven me nuts while on contract, and it was no better as a day job.
Maybe it would have been bearable if every time I had to make a change it was getting the thing closer to some final goal - but it wasn't. Usually, every iteration of changes would be because some fundamental aspect of the system was being reconsidered. Management would make a five second decision, off the cuff, without thinking about any consequences. I couldn't argue, because that wasn't my place. All I could do was go back and throw away hours (or even days) worth of work, based on careful analysis of the situation and lots of deep thought. My professional and informed planning would, in many cases, be thrown away in favor of a snap decision from someone who'd barely even considered the problem.
Eventually, I quit seeking approval. I started doing things because I knew they were the right thing to do: a heavy code-base refactoring that, on paper, cost me a week and a half, but in reality saved the project literal months; a port of some internal logic from a badly written ASP monster to a well-factored PHP system; a rearrangement and rewording of some critical and very confusing interface elements; some subtle organization changes in the UI. In every case, I'd just do the Right Thing, then politely and firmly inform the brass that I'd done the Right Thing, and they were going to live with it. Shockingly, they inevitably ended up liking the Right Thing - but there's no way I would have been allowed to do it if I asked first. Fighting against authority like that, even when I know I'm doing what needs to be done, doesn't exactly give me warm fuzzy feelings.
- You're Not Typing! Quit Slacking Off!
Apparently, programmers are not productive if they are not typing constantly between 9 AM and 5 PM. I had a few "negative" comments on performance reviews and in private meetings about "all of the web surfing you do." I was, a few times, publicly mocked for "falling asleep instead of working."
In reality, I'd do a lot of surfing, sure. Usually, it was to MSDN or similar reference sites to brush up on some API or to double-check an assumption about something. Even my "recreational surfing" was simply to clear my mind, to reset the stack, to get the juices flowing. In my working style, I sprint - lots of thinking/code, some testing to make sure it works, then relax and reset until ready to take on the next chunk. It works great for me, and as I started to find out from my reading of articles and blogs, a lot of "thought workers" use similar patterns.
As far as management was concerned, though, I was lazy. It made no difference that I was getting things done ahead of schedule on average; the brass thought they could get even more out of me if I'd just quit all that darn goldbricking all day. I actually started feeling guilty about my work pattern at one point, which thankfully I later realized is just plain stupid. As usual, attempts to talk through this fell on deaf ears. "Yeah, sure, we understand that's how you work. Just stop doing it."
- Here, Do This Other Job, Too
The shrinkwrap product we worked on required a fair bit of customer support. Due to the small nature of the company, we had only one support worker. This meant that, in addition to being solely responsible for all of the code work done at the company, I'd regularly get pressed into service as technical support, too.
Honestly, I'm thankful for it on the whole, but my parents did something to me that I absolutely resented during that job: they instilled in me a powerful desire to do a job right. So, when I got stuck with phone duty, I couldn't let myself suck at it. Being the programmer of the software, I was uniquely positioned to know a lot more about how to diagnose weird problems than the front-line staff guy was, despite his superb handling of the product in general. And, being a cog in the machine, it wasn't beneath me to talk to mere customers. Of course, that kind of customer interaction was far below the station of Management, who never dreamed of answering the phones or handling emails - they had more important stuff to do!
That wouldn't have bugged me too much if things had been slightly different. At Egosoft, we're also a small team. There, when one part of the team is unavailable, needs vacation, maternity leave, lunch break, whatever, we can step in to pick up the slack. I understand that small teams need that kind of support and flexibility. The thing is, at Egosoft we do it because we care about each other, and like getting the work done right. At the Day Job, I did it because it was pick up the slack or get fired. That makes a huge difference.
The worst part was that, in addition to being expected to do other people's jobs on a regular basis, I was still expected to do superhuman things on my main job. Schedules became increasingly short and utterly ridiculous. In the last project I worked on, the schedule was literally invented in less than five minutes my management; I wasn't even asked if it was reasonable. When I started to object, I was told that "yeah, we know it's an aggressive timeline, but we'll just have to buckle down and get it done." Apparently, management was incapable of realizing that there was no pressure at all on the next release, and that the schedule could have been ten times longer and not hurt a darn thing.
As it was, the schedule ended up slipping beyond all control to nearly three times the original allotment - and still about 75% of what I would have liked to allocate myself. Several features got axed to make it fit in that amount of time. It was finished as soon as it was because, by then, I'd already made clear my intentions to get out of that company as soon as possible. The problem was, the slippage was universally agreed to be my fault, because I wasn't working hard enough on getting the project done.
- No, You Can't Have an Office
Cubicles are the most disgusting thing that any human being has ever been forced to endure. They are degrading, offensive, and belie a pervasive attitude that the common worker is not worthy of much more than a 5x5 square of carpet with some cheap prefab "walls."
I had to buy my own mouse to replace the horribly inaccurate Dell ball-mouse that afflicted my workstation. It was a miracle that I even got a new workstation to replace the second-hand scrap heap I started out with. Requests for monitors that wouldn't give me eyestrain headaches on a daily basis were flatly ignored, if not outright mocked, while management upgraded themselves to dual LCD setups that they rarely used. Books and training materials were right out. To hell with you, you don't need Visual Studio 2003. VS6 compiles C++ just fine as far as any of us can tell, so take your C++98 standard and shove it. VS2003 costs money that you don't have in your budget. You can set up a source control server as long as you run it on your (highly underpowered) machine and don't use up network resources for it. [Needless to say, I gave up trying to get them to adopt source code control.]
Office space, clearly, was not going to be granted to me, period. Forget the fact that I was cooped up with several people constantly on phone calls, and that across the low cubicle wall was another software startup that engaged in frequent and very loud arguments. I'm frankly shocked I could do anything productive there at all. It was a nightmare for concentration. I took to occasionally napping in my cube and working late just so I could get a couple of hours of actual quiet.
With no way to clearly indicate to people that I needed some privacy to get my work done, I had to resort to being very short and terse, usually at the risk of alienating people that I liked (i.e. the phone support guy). Eventually, people learned to just piss off and send me an email when I was hunched over looking thoughtful, but it took some very regrettable outbursts to convey that point; calmly explaining that "now is not a good time, I need to solve X" never made any headway. You're a cog in the machine, dammit! My inane questions are more urgent than your thoughts, no matter what you're doing!
- You Will Be Here At 9AM, and You Will Not Even Think About Setting Foot Outside This Building Until At Least 5PM
Mandatory schedules are second only to cubicles in being utterly despicable inventions. Being expected to be at work, and typing in my IDE, on a rigid schedule, is just stupid. I only once succeeded in getting a day to work from home, and was told never to try for such a thing again, despite the fact that I got nearly a week's worth of work done in that one day.
Every day is different. Some days I'm ready to work first thing in the morning. Some days I need a few hours to warm up and ease into things. Some days I just plain need to not think about work. Some days I can hop out to Wendy's and grab a burger and be back at my desk in 30 minutes, ready to keep solving a problem. Other days, I'd prefer a solid three or four hours to just clear my mind and relax, think about other stuff for a while. Do some light gaming. The 9-to-5 world (at least, the part of it I was punished with) does not tolerate such heretical notions. You will be here and typing at 9AM, you will continue to do so until no sooner than 5PM, and you will darn well show back up precisely one hour after leaving for lunch.
Never mind the fact that management routinely kept loose schedules, took two or three hour lunch breaks, and worked on personal or external projects constantly. The Cogs in the Machine do not deserve such privileges. You will devote your every waking hour to making money for The Man, and you will like it.
Screw Everything!
After a while of this kind of crap, I found myself depressed. Not clinically, slit-my-wrists, take Prozac depressed, but pretty bummed out about life in general. Despite what my mother will try to tell you, I like things fairly clean and orderly (in my own weird "order"). During the job, I found myself not caring about that at all. My personal life, my flat, my work all started to decay under the weight of simple complacence.
I quit eating properly, gave up exercise, took to long hours of staring blankly into space instead of sleeping. Some of it was due to heavily limited time during the X3 crunch, but the laziness and lack of motivation continued well after release. I let myself slide in ways that I never would have imagined I could let myself go. Stuff got outright bad for a while in my personal life.
Eventually, the light turned on, and I figured out that I hated my job. I didn't just dislike it, or have frustrations, or have some niggling little peeve at work. I hated that job.
Moving On
Even during the sleep-deprived panic of working on a game in Crunch Mode as well as a day job, it was pretty clear to me that I liked the Egosoft job. For a while, I wondered if I wasn't just grasping at the greener grass on the other side of the fence. Soon enough, though, I realized that it was more than that.
At Egosoft, I'm finally with a good team, and I've got a great boss. After X3, I sent him a private postmortem outlining some concerns I had with the development processes and made some suggestions for improvement (some of which I've mentioned here before). At my day job, I would have expected (quite literally) to be fired over such insubordinate arrogance. For a while, I had a contingency plan of what I would do if I got fired from Egosoft for writing that document.
As it turned out, my document was welcomed; the problems were things that the team lead had seen and was interested in solving. We've even discussed some things (and plan to continue to do so) that help me see why certain decisions have been made. At the day job, when a decision is made by Management, you will darn well do it and not ask questions. At Egosoft, if there's a problem with a decision, you make your case, and everyone concerned gets together to find a better alternative.
Everyone on this team is a "thought worker." We do business and earn our living on abstract, digital concepts and products. There's a lot of real-world stuff that goes on (like producing and selling game units) but the essence of what we do is all very similar. Everyone understands wierd work habits and patterns; we all have our own quirks. Everyone is given everything they need to get their job done, as far as is practically possible. This team works together, on a shared goal, for a shared purpose, on a project we all care about doing - and doing well.
I've finally freed myself fully from the evils of contracting (never knowing where the next job will come from), and I'm now free of the evils of day jobs (being coerced into existing on someone else's agenda). I now have total freedom to live, clean my flat, go shopping, take a four hour lunch break, and/or sleep all day, provided the work gets done. I'm now working because the people I work with know I'm competent, know I know my stuff, trust me to do what I'm on this team to do. I value and appreciate the skills and input of everyone else on my team, and they reciprocate to me. Even those who are, formally, "In Charge" do not demand to be treated as if they are infallible or above reproach. We're not here to buy a Benz for The Man; we're here to all reinforce each other, and to contribute to a whole that is greater than the sum of any of us individual parts.
This team isn't just a bunch of people who happen to spend their day in the same building and get paychecks with the same letterhead. This is a team. And it feels damned good to be a part of it.
| |
| Wednesday, February 1, 2006 |
| Day One | |
Posted - 2/1/2006 1:49:00 PM | Well, I am now officially a full-time industry professional. Today is my first day of work at Egosoft working on the X game series. Those of you who have been here before (and are masochistic enough to come back) know that I've already been working with Egosoft for over three years now, beginning as a volunteer, and then working part-time around my Evil Day Job.
Today I've started in exclusively at Egosoft, working from home over the Internet to the main company office in Germany. It's actually pretty much exactly like my part-time work, except there's more of it, and the paycheck is bigger. Time will tell whether or not I continue to enjoy the job when it's what I do all day
So far all I've really done is work on getting my build environment back in sync. I was basically "out of office" for the last two months while finishing up stuff at The Evil Day Job, so I had quite a bit of updating to do in terms of code repository synchronization and tools adjustment.
At this phase we're working primarily on updates and demos for X3. This is a relatively low-strain project (compared to the pre-gold-master rush) so there's been a lot of time to update the various tools and utilities we use for working on the games. We're in the late stages of arranging the next main project, so some preparatory work is being done for that as well. It's looking like we will be doing a content expansion for X3, with a heavy emphasis on missions, quests, and such - which just so happens to be one of my areas of responsibility.
One of the other big areas that I'm going to be involved in is project coordination. The main office has a great set of design plans, documents, bug/task tracking setups, and all the trimmings of good software creation. The problem is, part of our development team (including me) and all of our testing team is spread out across the world, and these resources are not really nicely connected to the Internet. So we'll be looking at a major internal overhaul of some of the development and testing processes. The main goal here is to help get design documentation and work coordination into a more usable and accessible format, so that we can spend less time trying to figure out whether or not Foo is really a bug, and more time actually getting work done.
My next task is to install the game and get a working test environment on my development workstation. During the engine work on X3, the engine only supported Shader Model 2.0 capable cards, which meant I had to run the game on my testing/gaming rig instead of my workstation. This translates to copying built binaries over to another machine and physically walking over to my couch to run the game itself.
The engine now supports SM1.3, which means my development box's Ti4800 can run the game (weakly). So for post-release work, I'll be doing most of my code testing on this machine, and reserve the other box for hardcore final playtesting. That should speed up things quite a bit, and let me get nice and fat since I can sit in the same chair all day instead of walking back and forth every time I recompile the code.
So there you have it. Enough drivel... time to get back to work
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | | | | 3 | | 5 | 6 | | 8 | | 10 | 11 | 12 | | 14 | | | 17 | 18 | 19 | | 21 | 22 | 23 | | 25 | | 27 | 28 | | | | |
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
|
