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.

Sabbatical Report: Christmas

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

This was Christmas week, which is our year-end holiday of choice, so most of our week was focussed on that.  Christmas Eve is our big dinner night, and we had planned to visit our Sister Family on Christmas afternoon, but various and sundry children with various and sundry germs put the kibosh on that plan.  Still, Christmas was very lovely, even with the tiny amount of sleep I got the night before, and now our house is trashed, so it must have been successful.

On to my sabbatical goals (which are described in Sabbatical Report 3).  As they say on Marketplace, first let’s do the numbers.  So far, I’ve expunged 453 emails out of 500, I’ve expunged 15 todo tasks out of 25, and I’ve completed 69 project hours out of 75.  Now, this is the last full week of my sabbatical, so it may seem that I’ve failed, but let’s not forget that I don’t actually go back to work unitl Wednesday, so there’s some time yet.  Let’s look at the individual goals.

Currently I have 47 emails in my inbox, which fits on a single screen without having to page.  That’s pretty impressive, and, while I will probably try to whittle it down even further, I’m happy enough to declare that one a success even as is.

In terms of the todo tasks, I will probably knock a couple of others off before sabbatical is fully over, but it’s true that I have little hope of doing 10 more.  So I have to declare that one a bust.

Of course, the project hours is really the big one, and there’s only 6 more to go to reach my (adjusted) goal.  I’m feeling pretty confident about hitting that one, actually.  Even though there’s still a few projects that I never even got to start.

New projects I worked on were polishing up my Debuggit module (one new release done, one to go), finally finally getting around to using Dist::Zilla by creating my own plugin bundle (first, very primitive release done, several to go), and starting my super-long-term project, which I won’t reveal just yet, as it’s still very early days on that one.

So all is not lost ... no, all is not lost ... not yet.  Next week, me and my precognitive dissonance will visit: New Year’s Day.

Sabbatical Report: Catching Up

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

Family stuff has been fairly light this week.  We put up our Christmas tree, went out to eat at Souplantation, and went to see a movie.  We were going to do more stuff, but it was cold and rainy all week, and we just wanted to chill out at home.

Which gave me time to catch up on my other goals (my sabbatical goals are described in Sabbatical Report 3).  In terms of raw numbers, I’ve expunged 352 emails (instead of 400; a very slight drop from last week), I’ve expunged 12 todo tasks (instead of 20; a major improvment over last week), and I’ve completed 52 project hours (instead of 60), which is very good progress.  I actually completely finished 3 entire projects, which is the first I’ve been able to knock out since the half week way back at the beginning of sabbatical.

First, I identified and backed up all the files I have on this crappy laptop that I haven’t yet managed to migrate to the cloud.  Then, I finally got all my common scripts and config files checked into GitHub.  Finally, I actually purchased a new Linux laptop.  After going back and forth for quite a bit between ZaReason and System76, I finally went with the ZaReason Alto.  System76 is a great company with a lot of fans, but the support at ZaReason is supposedly amazing, plus I like that they’ll give me a choice of many different Linux distros, as opposed to being stuck with Ubuntu.  I’m going with Linux Mint, which is based on Ubuntu, but apparently has fixed most of the stuff that annoyed me about Ubuntu, and delivers the promise of “it just works” that Ubuntu never did, at least for me.

I also put in quite a lot of work on Method::Signatures, and got this close to making another new release.  I have one last problem on older Perls that I’m consulting with the Damian on.  Once I knock that out, that’s all the catching up on that module I wanted to do over sabbatical anyway, so I’ll mark that one done as well.

So that wraps it up for this week.  Next week: Christmas!

Sabbatical Report: Cabin Week

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

As I mentioned last week, we spent this week at  Lake Cachuma, which is a county park north of Santa Barbara.  We went up Sunday night and came back Thursday afternoon.  While there, we stayed in a cabin with a fairly awesome view of the lake, although it was pretty chilly the whole time.

