The Disturbance in the Force was...

For those of you who I've not told in person what's going on yet... there was a huge disturbance in the force on July 11th for me. A shift sideways, if you will.

The planet Alderaan. This is obviously an "after" pic.

I left Surreal Software.

That's a big huge enormous step for me... I'd been there for 3 and a half years, and because of that have worked with some of the most amazing people I've ever worked with. And I mean ever. These guys were awesome - almost like family. They honestly care about the people who work for them, and even though the company is getting quite large these days (its doubled in size since I started there), everyone there is a rockstar. That's rare.

Before you start wondering... no, I didn't leave because of the project I was working on, or problems with co-workers or anything else you might be imagining which is untoward. In fact, I'd have loved to have stayed and seen This Is Vegas all the way through to completion, because it's one of those projects which has the potential to just completely rock the gaming world. I've got faith that those guys will come out with an excellent game.

This Is Vegas: It's like someone took GTA 4 and gave it several large dirty martinis and a backstage pass to a Frank Sinatra concert

Nah, I left because working with your fiancee blows goats for both you and your fiancee. It removes that safety valve that everyone needs to vent about what's going on at work, because if you work together, often times you'll both be venting about the same thing - and from two different sides. Not good. That, and absence (even for a few hours each day) makes the heart grow fonder.

So where did I end up going? (And please, if your name is Andrew K, Pete I or Sean Ph, forgive me - I'm totally slammed right now, and this whole thing has been a bit of a roller-coaster. Emails are about to fly your way explaining what's going on).

The New Hotness...

XRK: You only think you've not heard of us because you've not been paying enough attention... yet

I've just started a new gig with the incredibly talented bunch X-Ray Kid Studios. Did you heard of Google Lively which hit beta about 3 weeks ago? Well, notice all that art and animation goodness? That's us.

I've come on board as Director of Engineering, which is a position I've been itching to sink my teeth into for a few years now.

We're working on our own IP right now. I can't tell you any more details, just please, rest assured that I've never seen a group of people so... well... synchronized. Everyone is on the same page as to what we want to create, and that's making the early stages mindblowingly smooth.

(BTW: I will be looking for at least 3 senior guys to join me on the team in the areas of general engine/tools tech, graphics and gameplay, and probably 2 or 3 mid to junior ones before the end of the year... although the details right now aren't fully figured out. If you know anyone in the games industry who's looking, let me know).

My Job So Far...

So far, over the past two weeks, I've been down to our Newport Beach offices in Orange County, California, and met the rest of the team in person. (All of whom are great... I spent a good part of my first week in complete and total utter fanboyish shell shock regarding the caliber and credentials some of the people I work with).

We get our offices up in Seattle on August 1st (X-Ray Kid North is the Video Game hub; X-Ray Kid South is the 2D/Animation/Cartoon/Comic Book/TV/Movie hub). The offices are right across the street from Surreal Software which is great (and means that I can still carpool to work), and literally right across the corridor from FXville - a group of mostly ex-Surreal Video Game FX and Character artists, whom I consider to be the absolute best in the business. (And if this all sounds rather incestuous and sparks your conspiracy theory neurons... that office complex is probably the best creative space for the price available right now).

I went to Gamefest 2008 last week and met up with some old friends, and made some new ones, did some networking, attended a number of talks, and discovered that - weirdly - about 75% of the attendees this year appeared to be Microsoft employees.

O Rly?

Meanwhile, the rest of my co-workers ended up at the San Diego Comicon. Unlike most people who go to the Comicon, they're the kind of people who actually go there and sign autographs and stuff, instead of lining up to get them. (Going to Comicon as superstars vs. listening to talks about how to compress data for streaming on the XBOX 360 at the exceptionally nerdy Gamefest 2008? I think they got the better end of the deal).

