Birthday Musings

Yesterday we celebrated the 7th birthday of our middle child, who we sometimes refer to as the Smaller Animal.  It was a double party, the other half being the younger daughter of our Sister Family.  I’ve mentioned them before, and it’s perhaps occurred to you to wonder why we refer to them that way.  A brief summary then:

The Mother and their matriarch are best friends.  Our elder son and their elder son are best friends.  Our younger son and their younger daughter are best friends, and also only ten days apart in age (which explains the double birthday party).  The father and I are both programmers.  Their children and our children are all homeschooled, and currently both attending the same charter school program.  We have three cats, a guinea pig, some fish, and a ball python.  They have a dog, some frogs, and a bearded dragon, and their elder daughter raises ball pythons.  We share similar tastes in music, movies, and books.  We have similar outlooks on politics, institutions, housecleaning, and punctuality.  We are, as they say, simpatico.

So, you know, when your two families both have children turning 7 within 10 days of each other, and they’re best friends, it only makes sense to have a double birthday party, right?  We chose a local children’s museum as the venue; our Sister Family’s elder daughter works there and got us a sweet discount.  It’s a pretty awesome place for a birthday party, especially for kids at about that age.  There were cupcake cakes (if you don’t know what that is, here’s a picture of one that’s very similar to one we had yesterday), and snacks, and presents, and the kids all got to pet bunnies and bearded dragons and starfish.

All of which is mostly a long-winded way to say that I’m not going to do a longer post this week.  Or you could look at it as a recommendation for a cool place to take your kids, if you happen to live near me.  Or you could look at it as my finally explaining what the hell I mean when I say “Sister Family,” and giving me a post to link that phrase to forevermore.  Or you could look at it as yet another proof that you really shouldn’t be reading this blog.

Little Things Add Up

It has long been an axiom of mine that the little things are infinitely the most important.

— Sherlock Holmes (“A Case of Identity”, Sir Arthur Conan Doyle)

A few years ago, the architecture team at my work (of which I am a part) put together a presentation for the business designed to explain why a serious rearchitecture was important.  We all contributed ideas and analogies and metaphors, and different ways to illustrate the problem.

One of the ones that I contributed was this:  Many times throughout your work week as a programmer, you run across things in our ten-year-old codebase that you just don’t understand.  Things that look insane.  Things that look like they couldn’t possibly work, and may in fact represent subtle bugs that no one’s ever been able to catch.  When you find such a thing, you have two choices: you can ignore it, or you can fix it.

If you fix it, you risk breaking something.  This, after all, is the source of the ancient adage that “if it ain’t broke, don’t fix it.” By “correcting” something without a complete understanding of just what the hell it’s supposed to do, you may correct one subtle bug only to introduce another.  The new bug could be worse.  It could cause a loss of revenue that’s not immediately obvious, and you might end up six months later in some business meeting trying to explain how you cost the company tens of thousands (or hundreds of thousands, or millions) of dollars because you “fixed” something that no one asked you to.  If you are a corporate programmer with any reasonable amount of experience, this has already happened to you in your career.  Probably more than once, even.

So, for any one given situation like this, the smart thing to do is to ignore it.  That is, from a risk vs reward perspective, or from a return-on-investment perspective (both of which are very proper business perspectives), the right thing to do, the responsible thing to do is to just leave it and move on.  Because the advantage of making your codebase just a tiny bit more sensible and sane isn’t worth that risk.

But the problem is, all those little things add up.  When you stand back and look at the big picture, over the course of ten years you’ve made thousands (or even tens of thousands) of individual decisions where each one was the right decision individually, but together they spell disaster.  Together, this approach means that you are literally incapable of ever improving your code.  Your code is, by definition, continually going to get worse.

Among the maxims on Lord Naoshige’s wall there was this one: “Matters of great concern should be treated lightly.” Master Ittei commented, “Matters of small concern should be treated seriously.”

— Yamamoto Tsunetomo, Hagakure

It’s very popular in business culture to quote Sun Tzu.  After all, the competition of companies often seems like a war.  Plus pithy quotes like “attack the enemy’s strategy” and “speed is the essence of war” sound really cool when you break them out in a business meeting.  In reality, The Art of War does have quite a few valuable lessons for us.  For instance, “lead by example” (technically, “a leader leads by example not by force”).  That’s pretty good advice.  Or how about this one: “Pick your battles.”

Actually, what Sun Tzu said was: “Thus it is that in war the victorious strategist only seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory.” But most people interpret that as just a more flowery version of “pick your battles.” And plenty of people have expounded on this theme.  Jonathan Kozol, educator and activist, once said: “Pick battles big enough to matter, small enough to win.” It seems like where Sun Tzu started was an aphorism on trying not to get into battles you know you can’t win.  But where Kozol, and most of us, seem to have ended up is closer to the military version of “don’t sweat the small stuff.” That is, learn to let the little things go so you can save your strength for the big ones, the ones that are really worth fighting for.

And certainly this seems to make good sense.  If you’re going to be losing any battles, they probably ought to be the ones that don’t matter as much ... right?  As we contemplate where to direct our energy, where to concentrate our efforts, when each little battle comes along, it’s always going to make sense to let it go and wait for the big problem that’s inevitably going to show up tomorrow.  But, the problem is, there’s a flaw in this reasoning.

See, little things add up.

I think we’re looking at the wrong end of the trite maxim spectrum.  Maybe we should be considering that “mighty oaks from little acorns grow.” Or that “a journey of a thousand miles begins with a single step.” This is what disturbs me about the (quite common) corporate attitude that, as employee freedoms are eroded bit by bit in the name of increased efficiency, each such loss is a small battle, and not worth fighting over.  I often speak out about such things, when I have the opportunity.  And I’m often told that I need to learn to let these little things go, because, you know, there are bigger fish to fry.  Pick your battles and all that.

So I get a lot of eyerolls, and shaken heads, and derisive snorts, because I’m making mountains out of molehills.  I need to go along to get along.  Because my argument is one of those “slippery slope” arguments, and you know how silly those are.  Let gay people get married today and tomorrow we’ll have legalized bestiality.  Stop people burning flags and next thing you know our free speech is gone.  That sort of thing.  Poppycock.

But here’s the thing.  When you first start a job, the world is full of possibilities.  And the environment of the place—the culture—is awesome ... if it weren’t, you wouldn’t have taken the job, right?  And if, later, after you’ve been there for a while, some little small thing that attracted you to the job is taken away, it’s not a big deal, right?  There’s still all the other things you liked.  And, the next year, if one other little thing disappears, it’s still no big deal, right?  This job is still far and away better than anything else you could find out there.  And if, the year after that, one more little thing is taken away ...