The cabin itself was nothing special: just one long space, divided into thirds.  The back third was a bedroom, the middle third was a bathroom on one side and two bunk beds on the other, the front third was a kitchen, a dining room table, and a couch that folded out into a bed.  Microwave, refrigerator, and stove, but no oven—no toaster, either, which was mildly annoying.  But there was a TV with a DVD player, a satellite dish that worked sometimes, and we set up our phones as mobile hotspots so everyone could use their laptops.  It was sufficient.

Monday we tried to go up to the Nature Center, but it was closed.  Went to the general store and bought some touristy crap.  Mostly we laid around.

Tuesday we went into Solvang, primarily to check out the Solvang Bakery, which everyone says is awesome (it’s pretty decent).  Other than that, it’s mainly a place to go shopping for crap that you didn’t really need anyway.  My eldest bought a hat, as did my youngest (although she had little say in the matter, being yet unable to speak English).  We also went to a nifty little New Agey shop where the Larger Animal bought a tiny little Buddha and I bought a “Lucky Horse” (my Chinese zodiac sign).  And we had some tacos that were decent but not overwhelmingly awesome.

Wednesday we finally did make it up to the Nature Center, where we saw lots of animals (stuffed, like by a taxidermist as opposed to a toymaker), and rocks, and bones, and some baby trout, and various and sundry other stuff.

Thursday we spent two hours trying to kill each other packing the truck, then an hour waiting for AAA to come jumpstart the battery that we’d drained while leaving all the doors open while packing.  The drive back was mostly uneventful.

Friday was recover-from-being-on-vacation day.

In terms of my sabbatical goals (refresh yourself on those by rereading Sabbatical Report 3), I’m behind across the board, but that’s mainly because I spent most of my free time at the cabin reading the latest installment of the Dresden Files.  But I finished that already (500 pages in 2.5 days!), so perhaps I’ll get caught up next week.  I’ve expunged 260 emails (instead of 300), I’ve expunged 5 todo tasks (instead of 15), and I’ve completed 31.5 project hours (instead of 45).  Still reasonable to catch up, I think, on everything except maybe the todo tasks, which is looking a bit bleak.

That’s all for this week.  Next week I’ll be doing more chilling at home, with perhaps a few day trips thrown in (I believe La Brea is on the schedule at some point).

Sabbatical Report: Lazy Week

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

Just a quick update this week, as I still have several things to do before we leave tomorrow for Lake Cachuma.

First of all, last week I outlined my recurring personal goals during sabbatical.  Quick refresher: 100 emails cleared out of my inbox per week, 5 tasks permanently removed from my todo list per week, and 20 hours working on personal projects per week.  Well, this week I realized that 20 hours per week was just too ambitious.  So I’ve downgraded to 15 hours per week.  Roughly half as much time as I would spend on $work.  That’s still reasonable, right?

So where are at the end of week 2?  Well, I’ve expunged 202 emails, so I’m still a little ahead of schedule on that one.  I’ve still only managed to remove 4 todo tasks (yes, yes: exactly the same as last week), so I’m less than halfway there on that one.  I’m behind on projects too, even with my revised goal: only 22.5 hours out of 30, so about three-quarters of the way for that one.

In terms of project accomplishments, I’ve moved a bit farther along on identifying any files I may need to get off this laptop.  I’ve also started on (just barely, in most cases) 4 new projects.

First, I’m planning to check all my configuration files into a GitHub repository.  I’ve been carrying around my Linux config files and personal scripts and all that sort of stuff for years using Unison.  Then I switched to Dropbox, but still use Unison occasionally for places (mainly at work) where sysadmins don’t care for Dropbox’s constant pinging out to the Internet.  Now, of course, all the rage is just to check all that stuff into GitHub and then check it out on each new machine.  Since I already have a system to get what I want onto new boxes, I don’t care much about the convenience aspect of it.  But creating a config repo also gets you versioning, so you can check what changes you’ve made over time, which is nice.  Still wouldn’t be enough to push me to make the switch, but the really nice thing about using GitHub is it makes it easy to share your personal scripts with your friends.  That’s what finally decided me.  So now I’m working on cleaning up my config stuff: paring it down, removing anything I don’t have permission to share, making sure I didn’t leave any personal info (like passwords) in the files, etc.