The embarassing thing tho? Last comic books I read was ... ok, well, strictly it was Absolute Watchmen. But before that? Er... that'd be my friend Aron Dittbrenner's one that he was working on. OK, so, anything commercial that anyone else would have read or heard of? Ummmm.. yeah... that'd be the Spiderman/Venom arc way back when. Like, 1985 or so. Before that, I did read my Uncle's entire Marvel comicbook collection which comprised of nearly everything Marvel published from about 1968 to about 1978. That was, I read it before my cousins decided they were coloring books and my aunt unfortunately didn't disavow them of this knowledge. God knows how much those would be worth today.

Which means that ... um... it's quite embarrassing to realize that nearly everyone I work with is a comic-book legend to those who follow them.

Jeff Matsuda gets his Batman on

Best thing about this job so far? Everyone's huge on collaboration, so I get to dabble with my more creative side instead of just pushing da onez and zeroez.

This week, I'm back down in the Irvine area, meeting up with potential Engine partners for a console game. *cracks knuckles* Time to get stuck in! (Although getting up at 4am for a flight... meh... goes with the territory).

Big leagues. Small massively agile company. This is going to be fun.

I'm planning on interviewing the guys I work with for either my blog or the X-Ray Kid website soon, so you can get a taste of what we're all about (the usual disclaimer: if I have time). More news as it happens. Keep 'em peeled.

How to Build Team Morale and Cohesion by Goofing Off

The Surreal Gameplay Programming Team's Friday Meeting, July 2006. From Left to Right; John Cuyle, Lance Dyson, Matt Lauritzen, Joe "The Robot" Sola. Sola's Mom could not be reached for comment.

So just how do you get a team together, keep them working together, keep tensions low during high-crunch periods of time, and just generally make sure they rock the house?

I've got a secret little trick that I figured out while I was managing the Gameplay Programming team at Surreal. (Actually, I discovered some of this while managing the Tools Team, but I refined and codified it when I moved to Gameplay).

We moved to an Agile project management method (kind of based on Scrum) at Surreal in October 2005. Now, people have varying thoughts as to whether or not it was successful or not - but that's for another post - but the upshot of it was that we ended up having two Gameplay team stand-up meetings a week.

One of the things I did early on after moving to the Gameplay team - given that we had two meetings a week - was to look at exactly what those meetings were doing for the team. It ends up that really, the meetings had several purposes:

1. To update the status of the team for Production, which we were already tracking in another way anyway.
   
2. To update the team and keep them apprised of what each other were doing. Kind of a forced exchange of information.
   
3. To provide an opportunity for people to exchange information and ideas.
   