Here’s another saying for you: death by a thousand cuts.  None of those individual cuts hurt, really, but one day, you just realize that there’s no point in going on.  And you start to question whether it really is true that there couldn’t be something better out there.  And you toss off an email to some random recruiter and next thing you know you’re moving across the country to an even more awesome job.  (But then I’ve told this story before.)  And then you start the whole cycle all over again.

The really sad thing is that, no matter how often this happens, the corporate managers will never see it coming.  See, from their perspective, people are quitting over stupid, trivial things.  And people that will quit over stupid, trivial things ... you don’t want those people anyway, right?  There was nothing you could do.  They were unpredictable.  Anything might have set them off.

They’re missing the big picture.

They let the little things slide, because they weren’t worth fighting for, and the little things added up.  There were haystems snapping dromedary spines right and left, to coin a phrase.  Is it really true to say there was nothing they could have done?  I wonder ...

I wonder what Sun Tzu would say if asked that question.  It’s sort of difficult to know for sure, seeing as how he’s been dead for about 2,500 years.  But I could hazard a guess.  I think he’d say this:

Treat your men as you would your own beloved sons. And they will follow you into the deepest valley.

— Sun Tzu, The Art of War

Perl blog post #11

Yet another CPAN catch-up week.  I was pleased this week to put the finishing touches on another one of my sabbatical projects, and it allowed me to make a new release for Debuggit, which was the first module I ever released to CPAN.  So, again, if you’re a Perl geek, check it out, and, if not, find something else to amuse yourself this week.

The Care and Feeding of Code Monkeys

Welcome to part 3 of my 2-part series on how to make Agile Development actually work.  This one has to do with managing programmers, which is both completely outside the purview of Agile and yet inextricably tied to it.  (It also ran a little long, since it’s a topic that I’m very passionate about.  Hopefully you’ll stick with it.)

First, a word on nomenclature:  At my current job, I am a “software engineer.”  At my last job, I was a “code monkey.”  What I really am is a programmer.  You can dress that up however you like, but, if you primarily write code for a living, you’re a programmer, and the following thoughts apply to you.  Be careful applying it too broadly, though: folks in other tech pursuits that hardly sling code at all, like system administrators and DBAs, may not fit the mold I outline here, and folks who write a lot of code but also do a lot of other things (e.g. QA engineers who specialize in automating tests, release managers who have to help code up things like continuous integration systems) may sort-of-kind-of fall into these patterns ... or not.

And, though I say above “if you primarily write code for a living, you’re a programmer, and the following thoughts apply to you,” what I really mean is, “if you primarily manage coders for a living, you’re managing programmers, and the following thoughts apply to you.”  For the advice I’m going to give you is pretty useless if you’re the one being managed.  We typically have so little say in those sorts of things.  Which is sad, really, but a topic for another time.

Next, a note on my qualifications.  I ran my own software development business for 12 years, and I followed one simple philosophy: keep your employees happy.  I never worried about keeping my customers happy, because I found that, if you keep your employees happy—and not just content, but deliriously, ecstatically happy; happy to the point where, at the end of the day, they’d rather stay at work because it’s more fun than going home—they’ll produce such amazing software that the customer satisfaction thing just takes care of itself.  I had more than one employee tell me that it was the best job they’d ever had.  Very few of my employees ever left for any other reason than I’d run out of work for them, and nearly all the ones that left because of that ended up coming back later.  I had an employee once sit at home jobless for a year and a half because he was just waiting for me to call with more work (and also because I’d paid him well enough that he could afford to do that).  When I tell you that I know how to manage programmers, I ain’t fucking around.

And finally (at least as regards this introduction), a cautionary note.  I generalize.  I think it’s good to generalize, even about people, as long as you remember that, at the end of the day, we’re all different, and we all need to be treated just a little bit differently.  You must be careful not to fall into the trap of stereotyping.  But there’s still a lot to be gained by understanding the whole through understanding the majority (because, even though we’re all different, we’re all the same), so absorb what I’m saying here, but remember that you’re always going to encounter exceptions.

So how does one go about managing programmers?

Well, there are two things that you must remember.  The first I’ve already discussed in some detail, and it would be pointless to belabor it again.  I’m talking about the issue of perception vs reality.  If you’re too busy to click that link, here’s the executive precis:  Programmers spend all day talking to computers, which are insanely literal; they tend to lose their concepts of perception.  You, however, are most likely a business executive, for whom things like your perception in the marketplace, your reputation, and your perceived brand value are paramount.  This leads to a fundamental disconnect.

The second one I touched on in my exploration of what agile means: programmers are craftsmen.  Very few people get this.  Most folks think programmers are all logical and mathematical, like Vulcans.  And it’s true that programmers have to have a logical component to their personality.  But some of the worst programmers I’ve ever met were mathemeticians, or mechanical engineers.  Not to disparage those professions—they’re very fine careers.  But the point is, those fields attract people who like things to fit together neatly and sensibly.  Programming isn’t neat.  It’s heinously messy.  Stuff goes wrong that no one can really explain, there are bizarre interactions between complex systems that were never foreseen, and there’s all these terribly illogical users involved in the process.  People who like things tied up in a bow get really crazy when they have to develop software.

But, even more than that, coding requires creativity.  There’s actually one backwater of mathematics that I remember from my school days which was a bit like programming: proofs.  I first learned them in geometry, which I took in the ninth grade.  A proof is a way to chain together different rules: this rule leads you to that rule and thence to the next, and so on.  To chain these rules together requires a very logical mind.  But you also need to have a sense of where you’re going, and that’s where the creativity comes in.  You need to be able to make a creative leap to the end first, and then be able to logically work your way there from the beginning.  If you start a proof without a clear idea of where you’re going, you most often end up right back where you started.

And so it is with programming.  That creative leap is absolutely crucial to being a top-notch programmer.  Without it you’re just a monkey pulling wrenches.  If more people understood this, the world (or at least the business world) would be a better place.

Because I think that the business world already understands that you have to manage creative people differently.  Advertising agencies, for instance, routinely hire artists, and writers, and people whose sole job is just to come up with ideas.  They’ve figured out that you can’t treat these people in the regimented fashion that you do for other workers—giving them dress codes, and set hours, and making up weird little rules about what they can and can’t put on their cubicle walls.  (Not that I’m saying that those are good ways to treat anyone, really.  Just that trying to treat creative people in such a fashion is even more doomed to failure.)  The Internet culture that came out of California in the ‘90s (and in particular out of Silicon Valley) has gone a long way towards fixing this for programmers.  There are many businesspeople who now understand that programming can be fun and they need to encourage their employees to have fun while doing it.  (That attitude is still more prevalent on the West Coast than the East, in my experience, but we’re getting there.)