Next is working on my custom Heroscape figures rebasing.  I’ve talked about our C3V work before, and I mentioned that we take figures from other games and reuse them as Heroscape figures.  Some of those other figures have bases that are very similar to Heroscape bases.  And some have bases that are very not.  Those latter have to be cut off their old bases and glued onto new ones.  So far, I’ve purchased the new bases, organized all the figures to get them ready for rebasing, and located all my supplies.  Except I seem to have lost or destroyed my utility knife.  So I need to get one of those.  But I’ve still actually managed to get two figs rebased, including the quite awesome dragon Quahon.

Next up, I made a suggestion to the author of Pod::WikiDoc on some alternate syntax.  I want to start using this awesome module for documenting my own modules—I personally find POD unberably ugly—but I always hate retraining my fingers.  Besides underscore-surrounded words just look like italics to me now.  (Tildes? not so much.)  I’ve forked the repo, cloned it, and started staring at the source in order to figure out the best way to make the alternate syntax work.  This includes brushing up on my Parse::RecDescent skills, which have never been more than neotenous.

Finally, I’ve started doing the background research for choosing a Linux laptop.  I know that Mac Airbooks are all the geek rage these days—the prices aren’t as shockingly out of reach (still a bit shocking), and Mac OSX is based on a version of Unix, and you certainly can’t say it doesn’t just work right out the box—but I’m a keyboard person at heart.  I use the mouse mainly when I’m forced to.  And I had a Mac laptop for a while, and it forces you to a lot.  Like, a whole lot.  Drove me absolutely insane.  Just simple stuff like selecting words without the mouse I found impossible (or so close to it to be not worth making the fine distinction).  Maybe it’s better these days.  Maybe I don’t want to spend the time or effort to find out.  I do want a laptop that just plain works, sure: but Linux has come a long way.  The desktop versions pretty much do work straight out of the box.  The laptops are just lagging behind.  So I’m probably going to end up paying about twice what I would for a Windows laptop that I would strip down and Linux-ize myself, but not the three times as much that a Mac would cost me, which I couldn’t strip down if I wanted to.  I’ve spent many many hours installing / configuring / maintaining Linux on my own.  I’m ready to pay a little extra for the privelege of having someone else deal with it.  So I’ve started the research, and right now I’m leaning towards ZaReason.  Partly because they’ve got some great machines, but partly because they’ll put something other than Ubuntu on it, which I hate.  I’ve tried many many versions of Linux throughout the years—Slackware, Debian, RedHat, Mandrake, Gentoo, Ubuntu, Fedora, and Mandriva, that I can remember—and Ubuntu is close to the botom of that list.  Many people like it, I presume because it’s very “Microsofty” (that is, it’s convinced it knows what you want better than you do).  I, of course, hate it for that very reason.  But I’m really getting disgusted with Fedora these days too.  The incessant need to jam Gnome 3 down my throat, the ridiculously short support windows, and of course the install program snafu that cost me several gigabytes of data that I’m still trying to recover over four years later.  So I’m leaning towards trying out a new option: Linux Mint.  I’m particularly excited to explore the differences between MATE and Cinnamon, and the ease of switching back and forth between the two sounds heavenly.  Anyway, that’s where I’m leaning at the moment.  But I’m still going to do some more research.

So that’s it for my personal goals.  Moving onto the family time for this week.

Monday we were going to go to the National History Museum, but it was rainy and cold, so we decided to do some Christmas shopping instead.  Typically we do the bulk of the Christmas shopping online so we don’t have to deal with any crowds.  But we figured, pre-Christmas-break, on a weekday, in the middle of the day, at our local Town Center strip mall instead of a major indoor mall, we’d probably be okay.  Which we were, other than the persistent danger of freezing to death.  We bought some Christmas candy, went to The Mother‘s favorite jewelry store, ate hot dogs on a stick,^* and hung out with some old fat dude who dresses funny.^**