Now, 1) we were already doing via email, and 2) was good, but kind of out of scope for a 15 minute stand-up meeting (it'd expand the meeting for one). 3) seemed like a great thing to me, but needed more flexibility.

By this point I was already doing 1 on 1's with each team member, once a week; these were working well, and mainly I was using them to allow for private conversation about things that were bugging each team member, and to resolve inter-personnel issues, find out what was blocking them and so on.

And of course, Summer hit. And we were in crunch. Again. (We crunched all the way through the previous summer on Suffering: Ties That Bind... I was working 14 hours days on weekdays, and 8 hour days - sometimes longer - on weekends for three months).

Now, Summer in Seattle is a gorgeous time. After spending all winter under oppressive gray skies, everything flips and Seattle becomes one of the most gorgeous places on the planet.

I'd be damned if I was going to miss it again. So I decided to start a new practice.

Summer at Golden Gardens in Seattle - Seriously, it's what makes the rain worthwhile.

The Friday Gameplay Team Meeting

The Friday Gameplay Team Meeting was something I instituted at Surreal, and it works great for keeping your team together, focused and happy. It's now an institution at Surreal - even though I've not managed that team for over a year, which shows some of its staying power.

Instead of two Scrum meetings a week, I cut it down to one formal meeting, and one informal meeting (where I'd take notes if necessary; later we modified this so that notes weren't necessary at these meetings - I'll cover that later). The informal meeting was at 2pm on Friday afternoon, downstairs on the grass field outside the building. (The grass field no longer exists; which is ok, because we're no longer at that building). People were encouraged to bring beer (Friday at Surreal is Beer & Pizza friday). The meeting itself? 30 to 60 minutes long.

Over time, the meetings evolved to include a short soccer kickaround during the summer and early fall. These stopped at the new building because there's no field nearby, so we just meet out on the deck which overlooks the Puget Sound. The beer's still there though.

People swap notes and kick around ideas (and, I guess, soccer balls). They talk about the movies they're going to see, what's cool on TV, cool games they're playing (including ours), maybe a bit of what they're working on, and life in general. There's lots of joking around, a little bit of teasing, and usually very animated conversation. Some people (with nasty bad habits... er... like me) smoke.

It all seems very much like just an organized excuse to goof off. That's because it is. But if you dig a little deeper and look under the hood, there's some very specific reasons why I do it this way.

The Inner Structure Of The Goof-Off Meeting

This isn't actually a Gameplay team meeting - but it's what one looks like in the new building (it's held right here on the deck, and usually there's that many people there. And the two people on the left (Darci Morales, Surreal Producer, back to the camera, Matt Lauritzen, Gameplay Programmer Extraordinaire, in shades) are usually there too. This photo is actually from the Surreal 2007 4th of July BBQ on the deck at work, where we got fantastic views of the fireworks show.

There are several key reasons for holding a meeting this way.

1. It Gets People Away From Their Coworkers

Games development is a pretty high stress environment, and I wanted to make sure that my team had a place that was safely away from potentially prying ears and eyes of their coworkers, so that they could feel comfortable discussing anything they wanted to - including the things that other people in the company are doing that are bugging them.

This is normally a 1 on 1 subject, but this also allows the whole team to voice what's derailing them - without fear of retribution. (And if you institute something like this, it's important that there will not be retribution. Handle the problem there and then by explaining the other side of the issue - as their manager you should understand the other side of the issue; if you don't, you're not doing your job - or by promising them that you'll look into it. Don't bear grudges. Don't throw blame. Don't be quick to judge. If people are bitching about something, there's something to it).

2. It Gives Them An Opportunity To Vent

Related to #1... unlike regular meetings, this meeting - and I told my team this going into it, and repeated it regularly - is meant to be a "stitch and bitch". And yes, they should. It's healthy. But keep it in check, and address misconceptions where you can.

For example, one issue that comes up regularly near the ends of projects is the fact that programmers don't like getting bugs filed against them for content issues. They hate having to help Designers fix content that (they feel) should have been set up correctly in the first place. The job of the lead in this situation is to remind them that hey - guess what - designers aren't programmers. Part of your job as a programmer on a game team is to help the designers get their job done - and occasionally, that means holding their hands. Because god knows, they get to deal with our bugs all the time ;-)

3. It's Not An Office Or A Conference Room

There's a mental gear shift that happens when you get a team out of the office. This is why Marketing & Sales guys get to have expensive off-site retreats in ski lodges all the time. Well, no one pays for the geeks to ever do that (or if they do it's rare, or reserved for upper management), so this is the closest thing you can do without having to explain it to the Finance guys.

When you're out of the office, you can let your guard down, and let politics go by the wayside a little. You can be more objective about your work, and you can be more creative because you're removed from the issue. The creativity part is a big one - it gets your team's juices flowing.

The moment the conversation turns to the game you're working on - and it will, because most of the team spends nearly every waking moment working on it or thinking about it; you just can't turn that kind of passion off - you're going to get a torrent of ideas that will blow you away.

Take a notepad with you - there's gold in there.

4. It's a Friday

Yep, you knew it was coming. Part of the idea of goofing off is to goof off. Just a little bit. It's Friday, people are already thinking about the weekend anyway. This just codifies it as something that's okay to do.

Why would you want people to goof off during work hours?