But what I’m not sure of is whether the business folks realize why they need to promote the culture of fun.  See, there are many jobs where you don’t really need to think very hard to get the job done.  You just do them.  They’re mostly easy, and a bit repetitive, and, once you’ve done them two or three times, you can practically do them in your sleep.  Again, this is not to denigrate any of those jobs, or any of the people who enjoy them.  I can certainly appreciate a job where I can let my mind do its own thing all day while my body churns out work.  That’s a cool gig.  But that’s not my job.

My job doesn’t just require me to think; it requires me to innovate.  Every day, in a thousand little ways, I make tiny little creative leaps (and sometimes, if I’m lucky, a few giant creative leaps).  In order to do that, your mind has to be relaxed, and clear.  Focussed is good, sometimes, but other times stepping away and focussing on something else entirely (like a rousing game of ping-pong) is exactly what the doctor ordered.  The one thing you absolutely cannot do is just plug away at it until it works.  That takes forever, and ususally produces a mess.  You need to be able to distract yourself, or maybe even just close your eyes and lean your head back and ponder.

Note that I say you need to be able to distract yourself.  Having other people distract you doesn’t help.  In fact, it’s horrible.  Just ask Samuel Taylor Coleridge.  Programming is brief periods of seeming inactivity (waiting for inspiration to strike) followed by intense bouts of insane productivity (where you put the inspiration down on paper, or in this case on screen).  This is why programmers always want to work from home.  Other people can distract you at home occasionally (particularly if you have a family and if you don’t sit them down and go over the “rules”), but in general the phone doesn’t ring, and people don’t wander by your desk for a quick chat, and there are no meetings.  I know that you, as a businessperson, value meetings.  You think that if you spend all day in meetings, you’ve actually accomplished something.  We programmers are different.  Our job is to write code.  You can’t write code in a meeting.

And the business world (even the California business world) is reluctant to let programmers work from home.  It’s changing, a bit, but still there are too many classically trained managers out there who believe that, if they can’t see you working, you must not be working.  This is 100% a trust issue.  I’m a programmer.  I’ve been a programmer for 25 years—that’s over half my life (actually, I’ve been a professional programmer for over half my life; I’ve been a programmer for about two-thirds of it).  I want to program.  You want me to write code, and that’s what I want to do.  If you let me go home, you know what I’m going to do when I get there?  Program.  Programming has got be one of the few jobs in the world like this.  When you’re a programmer, you relax after a hard day of writing code by writing more code.

So you don’t have to come up with strategies for making me do what you want me to do.  What you need is strategies to make sure nobody stops me from doing it.  Reduce my interruptions.  Reduce my meetings (agile helps with this).  Reduce my emails, if you can, and reduce the people who just pop over to get my opinion on something.  Stop telling everyone that they should not send me an email because it’s better communication if they come talk to me face-to-face.  It may be better for you, but it’s death to me, and to my productivity (and isn’t that what you’re striving to maximize?).  I want fewer emails too, but given the choice between a communication that I can attend to when I was going to take a break anyway and one that blows my concentration and makes me drop the threads I was juggling in my feverishly inspired brain, guess which one I’m going to take?

Now, it’s true that you also have to find a way to focus me.  Programmers, like magpies, are notoriously easy to distract with shiny things, like new computers, new software, new web sites, and discussions about geeky hobbies like roleplaying and MMORPGs and Renaissance Faires.  And, along those lines, we can get off track, chasing down something that seemed like a good idea at the time, but in retrospect turned out to be a giant temporal black hole.  Getting back to how agile addresses these issues, that’s what “daily scrums” are for.  It’s the chance for the programmer to say “well, yesterday I spent all day looking for a decent Javascript beautifier that would unravel this minimized code I’ve been staring at for the past week,” and the chance for someone else on the team to say “dude, I got one back at my desk; I’ll email it to you.”  There you are: problem solved, distraction eliminated, yak shaved by proxy.  Or perhaps they’ll describe the problem they’re stuck on and someone else will say hey, I’ve solved that before, I can help.  Whatever.  The point is to keep the coder on track and working towards the solution.

And, as I also mentioned in the agile theory post, we programmers are tinkerers, and it’s the responsibility of the business to help us from getting lost in that and never finishing anything.  You have to be careful not ot take it too far of course, because some amount of tinkering is necessary to keep things running smoothly.  It’s a careful balance, but you’ll get the hang of it.  Give us some rope, and be prepared (but not anxious) to tug us back if we range too far.

But, other than that, there’s actually very little you have to do to get us to produce the software you want.  In fact, the more you do, the more likely you are to make it worse.  Programmers react to micromanagement by slowing down: you want to focus on trivial things? fine, I’ll focus on trivial things.  Programmers react to attempts at measurement by getting picky and measuring everything in sight.  Programmers react to bonuses based on lines of code by writing unnecessary code, they react to bounties for finding bugs by adding more bugs, and they react to having to meet detailed performance goals by adhering to the exact letter of the goals and completely ignoring the spirit.  Businesspeople tend to find this more than annoying: they find it downright insubordinate.  But think of it this way: first, a programmer is prone to taking things very literally (talking to computers all day, remember?), and secondly you actually pay them to find the most efficient solutions to thorny problems.  Don’t get ticked off if they end up turning that ability against you when you try to control their workday.

In fact, getting the most out of programmers generally amounts to not pissing them off.  Not treating them with respect, or not trusting them, pisses them off.  Asking their opinion about something and then ignoring it really pisses them off.  Asking them to produce shoddy software because you’re in a hurry makes them livid.  Expecting them to do a lot of things at once and not understanding the simple fact that shit takes time (and also that nine women can’t make a baby in one month) makes them rethink their choice of employer.  Agile will help you with a lot of this.  Some of it, though, you just have work out on your own.

And it ain’t hard.  We programmers are simple creatures, really.  You’re just not used to us because we’re different from anything you’ve ever had to manage before.  And here I’m going to be presumptuous and move from giving you advice on programmers to giving you general advice on management (but, remember: I’ve actually managed people, even people other than programmers).  Robert Heller, a well-known writer on the topic of management, once said:

The first myth of management is that it exists. The second myth of management is that success equals skill.

Now, like any good quote, that’s going to mean different things to different people.  But here’s what it means to me:

The first sentence merely means that most people treat management as an active thing, whereas they should be treating it as a passive one.  Voltaire (supposedly) said: “The art of medicine consists in amusing the patient while nature cures the disease,” and the same applies to management.  Much of the time, the best way to succeed is simply to get out of the way.