Wednesday we were supposed to go see the Christmas lights in Griffith Park, but again that didn’t happen.  We were just being majorly lazy this week.

Friday we did a homeschool field trip to the Getty Villa.  They’re having a Pompeii exhibit.  Want to know what I learned at the Getty Villa?

1. There were lots of naked women at Pompeii.
2. There were a few naked men too.  But mostly naked women.
3. Hercules was so cool that everything he did was immortalized.  This includes taking a piss.
4. The only piece of art at the Getty Villa that you’re actually allowed to touch is a marble statue of a naked woman.  Seriously, guys: my teenage boy does not need the encouragement.

So that was fun.

And that about wraps it up for this week.  Next week, as I said up top, we’re off to a cabin by the lake.  Which hopefully is quite different from a cabin in the woods.


* Honestly, only the Smaller Animal had hot dogs on a stick.  But we all had the fries, and dug the cherry lemonade.  Yum.

** Note: If you’re not friends with me on Facebook, that picture may not load for you.  But, then again, if you’re not friends with me on Facebook, why do you want to see pictures of my family anyway?  Don’t be pervy, man.

Sabbatical Report: Goals

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

This week I concentrated on nailing down what I want to accomplish on my sabbatical.  Of course, I want to spend some extra time with my family, and do a few touristy things, as I mentioned in the original sabbatical report (see above).  But I also want to work on some personal projects, and I thought it wise to give myself some concrete goals.  Otherwise I’ll sit on my ass for 6 weeks and accomplish nothing except watching a lot of TV and eating a lot of holiday candy, and I’ll feel stupid and lazy (and fat) when my sabbatical is finally over.  So I decided to give myself goals.  And I’ve been fiddling with them, trying to get them to a point where they’re achievable, but not too easy.  I think I’m there finally.

First thing I did was give myself a little padding at either end.  My sabbatical is six weeks long in the sense that it’s 42 days, but it’s not actually six calendar weeks, because it started on a Wednesday.  So it’s really like half a week, then 5 weeks, then another half a week.  I decided that my goals would be applied during the 5 week stint.  The half weeks on either side would just be used to ease into it, and then to ease back out of it.

So, during the 5 weeks (of which this week was the first), I’ve decided to accomplish 3 broad goals.  I’ll explain them, from simplest to most complicated.

First, I’ve decided to finally clear out my (personal) inbox.  I got my Gmail account about 8 years ago, mainly as a backup account.  I still had my own business back then.  But, as time went on, and my company’s servers gradually stopped working, my Gmail “backup” became my main email account.  By the time I realized this, though, my inbox was already a mess, and it hasn’t gotten any better since then.  Oh, I read my emails (well, most of them), but I never seem to actually do anything with them.  I need to file them, or delete them, or maybe even reply to them every now and again.  When I looked at my inbox at the beginning of my sabbatical, there were nearly 500 emails in my inbox.  Fine: 500 emails, 5 weeks—all I need to do is clear out 100 emails a week and I’ll start back to work with a clean inbox.  I’m happy to say I’m currently on track (ahead of schedule, even) with this goal: my inbox right now stands at 352.

Secondly, I have a todo list.  There are two sorts of items on this todo list: things that need to be done once and then can be deleted permanently, and recurring tasks.  My recurring tasks, of course, never actually leave the todo list.  They float to the top sometimes, I do them, then I punt them back to the bottom until it’s time to do them again.  These are things like doing my laundry, fishtank maintenance, grocery shopping, etc.  But the one-time tasks are the more interesting ones.  I do the recurring ones—every week, or every month, or whatever—but I do them.  They never get passed over.  But those one-time tasks ... they just sit there a lot of the time.  Over time, they accumulate.  Before you know it, you’ve got stuff on your todo list you’ve been meaning to accomplish for a year and never touched.  It makes you feel sort of lame.  So I decided I would take advantage of sabbatical time to prune that list a little.  I figured, I’ll do 1 task every day.  Then I decided to make it 1 task every weekday—save the weekends for the recurring tasks, and maybe some chilling out time.  5 weeks, that’s 25 tasks, which must all be one-time tasks, and they must all have been on the list when sabbatical started—no cheating by adding new one-time tasks and then doing them, because that doesn’t actually help achieve the goal of shrinking the overall list.  So this week I should have accomplished 5 tasks, but so far I’ve only got 3.  Maybe I’ll sneak in 2 more before tomorrow.