This is a team that's going to go through hell and back for you. They're going to put off doing their taxes, their laundry, and their utility bills because they're at work at 9pm on a Saturday night trying to get the game out for its next milestone. They need to work together as a cohesive unit. Everyone needs to know what everyone else is working one. You need to know who's stressed out the most, and who's got a low workload - and this is a way of letting that work auto-balance itself. People will and do offer to help each other out during these meetings. But they'll only do that if they trust, respect and are friends with each other. (You can of course force it yourself and shuffle the workload for them, and you should do that as well, but this way they all feel like they're all in it together).

Think of it like being in the military. You're the Sergeant of your platoon. They're your men. What does a platoon do during downtime? They hang out. They build camaraderie. They become friends, and turn into a close-knit, well oiled fighting machine. And that's all you can ask from a team - have that, and you've got the best team in the world.

But you're not in the military, so they're going to go home after work. So do it at work instead. And give them a place to relax while at work - seeing each other day in day out, it's something your team needs. It's therapeutic.

Equipment List

What do you need for a successful Friday Meeting like this?

• At the very least, the lead should have a notepad & pen for taking notes of issues that come up, and ideas the team generates.
• Beer (and nonalcoholic beverages)
• A Soccer Ball if you've got somewhere to play.
• Your Producer. Make sure your producer gets invited to these meetings - your producer is not the enemy, and as long as you've told them why the meeting is structured the way it is, they should see the benefits. It'll make them a part of the team as well.

Conclusion

The Friday Meeting (or Goof Off Meeting) is an excellent tool for building team morale and cohesion. It's also great for getting information on the team's status in a way that isn't formalized, allowing you to fix problems before they become real issues.

It's now a part of Surreal tradition (at least for the Gameplay team), and has been successful enough that when programmers move to other teams, it's one of the things they miss the most about the team. That's ok - we let them come along to the meeting as well if they have time. In my ideal world all of the teams would have one meeting a week that was like this - it really does help.

Next time I'll talk about team morale, and I'll explain how I try to show the team that I appreciate their efforts.

The Visible Progress of Broadly Scoped Tasks

I've just gotten to a good place at work today. Finally, a long project is approaching its conclusion. So I've been thinking about what I know about project management, and working from my experience on tasks like this (and watching others tackle them) I came to some conclusions about how this kind of process works.

What is a broad task? Or a narrow one?

A broad task is one that cannot be easily broken down into pieces to attack. That's not to say you can't try; it's just that there are large numbers of unknowns at the start of the process.

A narrow task is one that is easily defined, narrow in scope (ie. tackles a very specific, small problem), and that is reasonably accurate to estimate.

Examples of broad tasks include any kind of integration work, any kind of porting work from one platform to another, and any time you need to build a new framework.

Examples of narrow tasks are those that could be described as "small features". For example, adding the ability to drop down a color-picker and select a color in an editor would be a narrow task. Adding the ability to specify that a mesh uses 16-bit floating point values for vertex positions instead of 32-bit floating point values would also be a narrow task.

The Graph of Progress over Time

Here is a graph of what a broad task looks like to the engineer doing it, and to the outside world, in terms of progress made. It's slightly scary, but that's ok, we're going to go through it in detail.

We're focusing here on the experience of the engineer themselves (because it's important to understand what they're going through as they do the work in question), and the experience of their managers/investors... the management layer which has a strong interest in getting the task done, but might not care quite so in-depth about how it's achieved. Basically, the people with financial responsibility for the work. The ones who have to explain to investors what's going on - or indeed, the ones who have to go to investors and ask for more money for the project to continue on a regular basis.

Visible Progress

In the above diagram, the yellow body of the graph is the amount of visible progress. This is what everyone else sees - managers, executives, people on other teams - unless you're providing detailed status updates. And by detailed, I mean, showing what you did every single day. It's unfortunate, but perception really is king - you will hang or fly based on what other people can see you doing.

With broad tasks, it's crucial therefore to make sure people know what's going on - they won't understand if you're not making visible progress - all they have to measure you by is the visible progress alone.

Expected Activity

The red dashed line (the straight one, for those of you who are color-blind, and I apologise for my poor color scheme if you are) is the expected amount of progress. It's when this line doesn't match the visible progress that people get ... well... kind of nervous.

In a perfect world, this line is what your output would be. But people aren't machines. Even taking unforseen circumstances (life intruding on work, discovering that the task is a bottomless pit that no one understood until now) into account, no-one ever works like this. Let's ignore the ebb and flow of up and down days, and assume that this line is an average. Even so, the shiny happy engineer will not match this line (unless they're an engineer in the category I like to call Bulldozer). They're human, and there's a stimulus-response thing you have to take into account here.

Either way, for planning purposes (both because you can't really plan any other way, except by padding... and also because they're not the ones doing the work, so they're removed from the immediate situation), this is what management normally expect of their warm bodies.

Actual Activity

This is the green, curvy dashed line. And it's curvy. Boy it's curvy. And it's a little badly drawn (view it more of an emotional line; if I'd done it completely right, it would always slope at least imperceptibly upwards; at worst, it'd be horizontal).

This line is the actual productivity and progress of an engineer on a given broadly scoped task. Why is it shaped like that, you ask? Well, let's break it down.

The Lifecycle of a Broad Task from an Engineer's Perspective

Ramp Up

Any broad task can be pretty reasonably expected to be at least somewhat new to the engineer performing it. A certain amount of book-keeping and surveying has to be done before the engineer can even begin, because you need to figure out where to start, and where you're going.

This part of the curve is a gentle, shallow ramp (far left of the graph). It soon peaks, however, as the work gets going.

Fatigue

Next up is our first dip. Literally, at this point, fatigue sets in on the developer. They've been bashing their head against their desk trying to break the task down into bits and pieces they can manage. They've been working a while, and churning on the problem, but at this point their work provides little gratification. Their own perceived progress level is excessively low compared to the amount of work left on the task - and that worsens the problem, because now they're feeling like they're useless and they still have a huge task ahead of them.

Disheartened, they step off the gas pedal, until either someone steps in and prods them, or they get their own internal second wind. They're in the middle of a death march at this point, and they know it.

First Flush of Success
Hey, what do you know? That curve does turn back up (unless the engineer in question quits - which, if it's a huge task with no end in sight, does happen). Why?

Broad tasks are basically - as far as perceived progress goes - exponential. You're tackling problems all over the place at first, and nothing works. Then, as you keep ploughing on through the problems, you start to gather steam as you get enough of the foundation problems fixed to start tackling specific problems.

The problem with foundation issues is that ultimately, you have to fix them. You can't put them off. If you don't fix them, nothing works. But fix enough of them, and that picture changes. You can start tackling specific problems. And specific problems have a number of great qualities:

• They're narrow (aka specific). You can look at them, and see the shape of them. They fit in your brain.
• They're finite in scope.
• They're understandable.
• They're typically jenga blocks in reverse. Take them out, and whole systems come online.

Do the problems actually change at all? No, you're actually fixing specific problems the whole time. It's just that they were buried in a sea of other problems, and so they were masked, and you were also thinking about all the other problems as well.

Think of it as a huge party, where hundreds of people are shouting as loudly as they can, and everyone's standing shoulder to shoulder... and not only that, but you're the host, so your responsibility is to go and talk to every single person - even if you can't even squeeze through the crowd. Once you get a little breathing room and throw a bunch of people out, you can start having a normal conversation, and spend some quality time with your guests.

Power Curve

Here's the fun part. OK, so you're starting to thin out the problem "herd" and you've finally hit the point where not only do you know most of the systems you're working on pretty well at this point (ie. you know the mental geography of the problem you're fixing), but the herd is really thinning out. You've reduced the sea of problems down to a few rivers.

And all of a sudden, your activity level goes up, because you're making real progress. At least, you can see that you're making it.

Back to the cocktail party analogy - you're looking for people who need a fresh drink. Much easier to spot when there's only about 10 people in the room, instead of 100. Not only that, but you start noticing similarities between them - maybe three people want martinis, so you can do all of those in one go and save yourself some time.

All of a sudden, you're fixing problems, and systems start to come online. Maybe they don't work yet, but you know what you have to do to get them to work. And you know what? That's a great feeling.

In the Zone

This is the great part. All of a sudden, you've reached the point where you're making regular fast past progress. The brunt of the task has been done, and now you're at a point where you can get a good handle on your work. Here's the cool bit.

This is where the externally visible progress part of the graph takes off like a rocket. You've already slipped out of your funk, and have been grooving on the system for a while now. And with your happiness at the progress you've made, and all the positive feedback that gives, you're on a bit of a high. So your output increases.

But not only that... shortly after this point not only have you nailed enough of the problems to the wall that you're happy about what you're going, and can make targetted attacks, but at this point enough of the foundation work has been laid that the problems that remain aren't completely deadlocking your work from... well... working. All of a sudden whole systems are coming online with a few annoying hangnails here and there where things crash or don't work right. The important thing though is that until this point those systems didn't appear to work at all.

It's like an exponential curve. You've got to get past all of the long flat part until you hit the knee, and then it shoots off like a rocket.

Suddenly, to the outside observer, you're making continued, amazing, daily (or even hourly!) progress. Has anything changed?

Not really. You hit that point personally about a week before, but no one could see what the fuss was about. But the slope of your expected activity curve is now looking mighty shallow compared to the visible progress. Vindication! All those hours where people were wondering if you should be considering an alternative career path are now worth the pain.

And what does that do?

It bumps your activity up even further. Now you're jazzed, because not only can other people see what you knew you'd been doing all along, but the task is now starting to look easy to you. The visible progress curve lags the actual progress curve; at this point, you're down to a cocktail party with about 3 people, and you're serving the coffee and brandy.

Back-Patting

It's inevitable that an engineer after a long, arduous task, is going to indulge in a little back-patting. After all, if this was a race, then they've just been sprinting non-stop - which was a wonderful change of pace after trying to run through the middle of a swamp.

The only issues left to fix are pretty much in two categories - minor ones, which aren't preventing immediate progress, or huge ones which were discovered as the work went along, and have been worked around for now, and need some serious TLC in the near future.

But not right now. Because right now, they need a bit of a rest.

This phase is pretty short. It comes as the amount of issues remaining drops to only one or two. The top of the visible progress power curve is reached right at this point, and begins to slope down again - but now it's pretty much consistent progress going forward.

Refractory Period

Back patting is over, the engineer is a little mentally exhausted still (the low after the high of getting as far as they did). Now starts the ramp back up to regular productivity levels (the expected line now does have true meaning, because presumably we're back to narrow scoped tasks).

If you're going to give them some time off for good behavior, now is the time. They've milked their praise, and that little extra bit of buzz is wearing off. So now that they've done their work, and given their bows to their peers in the audience, let them go off stage gracefully and recoup their physical and mental energy.
And lo and behold... the task is done. It was a rocky road. And some rock stars were discovered.

The Secret

Some people can get past the initial curve by discipline and stiff upper lips alone (the aforementioned Bulldozers).

If you don't want to get fired, fight that visible progress curve by providing regular progress updates - never go "dark".

And the biggest secret of all?

All tasks work like this. Even the little narrow focused ones. It's just that it's over such a short period of time that you might not even notice the ups and downs, and the relative durations of each of the phases will change. About the only time it differs is if you've done something very similar many times before, in which case you might be able to avoid most of the doldrums at the start.

Even big, multiperson tasks work like this too (eg. Entire Projects). Different people in different disciplines might be at different points in the curve, but large projects do work like this.

Project Managers, Lead engineers (call them what you will) try to fight the visibile progress curve with a number of tools - milestones being one of them - for a number of reasons. Executives and financiers don't like it when a project isn't making visible progress at a consistent rate. Potentially more importantly, people can feel the ebb and flow of a project, and this can affect their productivity. Best to keep a good shiny face on things, and continuous displays of concrete progress will do that for the team - and that's good for the health of the team.

The only trick is, don't ever, ever, ever jeopardize the foundation of your project (you know, that long shallow part) solely to satisfy the need for visible progress. Because that will come back and bite you in the ass, big time, as that foundation you skimped on crumbles around you later. If you must muck around with that part, make sure you have a plan, everyone agrees on that plan, and you have a written document which specifies how and when you're going to go back and fix things up. It'll be more painful than doing it right up front, but that's the trade off you make.

More on that in a later post.

Finding Balance

Name of the game right now?

Finding balance.

Yep, I know, everyone's on the search for balance, aligning their chi, making sure their karma's net positive, looking after themselves, etc etc etc. Sure, it's old hat, it's cliche and it's boring. But frankly, that's what I'm trying to do with my life right now.

I think I'm getting there. On the whole I'm feeling better than I've felt in ages. My brain has started working again. If anything, it was running at about 20% capacity for the past year... if not longer. Now? I'm back up to about 70%.

How?

The old chestnuts of exercise and diet are helping a lot in that regard. (Exercise: Lots of walking and cycling, at least 8 hours a week. Diet: lots of greens, oddly, seems to be helping. Limiting my alcohol consumption is helping too. Marianna's by the Market has a lentil soup and a thing they call "Horta" which is frankly fantastic).

Not on any drugs any more - other than strattera, which seems to help with sleep and my sinuses, and gives my system a bit of a bump - which was surprising.

Lots of supplements - Omega 3, L-Tyrosine, L-Lysine, 5-HTP, and a couple of really good multivitamins, sublingual B12, and B6 before I go to bed.

I've nearly eliminated High Fructose Corn Syrup from my life too.

Net effect? I seem to be feeling a lot better than I have in ages. There's another part of this puzzle though, and that's just plain old listening to yourself.

I've started listening to myself. When I feel tired, I go to sleep. When I feel like staying at home, I stay at home. I always used to listen to the big emergency signals of "I feel restless", and "I wanna play" - but now I'm listening to the other ones. I don't stay at a bar until 2am just to close it out any more - I leave when I'm done. (Even then, most of the time all I'm doing is drinking cranberry juice).

All in all, I feel much better now than I have in ages. Are all of these changes necessary? Well, the diet and exercise ones were mandated by my doctor for high cholesterol and high fasting blood sugar, so while I don't know whether they make a damn bit of difference, they're getting done anyway. I think that the listening to myself ones are the most important ones right now.

Big changes at work too. I've managed teams of people on and off for about 6 years total, and general consensus is that I'm really good at it. But with everything else going on in my life right now, I've just been dropping the ball in too many ways. Fortunately, the people I work with are really really ultra cool. They saw this happening, and decided that the best way to deal with it was to lighten my burden (even though I'm already through the worst of it and coming out the other side). So instead of leading a team now (bye bye, Lead Gameplay Programmer!), I'm going to be exercising my mental muscles a bit more, and have become a Principal Gameplay Programmer (hello, Principal Gameplay Programmer!).

Basically, it means that I can stop worrying about intrapersonal dynamics, and start worrying about the technology. Most importantly, it means that I should be able to tailor the amount of multitasking I do to the amount I've actually got enough bandwidth for right now.

I'm not 100% sure about this change... in some ways, it bruises my ego... I've been on the manager track for a long time now, and I have a lot of my identity tied up in the fact that I was able to steer the careers of the guys on my team, and be someone they could depend on to fight for them when they needed it, and shelter them from randomness.

Although frankly, sheltering from randomness has become more and more difficult since we switched to an "agile development" model at work. I'm still not convinced that this method actually works for software development except on ultra small teams.

Either way, my load's lighter, and I'm thankful for that. It'll help me while I'm balancing myself out.

I live in interesting times :)