The second sentence means that you must be careful not to let yourself get caught in a feedback loop.  If you undertake a style of management which is actually very horrible, and your employees succeed despite you, you may believe your ideas are validated.  This is important to understand, I believe, because it answers of the question of “why haven’t people figured all this out by now?”  If you’re a business executive reading this post and shaking your head and saying “man, this guy is crazy!” then I urge you to go find a programmer and give it to them to read.  They will no doubt nod and mutter “oh, yeah, that’s so true” under their breath the whole time.  The fact is, nothing I’m saying here will come as any surprise to any programmer working in America today (and probably not to the ones working in other places either).  And yet business has managed to go 50 years without figuring it out.  How?  Are businesspeople stupid?  No, of course they’re not.  But management, like medicine, can seem like it’s working even when it’s doing more harm than good.  Remember leeches?  People thought they worked too.  Those people weren’t stupid either.  But, as it turned out, leeches were a pretty bad idea.

So rethink your strategies with your employees, particularly if they’re programmers.  Don’t stand behind them and push.  The definition of the word “lead” implies that you have to be in front.  And not pulling either: just striding ahead, with confidence.  (And a few donuts wouldn’t hurt either.)  You don’t even have to look back that often.  If you are a business with hard problems to solve, we’ll be following you.  After all: solving hard problems is what we live for.

Pitfalls in Agile

[This is part 2 of a series of posts on Agile Development.  First you should decide if you care about that at all.  Then, if you decide you do, you should make sure you’ve read what I wrote last week about what agile means.]

So now we know what the attitudes towards agile should be.  But, as I’ve said, often they aren’t.  Sometimes it is that tech are the ones who don’t get it.  But I’ve found in my experience that it’s more often business.  Tech, after all, is used to not always getting what they want.  But business is the driver of a business—it’s right there in the name, after all.  What business needs, they get.  They’re not used to hearing “no.”

But here’s a crucial fact: agile did say to business “you’re not going to get everything you want,” true.  But that’s not the same as saying “no.” What it’s saying instead is, “you must make a choice.”

In 1975, Frederick Brooks was considered a revolutionary for pointing out that nine women can’t make a baby in one month.  When I said that in a meeting recently, I got nervous titters and a few frowns.  Yes, that’s right: even after forty years, people are worried that I might be talking about something vaguely related to sex instead of recognizing that I’m quoting The Mythical Man-Month, possibly the most seminal work on software management ever published.  How is it that there is a single person in software development who doesn’t know this work, or at least the general concepts of it?  MMM is whence cometh Brooks’s law, which states simply that “adding manpower to a late software project makes it later.” Surely if you’re in the business of software development—from either side—these are concepts you need to understand.

But the point that both Brooks and agile are attempting to make is that we don’t say “no.” We must instead reframe the question.  If you need to buy two items that each cost $100, and you have $100 in your budget, you don’t say “no” to one or the other—you simply choose which one you will buy now, and which you will buy later.  In fact, allocation of limited resources is something that business does extremely well.  This is because of the numbers thing again.  Juggling numbers and balancing expenditures is the true forté of business.  Agile is not attempting to deny business’s requests.  It is reframing the question in terms of prioritization of one of the scarcest resources business has: the time and effort of its tech department.

Because tech can’t possibly do everything at once.  It can often do many things at once (depending on the size of the team), but it shouldn’t come as a surprise to anyone that coming up with ideas is easy and implementing them in the real world is hard.  Which means that business will always have more for tech to do than tech can possibly complete.  Which, in turn, means that business has to choose which things are the most important.

This should not be a radical concept.

And, yet, in every corporate environment I’ve ever worked in (and I dare not even exempt the business I ran myself for 12 years), business tells tech that every project is “the most important one.” Perhaps not all the time—perhaps not even most of the time—but always there comes that time when somehow it seems rational for business to just expect tech to do it all at once, without exceeding the budget, without missing the deadline, and without any one project suffering or dragging down the others.

But agile exposes the fallacy in this.  Agile gives us the concept of the “Iron Triangle.” One side of the triangle is time.  Another is functionality.  And the third is quality.  And, what agile tells us, quite explicitly, is that, if business will not move the deadlines, and will not accept any redcution in functionality, there’s only one other place where reductions can be made.

In fact, the whole point of agile is to institute a negotiation over functionality: the concept of “if you want to add something to this iteration, you have to take something out” is exactly that.  The time is not negotiable in one sense, because the dates of the iterations (often called “sprints”) are fixed.  But agile addresses time as well, by forcing regular releases before the final deadline of the whole project.  In this way, business gets value earlier, which mitigates potential losses should the deadline have to be pushed back.  And the end result is that tech can put in the quality that they wanted all along.

Where can this all go wrong?  Several places, but one of the big ones is with the Product Owners.

Agile is designed to work with small teams.  If you have a big team, you divide it up into several small teams.  These are tech teams, but they’re led by a person called a Product Owner, or just “PO.” The job of the PO is to be the liaison between business and tech.  That is, the job goes something like this:  First the PO goes to the business and say “What do you want?” Business tells the PO all the things it wants (of which there are likely very many).  The PO nods sagely and goes back to tech.  “Here’s what the business wants,” they say.  Tech promptly objects: it’s too much, or it doesn’t consider this challenge or that hurdle, or it will result in this drop in quality or maintainability, or it conflicts with this other piece of the system over here.  In this conversation, the PO represents business: “If you don’t want to give them this,” they’ll say, “then you better tell me why.  And use small words, and hard numbers.” After some back and forth, tech gives in on a few points, but stands firm on others.  Once the PO has pushed all they can push, they go back to business, and now they’re representing tech.  “The good news,” they say, “is that you can have this and this.  The bad news is that you can’t have that and that, or you can’t have it right now, or you can’t have it in that form.  And here are the numbers that demonstrate why.” Business loves this, because they love having numbers to analyze.  That makes it all make sense to them, as opposed to vague technical discussions of efficiency and flexibility.  “Okay, we’ll grant you that one,” business may say, “but this one over here we just can’t give up.” And the PO responds: “Tell me why.  And use precise words, and outline the risks and challenges of not doing it.” After more back and forth, the PO goes back to tech and represents business again.  “They agreed to give up on this thing.  But they have to have some solution to the other thing.  Here’s exactly why we can’t just not do it.  If you say you can’t give them exactly what they want: fine.  But you have to give them something.  You’re the technical geniuses: figure it out.” Tech loves this, because now they’ve been given a challenge, a hard problem to solve, something which will require them to think outside the box and push themselves to the limit to come up with an elegant solution.

So, as you can see, the PO has to represent both sides, at different times.  So obviously the first mistake you can make when trying to implement agile is to choose the wrong people to be the POs.  Most often what happens is that the Product Managers are chosen.  This is disastrous.  They have an inherent conflict of interest: when tech says “no,” they take it personally and throw up roadblocks.  When it’s time to go back to business, they are business.  They only people they’re likely to be reporting to are their bosses, and are they really going to push hard to represent the interestes of tech when it means disagreeing with their boss?  You can’t blame them for not doing that—it’s political suicide.