Finally, the big stuff.  Over a month ago, I started making a list of bigger projects I wanted to accomplish during sabbatical.  Some were short, well-defined tasks, like pulling out my old mountain bike and taking it to a bike shop (which necessitates actually locating a bike shop, of course) and either having it fixed, or having it pronounced dead and buying a new one.  I might actually exercise if I had a working bike.  (I probably won’t, but we’ll never know unless we try, no?)  Others were more nebulous, like working on my book, which could go on for quite a while and never see completion.  So the trick here was to figure out how to turn these larger projects, with all sorts of different lengths and levels of achievability, into concrete goals.

My original thought was to just try to polish off X projects a week.  There were several problems with this plan.  First off, some of them didn’t have definitive endings, as I mentioned.  But, worse: I had so many that I would need to polish off one every day to get them all, and that wasn’t even remotely practical.  Plus I’d need to start one, work on it frantically, and take it all the way to completion before I could mark it off and move on to the next task.  That’s too much like work, which is what I taking the sabbatical to get away from.  I need to be able to hop around from task to task, doing whatever mood strikes me, but still working towards concrete goals.  On top of everything, the fact that some tasks would take only a few hours, while others might go on for days, meant that I would have no idea how to make sure I was on track for hitting my targets.

So I hit on the idea of counting my hours.  When I work on work stuff, I track my hours.  (This comes from many years of being a consultant who gets paid by the hour.)  I know that, in a 40-hour work week, I generally achieve about 30 hours of real, solid work.  I briefly considered trying to do 30 hours per week on sabbatical.  I promptly discarded this idea.  What’s the point of being on sabbatical if you can’t slack off a little?  But not too much ... I’m currently trying to achieve 20 hours per week instead.  Of course, so far I’ve only got twelve, so that’s a poor start.  But, hey, I’ve actually achieved a few cool things.

First off, I just released a new version of one of my CPAN modules, Method::Signatures.  This involved fixing a few niggling bugs and just getting things organized and properly put out on the Internet.  I really love making progress on this particular module, because it’s probably the most high-profile thing I’m known for (even though I didn’t write the original version), and I hope to expand on it even more as time goes on.  I don’t know if I’ll ever actually have a Perl legacy, but, if I ever do, this will probably be the cornerstone of it.  If you’re into Perl, you can read more about this latest release on my other blog.

Secondly, I figured out how to make a “lab” (i.e. a personal page for my custom creations) on my favorite Pathfinder site, d20pfsrd.com.  So far it’s just an empty page, but you’d be surprised how much effort it took to get even that far.  Google Sites may be an awesome thing (not saying it is yet, only that it may be), but intuitive it ain’t.

Finally, I started working on the project of identifying all local file modifications to my laptop.  This is necessary for upgrading to a newer laptop, which is another project on the list.  So far, I’ve got a list of directories, sorted in order by the modification date of the most recently modified file, with the obvious stuff (like the /tmp directory, or my Dropbox directory, which is already on the cloud and thus doesn’t need to be backed up) removed.

So I’m 8 hours short, but I’m not feeling lame.  Yet.  I may have to revise my weekly goals to 15 hours though.  We’ll see.

Anyway, I have to wrap this up now, as we’re out to pick up yet yet another furry child.  Should keep the holidays interesting ...

Sabbatical Report: Thanksgiving

I really should have time to do a real post this week, but I’m lazy.  Sabbatical-type lazy.  So welcome to Sabbatical Report #2.  If you want to know what the fuck I’m talking about here, you may want to read Sabbatical Report 1.

So, I’ve been on sabbatical for half a week so far, and I haven’t done much.  Mainly I’m trying to catch up on all my C3V work that I let slack while I was putting in so many hours at work, getting ready for sabbatical.  I’m one unit away from being completely caught up on my editing duties.

Thanksgiving was in there too.  We decided to forego the turkey this year ... it seems like every year, we all get excited about the mashed potatoes, and the deviled eggs, and the onion casserole, and cranberry sauce, and we eat some turkey out of some weird sense of duty, and then we’re stuck with turkey leftovers for 3 weeks and we’re sick of it the whole time.  So, you know: screw the turkey.  We’ll just have the other stuff.  So we did.

Mainly what I was thankful for this year was sabbatical.  That may very well keep me sane.  Many of us were thankful for our newest family member.  And also for our sister family (who I still need to write a blog about someday).  And various and sundry other things.

Other than that, I’ve mostly just hung around the house.  It’s been nice to be able to stay up as late as I like, sleep as late as I like.  And I sleep pretty late under normal circumstances.  So, not a lot of interesting stuff to report, over all.

Next week may be a little more exciting.  Or not.  Either way, I’ll be enjoying it.

Sabbatical Report: SeaWorld Snow Days

Hello, and welcome to Sabbatical Report #1.  When you work for eBay, after 5 years you get a sabbatical, which is 4 weeks off that you have to take all at once.  It’s a way to sort of reset your life, take a well-deserved break from work, and generally chill out.  Next Wednesday, I’ll start my sabbatical.

Of course, I don’t work for eBay, so that’s sort of weird.  I did work for eBay, or at least a subsidiary of eBay (what they call an “adjacency,” for some reason).  But we got sold ... about two months before my 5 year anniversary.  Happily, though, one of the conditions of the sale was that anyone who would qualify for their sabbatical before the end of the year would still get to take it.  (If you didn’t qualify until next year, you just got screwed.)  There were several of us in that boat, including some folks who started after me.  But they all took their sabbaticals already.  I am, in fact, taking the very last sabbatical my company will likely ever give out.

The other thing about sabbaticals is that you try to take them at a time when you can stretch things out.  I decided to take mine right at the end of the year primarily for the reason that there are six paid holidays in there.  Toss in 4 vacation days, and all of sudden that 4 weeks becomes 6.  Pretty smart, eh?

Also, there are a bunch of high-profile projects due at the end of the year, and I don’t feel like dealing with the pressure.

Anyway, during the next 6 weeks, I will be mostly chilling out at home, working on some personal projects, but also doing various and sundry touristy things in the Southern California area.  There will be times when I don’t have time to do a proper blog post, and, on those occasions, I’ll just post something about where we’ve gone and what we saw there.

So this is the first of the Sabbatical Reports.  It’s coming actually before my sabbatical has even started because we had planned to go to SeaWorld during sabbatical, but then we found out that this past Friday was the first day of SeaWorld’s “snow days”, and they reserve that day for season pass holders (which we are, this year).  So we started sabbatical a bit early.

We decided to invite one of the kids from our sister family (p’raps one day I’ll write a blog post about them), so we were six strong heading down to San Diego on Thursday afternoon.  The Mother drove and I worked the whole way down (got a lot of stuff to do before heading out on sabbatical, don’cha know).  We got a decent deal at a Comfort Inn (the picture there looks much nicer than the reality, but it was okay).  We got a suite—there’s just too many of us for a single room these days, especially with one extra kid.

We got in in time to spend a little time in the pool area.  My middle child “fell” into the jacuzzi.  Then we put our bathing suits and got in on purpose.

Next morning we took our time getting up and getting ready.  The park was open until 5pm for everyone, then 5pm - 10pm was for passholders only: there was a special gift for us (turned out to be a manta ray Christmas tree ornament) and fireworks just before park closing.  So no need to rush.

We got there around noon, which means we were walking around the park for about ten hours, minus breaks for food and shows.  We got the all-day-eating thingy so we wouldn’t have to stress about how much food we were getting.  Plus for dinner we got cookies and hot chocolate for free (more season pass holder goodies).  Of course, none of the food was particularly good, but that’s to be expected for amusement park food.