And agile is supposed to be all about communicating.  When a problem comes up, you’re supposed to report it immediately, so the business is aware that there’s a potential problem.  And the person you should report it to is, of course, your PO.  What happens when the PO is also the Product Manager?  You get immediate pushback.  “Unacceptable!” you’re told.  Suddenly you’re in the exact situation that agile is supposed to avoid: you’re under pressure to agree to continue to meet a deadline that is no longer feasible.  And tech people are, for the most part, an agreeable bunch who really don’t like confrontation: usually they’ll tell you what you want to hear, eventually, just to stop the uncomfortable situation.  So now either they have to work extra hours to make an unreasonable deadline (which leads to employee burnout and your best and brightest tech resources polishing up their résumés on Monster), or they starting cutting corners (the Iron Triangle strikes again), or the deadline just plain gets missed, which was probably going to happen anyway, except this time business didn’t get to find out ahead of time (surprise!).  All that communication that agile was supposed to be fostering gets destroyed.

The other thing that suffers when Product Managers become POs is team cohesion.  Agile is all about small teams, and people working together, and helping each other out, shoring up each others’ weaknesses.  This is why you always measure the velocity of the team and never that of its individual members.  When people work together on a team for long periods of time, they develop efficiencies of coordination: they know when someone is going to have trouble with this, or exactly who to go to when there’s an issue with that.  They can do things efficiently with a minimum of noise-to-signal in their interpersonal communications, because they know each other so well.  But when Product Managers are the POs, or even just assigned to teams, they have a tendency to want to shuffle the team members around instead of shuffling the work around.  If Product Manager A has more work to do than her team can handle, she goes to Product Manager B, who happens to have less work right now.  She wants to borrow some of his team members.  Perhaps Product Manager B doesn’t want to give them up; what happens if my projects heat up while you’ve got some of my people?  Even if you somehow manage to avoid the disruptive turf wars, and the transfer of resources is smooth, you’ve destroyed your team dynamic.  The transfer only appears smooth to the business side: on the tech side, the employee has a whole new team to learn about, new politics undreamt of, new social waters to navigate.  And, on top of everything else, you give your chronic underperformers a way to hide: in a situation where teams are for the most part permanent, you can count on your good employees to root out people who aren’t pulling their weight; when teams are constantly in flux, it’s more likely that they’ll just try to pass them around to another team, to (again) avoid the confrontation.

I’m not actually suggesting anything radical here; in Dean Leffingwell’s excellent Agile Software Requirements, for example, he makes it clear that Product Managers are not ideal POs, and I could cite many other sources.  But, in the end, this is a symptom, not a cause.  The cause is business not taking agile for what it is.  Too often it’s seen as some palliative: let’s just keep the developers happy, because we need them.  If this is what keeps them around, fine.  But we still want our deadlines met, no matter what.

This is contrary to the spirit of agile.  Agile, as we started out discussing, is about making hard choices.  It’s about saying what’s most important and how long things should take and how to deal with problems as they ariese.  When the business says, “this must be done on this date, and it must include all the features,” I’m somehow reminded of talking to small children.  Declaring something to be so doesn’t mean that it will happen.  You may even stamp your foot and hold your breath, if you like.  That’s not going to make the work go any faster.

In fact, unreasonable date pressure is probably the most common area where agile fails.  Of course, the hardcore agilists will complain that, if you have hard deadlines without functionality negotiations, you’re not doing agile at all.  And, perhaps, in a strict technical sense, you aren’t.  That doesn’t actually help address the problem though.  The problem is that tech people get very frustrated with these types of situations.  They’ll either buckle to the pressure, and make themselves miserable (back to polishing their résumés), or they’ll mentally give up, slow down, and make business miserable (and, I don’t know if business has noticed this or not, but it’s typically not the tech people who get fired if this scenario deteriorates).  Either way, business loses.  Their numbers suffer.  And this is not what business wants.

So the solution is for business to come at it with a fresh perspective.  For them to take the time to understand what agile means, and what it has to offer.  Agile is certainly not perfect (nothing is).  Agile certainly has lots of room for improvement (everything does).  But agile also takes a lot of different aspects into account, and actually produces a process that has the potential to make everyone happy in the long run.

There are companies out there who have seen that potential fulfilled.  Perhaps your company will join them.

[Having finished the second part of my two-part series, you may think you’re done.  However, I encourage you to stay tuned for part 3, where I talking about managing programmers.]

My Theory About Agile

[If you don’t follow software development, and in particular if you have no idea what “agile development” is, or how it contrasts with the “waterfall style,” this week’s blog post is not going to make much sense.  But that’s okay: I told you not to read this stupid blog anyway.]

Agile software development is really quite a cool thing, when done properly.  (If you disagree, please see my rant about hype.)  Unfortunately, most people who do Agile don’t really do it properly.  And, even more unfortunately, when Agile people try to help failing Agile shops, they often do it by pointing out where they deviate from a certain process (in whatever flavor of Agile is appropriate—XP, Scrum, whatever).  “You’re trying to do XP but you’re not pair programming,” they’ll say, or perhaps “you’re trying to do Scrum but you’re not standing up in your daily scrum meetings.” This is ironic (insanely ironic, even) because point #1 on the Agile Manifesto is: “Individuals and interactions over processes and tools.” So we’re supposed to downplay (although not ignore entirely) the processes, except when figuring out what we’re doing wrong, when suddenly it’s all about the process.  This seems wrong to me.  Most of the time when I’ve seen, or heard of, Agile going wrong, it isn’t the processes that are to blame.

It’s the attitudes.

I think that, in order to implement a good version of Agile—whether XP, Scrum, Crystal, or some melange—you need to start with an understanding of what Agile is supposed to give everyone.  So let me give you my theory on that.  Note that this theory is not backed up by scholarly research.  It is based solely on my own experience, and therefore is 100% anecdotal and useless from a strictly scientific perspective.  (As always, please refer to the masthead.)

Once upon a time, there was business, and there was tech.  These two camps didn’t always get along, primarily because of their radically different outlooks on the nature of reality and perception.  And one of the biggest conflicts they had (and, honestly, still do have) is when it comes to figuring out when something is going to get done.

See, tech people are horrible estimators.  We are, at heart, hopelessly optimistic.  I think this is mainly because, for the most part, we love what we do.  Which is unusual in the professional world, if you think about it.  Actors love what they do.  Musicians love what they do.  Professional athletes love what they do.  Really, if you think about it, programmers are some of the only people on earth who love what they get paid to do without ever getting rich or famous for it.  So, when you say, “we’re going to give you a really hard programming problem to solve,” we start salivating.  We’re looking forward to it.  When you say “now how long is that going to take?” ... we think about all the fun we’re going to have.  All the coolness, and all the interesting trickiness.  What we don’t think about is how long we’re going to spend going down blind alleys before we figure out the right way.  Or how long we’ll spend chasing down documentation on the new tools we’re going to have to learn.  Or how many bugs in IE are going to make us tear our hair out, or how long it’s going to take us to find our own bugs that QA thoughtfully pointed out to us after we were “done.” Or how much time we’re going to have to spend in meetings telling business why it’s taking so long.

So we underestimate.  It’s understandable, if not exactly forgivable.

Business has a different perspective.  They need to plan.  Us techies don’t plan.  We just do.  “It’ll be done when it’s done!” we say.  This makes perfect sense to us—after all, it couldn’t possibly be done before it was done, right?  But that makes businesspeople insane.  They need to market.  They need to develop release strategies and conduct market research and hold pricing meetings.  They need to write slick advertising materials about what the product will do, and there’s no way they’re going to wait to start doing that until after us techies are done making the damn thing.  So, to them, asking when it’ll be done is a perfectly rational question.

And thus the trouble begins.  I think that, probably, back in the dark ages of the software-induced shotgun wedding between business and tech, business would say “when?” and tech would answer “then” and business would say “fine” and then go away for however long that was.  Then they’d come back at the end and say “okay, where is it?”

This didn’t work.

After several iterations of not getting anything on the date they were “promised” it, business decided that they needed to check in with tech a little more frequently.  Maybe if they could at least know there were delays before it was too late to do anything about it, that might help.  Seems rational enough.  So let’s have a meeting every month just to see where we are.  And, you know, if meetings every month are good, meetings every week are better.  That’s just math.  Actually, meeting every day would be even better still.  Pretty soon, tech found that they might be spending as much as 20-25% of their entire workweek explaining why they weren’t getting any work done.

This didn’t work either.

Besides estimation problems, the other serious problem was specifications.  Business would say to tech “this is what we want the software to do.” And tech would say “okay.” And tech wouldn’t make it do that.  Exactly that; as I mentioned before, techies tend to be literaliststs.  Occupational hazard.  Whereas businesspeople tend to live more in the real world, where common sense is supposed to be applied to anything you say.  Silly businesspeople.  So there were communications problems.  And also, sometimes businesspeople don’t know what they want until they see it in action, wherein they promptly realize that they wanted something different all along.  Also, software takes time to develop, and the market doesn’t just sit around doing nothing while new software is being written.  Sometimes the requirements change in the middle of the project, and that’s not really anyone’s fault at all.

But somehow the solution to this problem became to make the specs bigger.  Longer, and more exact, and more like a contract.  There are legal documents—hell, there are bills in Congress—which make more sense and are easier to read than software specs produced by a serious waterfall methodology, like say ISO 9000.  And then, if something changed, everyone scrambled through their copy of the specs looking for the reason why it wasn’t their fault.

This was not particularly helpful.

See, there’s not only a fundamental communications gap between business and tech, there’s a fundamental difference in goals.  Tech wants everything to be beautiful.  Not perfect, because it can never be perfect, but at least pretty.  Most people don’t realize it, but programmers are craftsmen.  If you’ve ever engaged in a creative hobby—say, woodworking, or perhaps gardening—you understand pride of craftmanship.  When you make a chair, it better not be just good for sitting on.  It better be beautiful to look at, and detailed, and supremely comfortable.  When you plant a vegetable garden, it better not just produce food.  It better produce gorgeous, succulent vegetables that make the children’s mouths water and the neighbors green with envy.  If it’s not doing all that, you’re not done yet.  So it is with programmers.  It can’t just work.  Any moron can give you code that just works.  It needs to be code that other programmers will come along and read, and whistle to themselves, and be happy that such an amazing craftsman was able to provide them this as a starting point, because she just made their lives a thousand times easier.

Whereas business is all about numbers.  Mainly that bottom line number, the number that shows you how much profit you made at the end of the day.  But there are all sorts of numbers: customer satisfaction numbers, and product defect numbers, and market penetration numbers.  Some you try to maximize, and some you try to minimize, but it’s always about moving the needle.  Maybe you pull off some business maneuver that makes a good story over cocktails, but that’s just a bonus.  At the end of the day, you can tell whether you did well or poorly just by looking at the numbers, and numbers don’t lie.  And everyone else can tell how well you’re doing too.  It’s all very satisfying, in a visceral way.  When you get that report back, and the numbers are bigger (or smaller), you get this excitement in the pit of your belly, and you just want to pump your fist in the air and go “YES!”

And the thing is, it seems like these are completely incompatible viewpoints, but that’s not the real problem.  The problem is, they’re both wrong.  Oh, they’re both right, too (balance and paradox), but they’re both wrong.  And, when you put them together, they balance out nicely.  Tech without restraint becomes perfectionist, always tinkering with everything and never finishing anything.  Business without restraint becomes lost in the weeds of short-term gains and ignores the long-term goals that are being crushed.  Techies often forget that, if they don’t make deadlines, the bottom line suffers, and that’s what puts food in their mouths.  Businesspeople often forget that cutting corners today means defects—and therefore lost revenue—tomorrow.  But together, there’s a yin and a yang that usually produces pretty good results overall: not too slow, not too sloppy.

And this is what Agile attempts to do.  Agile says to tech, “You’re not going to get everything you want—sorry.  We’re going to give you an outlet for your concerns about doing things right, but you’re going to have to justify them.  And we’re going to put you in the driver’s seat on how long things are going to take, but you’re going to have to break it down into tiny little pieces and esimate every one.  And, yes, you’re going to have to give your status every day, but we promise it won’t take but 10 minutes.  If you want to spend longer on doing something the “right” way insead of doing it the expedient way, you’re going to give business numbers to show the difference.  This is how much it costs now, and this is how much it will cost later, and then business can make a rational decision on whether that trade-off makes sense.  And sometimes they’re going to agree with you, and you’ll be happy.  And sometimes they’re not, and you won’t be.  But it’s better than nothing.”

And then Agile says to business, “You’re not going to get everything you want—sorry.  We know you want 100% visibility into what tech is doing, but you can’t have that.  100% visibility equals 0% productivity, because it would be you and tech sitting in a room, with you going ‘What are you doing now?’ and them replying ‘Answering your question’ over and over again.  But we’re going to institute a structure so that nobody gets stuck for more than a day.  And we’re going to give you numbers.  How many units something will take, and how many of those units this team can deliver in a given time period.  That time period will be short—a month, or even two weeks—and you can specify exactly what will get done in each period (no more ‘tech spent 3 weeks doing this thing because they thought it would be useful’), but you can’t change your mind in the middle of the period.  If there are changes, just wait a few days until the new period comes along.  And the team is a team: they’re a cohesive unit that works together, and you can’t just replace team members or juggle them around like they’re factory components.  So you can’t bother them while they’re working, and you can’t try to measure them individually (which ends up creating destructive competition anyway), but you’ll get lots of numbers that let you know what’s going on and when things are going to get done.  And that’ll have to do.”