Show-wise, we saw the Christmas version of the Shamu show, which was a lot cheesier than the regular Shamu show (and that’s saying something).  Lots of oozing religiosity and seasonal warmth.  Whatever.  And we saw the Polar Express 4D show, which means we saw a really abridged version of the movie and they shot bubbles at us so it looked like snow.  Nothing to write home about (although here I am writing blog about it, so what do I know?).

We didn’t really didn’t do too many rides.  We rode up in the tower, and the kids did the Riptide Rescue.  Oh, and the Wild Arctic fake helicopter ride thingy.  Mostly we did animals.  The kids fed the sea lions, we all touched the bat rays, we watched the penguins and the polar bears and the beluga whales and the fish and snakes and frogs.  We saw a lady with a tarantua on her hand, a guy with a hawk on his arm, and two women with a beaver on a leash, who came up and sniffed our toes.  Plus the standard dolphins and orcas.

And of course there was the snow, that being the point of “Snow Days.”  There was a small, roped-off area where a snow machine was making honest-to-goodness snow.  The kids made snowballs to throw at each other, made a (very small) snowman, and, most importantly, got to sled down a little hill.  Not much of a hill, mind you, but considering we’re less than 20 miles from Mexico, any sledding at all is pretty impressive.

Add a few overpriced stuffed animals to the haul, and some decent fireworks right at the end, and you’ve pretty much got our entire day.  We were thinking about doing the zoo yesterday, but we decided we were all too tired.  Well, except for my middle child.  He could have kept on going for days, I’m sure.

And that was our first sabbatical trip, before sabbatical even starts.  Hope you enjoyed this brief recap.

Dresden Again

Allow me to preface today’s post with a caveat:  It was never my intention to turn this blog into a drooling Harry Dresden fanboy site.  Seriously.

But good God damn.

The last time I talked about the Dresden Files (an urban fantasy series by Jim Butcher), I mentioned that it had gone from being good to really, really good.  That was along about book 7 or 8.  I am now on book 13, and it is no longer really, really good.

It is fucking insanely awesome.

Now, last time I tried to express just why it was so awesome, I theorized it was because of its perfect balance between episodic adventures and an overarching story arc.  And, it’s true: there’s something indescribably delicious about the way it sucks you in with a monster-of-the-week premise until you’re almost surprised to realize you’re hip deep in mythic quest territory.  But I’ve recently realized there’s another element going on here.

I’m a lot like Harry Dresden.

I mean, Harry is generally relatable: he has an affable, everyman quality that makes him instantly likeable, and I’m sure a lot of people will see themselves (or at least bits of themselves) in Harry.  But, for me, it seems to go beyond that.

I first noticed it when Harry was dealing with the White Council in one of the later books.  The White Council, of course, is the organization of wizards to which Harry belongs.  Harry hates dealing with them, because it’s all politics.  Harry hates politics.  I do too.  Harry deals with politics much the same way I do: he’s blunt, he’s abrasive, he bulls his way through, knocking over with main force what he can’t deal with via subtlety.  Yet, as the series progresses, Harry actually gets better at politics, almost by accident.  He still hates it, and he’s still not particularly skilled at it, but he manages to get by, and even score a few points now and again.  I feel much the same way at work: I still avoid the politics, and bulldoze it where I can, but every now and again, just from having survived this long, I manage to score a point here or there.  Just like Harry.

And, once I started to see similarities between myself and Dresden, I couldn’t stop seeing them.  Harry is a wiseass: if you’re familiar with psychic detective Shawn Spencer, you’ll recognize Harry’s tendency towards inanity in the face of danger or authority.  (Harry’s not quite as off-putting as Shawn, but close.)  Harry has a wacky sense of humor, but he also has a lot of pent up anger.  He has an overblown sense of injustice, which is often the trigger for his anger.  He has an insouciant sense of fatalism which leads many of his friends to think of him as cynical, yet at heart he’s a hopeless romantic.  He’s passionate about certain things, and careless about others.  His friends think he’s stubborn, but he doesn’t view himself that way.  He’s desperately loyal to those friends, protective of them, would do anything for them.  Little things bug him; big things roll off his back.  When he says “Oh, come on!  How is that fair??” ... I hear myself.