This is where business and tech need to start from if they’re going to try to make Agile work for them.  They both need to start from a place where they each realize they’re not going to get everything they want.  In my experience, most of the time when Agile goes wrong, it’s because tech is on board with this compromise, but business didn’t get the memo.  Next week we’ll look in more detail about just what can go wrong when that happens.

Guides: Willie Vadnais

[This is one post in a series about people who have had a great impact on my life.  You may wish to read the introduction to the series.]

I started my company back in 1992.  It wasn’t much more than just me for a while, but through the 90s I grew it, adding more and more employees.  Mostly I hired fellow coder geeks, but I also spent a fair amount of time trying to find someone to run the business side of things so I didn’t have to think about it, someone to handle the acquisition of new clients, the management of old ones, deal with the financial crap, etc.  Because all I really cared about was coding.

I had different amounts of success with this, but never did my company achieve any sort of greatness.  Sometime around 2004 business had slowed to such a trickle that I had to start looking for a full-time job for myself just to pay the bills.

Meanwhile, in 1995, in the exact same town I lived in, three friends started an ISP that would eventually turn into ThinkGeek.  And they actually did manage to achieve a sort of greatness—the chances are that you’ve heard of their company, but you’ve never heard of mine (trust me on that).  They did that because they had a core group that was actually good at acquiring customers.  They could have used some coding help, perhaps (though the original ThinkGeek code monkey was a demon of a workhorse and a great friend of mine to this day, he was only one man, and I’m sure he wished he had some help many times).

I’ve talked before about twists of fate that we think of as “coincidences,” and in fact the story of how I went to work at ThinkGeek is in that very post, so I shan’t repeat it here.  What interests me now, as I look back on this story, is how much our lives are shaped by the strange twists of fate that don’t happen.  For instance, the ThinkGeek founders and I were both working with Linux software in the same DC suburb.  The tech community there wasn’t all that huge.  How did we never meet?  Why is it that they, who had brilliant ideas and needed programmers, and me, who had brilliant programmers but needed ideas, never managed to connect?

“The ThinkGeek founders” consist of the three original partners, plus their original programmer.  I got to know all of these people pretty well over the course of the three years I worked there.  They’re all amazing, and amazingly talented, people.  In the music that ThinkGeek created, they were the core band: the rest of us were backup singers and studio musicians.  And, in the band that is ThinkGeek, the lead singer is Willie Vadnais.

Just as I was the one who founded my company, the one who, even though he was not its CEO, its President, or the chairman of its board of directors, was still the heart of it, the man behind its vision, the oracle of its Delphi ... so Willie was to ThinkGeek.  Not always in charge, but always the center.  The man with the plan.  If you wanted to know what ThinkGeek was, at its core, you talked to Willie.

There’s only one person I ever worked for who was more fun to work for than myself, and it was Willie.  I’m not saying he’s the best boss I ever had—hell, technically he was never my boss at all—but in terms of sheer joy in coming to work every day, nobody has ever beaten Willie.  I looked forward to going to work every day when I worked at ThinkGeek even moreso than when I worked for myself.  And he was a big part of that.

Willie is in some ways a walking oxymoron.  He’s a true salesman, and also a consummate geek.  Now, in my post on reality and perception, I discussed why these are generally opposite sorts of people.  They have diametrically opposed outlooks on life.  So it’s pretty rare to find both outlooks in the same person.  But Willie is that guy.  He can come up with the brilliant ideas, sell them to the people who need convincing, and still talk technical details with the people who need to implement them.  Honestly, he’s ruined salesmen for me forever: I’ll probably always compare any new ones I meet to him, and they won’t come out looking very good.

The folks who founded ThinkGeek sold it to a larger corporation many moons ago, before I ever came along.  But they all stayed on to help run the company, to help keep things going smoothly, to keep the company true to its roots.  Jon still wrote all the back-end code, and Jen still wrote all the front-end code; Scott still dealt with all the geeky, techy hardware that ThinkGeek sold.  And as for Willie, he still kept coming up with the ideas, finding the unique products, rethinking how the website should work, tossing out the witty slogans that ThinkGeek would put on the tee-shirts.  But, one by one, the founders left ThinkGeek, moving on in frustration or pushed out by corporate overlords who didn’t understand that the company couldn’t be the same without them.  Finally, only Willie was left, and, this past Monday, ThinkGeek said goodbye to him as well.

Now, I don’t have any special insight into the corporation that currently owns ThinkGeek.  I don’t have any insider information.  But I’ve seen this pattern in corporate dealings before.  It’s amazing how efficiently a corporate machine can dismantle a golden goose to produce goosesteaks.  ThinkGeek will go on, I’m sure.  There are still many good people who work there, and they will do their best to make sure the company lives up to its reputation.  But its heart is gone.  ThinkGeek without Willie is ... strange to me, a foreign beast that I’m unsure what to do with.  I’m not sure I can in good conscience continue to shop there.

I consider Willie a friend of mine.  He was wonderful with my children, he had me over to his house on many an occasion, and I’ve gotten roaring drunk with him several times.  He’s wise in some ways, and full of childlike wonder in others.  He knows what people want, what they like, what will please them and tickle their funnybones.  He’s one of the few people in the world who, if they came up to me today and said “I have an idea for a new business,” I would say “I’m in” without even needing to hear the rest of the pitch.  He’s inspired me sometimes, and frustrated me sometimes, and made me laugh a whole lot of times.  He challenged my beliefs about salemen.  My life is richer for having known him, and I hope I get a chance to work with him again someday.

Every now and again, I get a late-night IM from Willie, although it hasn’t happened in quite a while.  Usually, he’s trying to convince me of some insane premise that’s he’s come up with, often after imbibing a few intoxicants.  This might be a business premise, but just as often it’s something else entirely.  I am typically skeptical; he is typically persuasive.  Often I end up rolling my eyes at his ideas, virtually speaking.  Still, I sort of miss it.  Maybe now that he has more time on his hands, I’ll get another midnight message.  Maybe he’ll have another hare-brained scheme percolating in his brain.  If so, I’ll be honored that he chose to share it with me.

Working Man's Lament