Harry doesn’t always think of himself as a good man, and yet he always tries to do the right thing.  He knows he has faults, and mostly he’s comfortable with them.  He knows he can be loud, and that he can get on people’s nerves, but he’s pretty much a love-me-or-leave-me guy, so that doesn’t bother him.  He’s direct, and he’s honest, and he has a great deal of talent at one particular thing, which makes him respected by some and laughable to others.  I’m not a professional wizard, obviously, but, as a professional programmer for over half my life, I have experience with being a geek in both positive and negative senses of the word.

Of course, the coolest thing about reading the adventures of someone who’s a lot like you is the parts where he’s not like you.  I am not, as I mentioned, a professional wizard, nor a private investigator, nor do I hang out with vampires, werewolves, holy knights, and various stripes of wild fae.  Harry Dresden’s personality may be close to mine, but his life is far more exciting, which is good, because who would want to read about my boring-ass life?  Harry’s life is anything but boring.  Harry’s life is not always fun for Harry, but it will keep you on the edge of your seat.

Check it out.  You’ll be glad you did.

Recommended Reading Order

Hopefully I’ve convinced you to at least check out this great series.  If you really get into it, you may want to know what order to read things in, and I’m going to help you out.

For the most part, this is a no-brainer.  There are 13 novels in the series, and the 14th is due out later this month.  The publication order matches the chronological order within the fictional world, so you just read them in the order they came out and you’re golden.  The only monkey wrench is Side Jobs.

Side Jobs is a collection of short stories and novellas set in the Dresden Files universe.  Each one contains a short introduction and a blurb telling you where it fits, chronologically.  If you like, you can read it at the point where I read it:

Simple Reading Order:

Read Side Jobs between Changes and Ghost Story.  Do not read it earlier, because the last story in it (“Aftermath”) contains major spoilers for Changes, and don’t read it later, because I think “Aftermath” really gives an important context to Ghost Story (not to mention the useful background info you get from “A Restoration of Faith”).

Or, you could alternately try:

More Complex Reading Order:

It might make more sense to read the stories in the order in which they fall in between the books.  This works very well for almost all of them, in fact; the only problem is “A Restoration of Faith.”  Chronologically, it’s first (before Storm Front, even).  But I think it works much better as a flashback than as an introduction.  Reading it first would be like trying to read New Spring before the remainder of the Wheel of Time books, or trying to watch In the Beginning before the first season of Babylon 5 (both of which I’ve tried).  It just doesn’t work.  There’s too much going on that only makes sense when you’re looking back on it with some perspective.

On the other hand, the rest of the stories are just the opposite: they give context to the books that follow (or at least some of them do).  Certainly I know that if I’d read “Heorot” before reading Changes, a couple of things would have made a lot more sense (for just one example).

So, in the order below, I’ve chosen a good place to drop in “A Restoration of Faith,” and I’ve left the others where they naturally fall.  So this is mostly nothing you couldn’t have figured out for yourself, but hopefully this saves you the hassle of working it all out.  Enjoy.

• Storm Front
• Fool Moon
• Grave Peril
• Summer Knight
• “A Restoration of Faith” (from Side Jobs)
• Death Masks
• “Vignette” (from Side Jobs)
• Blood Rites
• Dead Beat
• “Something Borrowed” (from Side Jobs)
• Proven Guilty
• White Night
• “It’s My Birthday, Too” (from Side Jobs)
• “Heorot” (from Side Jobs)
• Small Favor
• “Day Off” (from Side Jobs)
• “Backup” (from Side Jobs)
• “The Warrior” (from Side Jobs)
• “Last Call” (from Side Jobs)
• Turn Coat
• “Love Hurts” (from Side Jobs)
• Changes
• “Aftermath” (from Side Jobs)
• Ghost Story
• Cold Days