There is a bit of “grass is always greener” going on in today’s post, I’ll warn you.  Of course, for someone who believes in balance and paradox, this is perhaps not surprising.  In any given situation where you’re trying to decide “which one is better?”, the answer is almost always: both.  Everything in life has both advantages and disadvantages, so any given binary choice is going to have you weighing pros and cons.  If you’re lucky, it’s easy to see which side outweighs the other.  Generally, you’re not lucky.

For instance, I went to college in two different spurts, with a gap of about 3 years in between.  What I usually tell people by way of explanation of this is that I dropped out of college, because college sucked, and went to work in the real world.  Then I went back to college because the real world sucked even more.  But of course the truth is that both sucked.  And both were awesome.  Just differently, and in different ways, and at different times.  The first time I went to college, I wasn’t prepared to appreciate how cool college can be.  Having to hold down a real job certainly made me appreciate that a lot more.  On the other hand, the first time I had to hold down a real job, I definitely wasn’t prepared to appreciate the freedom in it, the satisfaction that comes with responsibility.  After 3 more years of college, I was much better prepared.

Now I’m going to back to full-time work after a six week sabbatical.  I’ll be honest: I’m having a bit of trouble adjusting.  I’ve been working full-time for a lot of years now—decades, in fact—and I never thought that I’d be interested in retirement.  I always figured I’d be that guy that worked so long he was retired forcibly.  Now, though ... now I think I see the attraction.

My working life has had its interruptions too.  I spent 3 years in between college and college (as I mention above) working on jobs from furnace cleaer up to C programmer.  Then, while I was in school (the second time), I went back to part-time work, but eventually fell in with some guys who made me a business partner.  Which worked for a while, until it didn’t.

After I graduated, I felt ready to take the step of starting my own business.  I wasn’t too keen on lots of aspects of it (I had seen first-hand the effects of the stress on my partners), but I was also ready to be in charge of my own business fate for a change.  I ran my own company for 14 years, with anywhere from zero to 15 employees (or subcontractors), most of whom were (naturally enough) other programmers, but also project managers, bookkeepers, graphics artists, sys admins, salesmen, and office handymen.  I met The Mother while running my own business.  I hired nearly every one of my friends at one point or other (including The Mother, who was our bookkeeper and office manager for many moons), or at least put them on the Board of Directors.  Our biggest sales year was three-quarters of a million dollars, which doesn’t seem like much to many of the business folks I know, but, for a company that never accepted a dime of venture capital, it was plenty impressive to us.

Then I went back to working for other folks.  My current job is the second I’ve had since those days.  And, right now, I won’t lie: I’m starting to miss the freedom I had when I ran my own shop.  Constantly working for someone else can sometimes make you feel like you’re working hard to make other people rich.  Plus it’s twice as frustrating when they won’t even listen to you on how to get rich.

But of course being the boss was no picnic either.  Feeling that responsibility for everyone’s livelihood is pretty scary.  There’s the simultaneous pressure to do things yourself to make sure they get done right, and the pressure to teach other people how to do things so there’s a backup, and the pressure to learn how to delegate simply to keep your sanity intact.  There’s never anyone to go to to ask what to do next: everyone comes to you and expects you to have that answer.  You work harder than everyone else, you put in longer hours, and you often pay yourself less (at least I did).  Moreover, you expect more from yourself than you do from everyone else, and everyone else returns the favor by expecting more from you too.  It can be very stressful, which impacts not only your mental health but your physical health as well.

And, then again, there are certainly a lot of upsides.  I don’t mind failing.  What I can’t stand is being forced to fail.  When you work for someone else, particularly in the world of publicly-owned corporations, you end up doing a lot of things you know are not going to work.  You tell people they’re not going to work.  You send emails and hold meetings and write reports explaining that they’re not going to work.  Then your boss makes you do them anyway.^*  Then they don’t work.  And what satisfaction is it to say “I told you so” when the answer is “yep, you were right; now go clean up the mess.”  At least when you work for yourself, your mistakes are honest, your own, and you can do your damnedest to make sure you only ever make them once.  Not that you always succeed at that, of course.  But then, if you fail, you have only yourself to blame.  And I’ve always felt that that was cleaner, somehow.  I personally never got hung up blaming myself.  I give myself permission to make mistakes.  But when I have to blame someone else because there was nothing I could do about it, that feeling of helplessness makes me a little crazy.

So neither position—being the boss or being the worker bee—is perfect.  They both have their good days and bad days.  Perhaps one day I’ll go back to running my own business.  And perhaps, after that, I’ll go back to working for someone else again.  No reason I have to stick with only one or the other the rest of my life.  I suppose I’ll probably complain either way, some days.  But I also try to look at the bright side, whenever I can.  Right now, I’m working for a company owned by a company owned by another company.  I have five levels of bosses from three different companies, and that’s just counting the ones who are in the same building as I am.  There’s more floating around in other buildings, in other cities.  But, you know what?  They’re in charge.  All the responsibility and all the stress is on them.  And I’m happy enough with that.

For now.


* This is not to imply anything negative about my boss, who is an awesome guy and generally doesn’t do that sort of thing to me.  But sometimes these types of things just come down from above.

Sabbatical Report: New Year's

Welcome to Sabbatical Report #8; for explanations, you may want to read Sabbatical Report 1.

Moving on from Christmas to New Year’s.  This year we went to celebrate with our Sister Family.  They have a cool idea about how to deal with celebrating New Year’s in California with small children: you just celebrate East Coast New Year’s.  So, at 9pm, we had some champagne and sparkling cider and then went outside and made lots of noise and then, for the most part, went home and went to bed.  Except we watched Looper first, which was fairly awesome.  Joseph Gordon-Levitt is starting to become one of my favorite actors, and this is his second pairing with writer/director Rian Johnson, after the insanely good Brick.  But I digress.

I also returned to work, which was sort of anti-climactic after six weeks of sabbatical.  Other than that, all we did family-wise was a half day at Magic Mountain (where our middle child rode his first roller coaster with a loop in it) and a Heroscape game day, which we actually just returned from.  The two boys and I, plus the elder son of our Sister Family, enjoyed a fine day of killing each other via plastic soldier proxies, while the womenfolk stayed home and had a relaxing testosterone-free day.

My final numbers for sabbatical goals (see Sabbatical Report 3 if you don’t know what I’m talking about):  I’m declaring my todo tasks a failure, with only 15 out of 25 expunged.  However, I cleaned 455 (out of 500) emails out of my Inbox, and I think that’s plenty good enough, and, for project hours, I hit my goal exactly: 75 hours on personal projects, many of which I made excellent progress on.  So I’m pretty jazzed about that.

Well, this is the last of the sabbatical reports, so next week we’ll be back to normal posts.  Which of course you should continue not to read.  But apparently my warnings are going unheeded, so I suppose I’ll see you in seven days.