Technical Debt Strategies

For a new role I’m starting at work, I’ve been thinking about the concept that we in the software development business refer to as “techincal debt.”

In software development, there is always a tension between two opposing forces: the desire to do it fast, and the desire to do it right.  I could probably write an entire blog post on just that topic, but for now I’ll settle for the short version.  If you do it right, then, later, when you want to extend it, or modify it, or use it as a jumping off point for branching out in a whole new direction (and you will always want to do these things eventually, if your software lives long enough), you can do so easily, with a solid foundation as a base.  The downside is that it will take longer.  If you do it fast, you get results faster, which means you can serve a customer’s needs before they change, fill a window of opportunity before it closes, or perhaps even beat your competitors to the market with your offering.  But when you have to modify it later (which you will), it will end up taking even more time to clean things up than if you’d just done it right in the first place.

You can see why we often call this “technical debt.”  You’re saving time now, but you’ll have to “pay it back” later, and the amount of extra time it takes is like the interest.  Primarily, we software people invented this analogy because it makes good sense to business people.  When you’re running a business, sometimes you need a piece of equipment.  You have two choices: you can borrow some money and buy it now, or you can save up and purchase it outright, later.  Buying it now allows you use it now, thus saving you costs somewhere else or giving you new capabilities you can capitalize on.  But you’re going to have to pay for it eventually, and you’ll have to pay the interest too.  Buying it later saves money in the long run, but denies you the advantages of the equipment for however long it takes to save up enough money.

This analogy really works because, despite what some people tend to believe, neither choice is always right or always wrong.  Sometimes it makes sense to borrow the money and buy it now; sometimes it makes sense to wait.  Likewise with software, sometimes it makes sense to just get the damn thing programmed as quickly as possible, and sometimes it makes sense to take the time and do it right the first time.  And business people have to make that call, and expressing the choice in financial terms makes it easy for them to understand the trade-offs.

For instance, when a company is first starting up, “do it fast” is nearly always the right answer.  (David Golden has a great post which explores this in greater detail.)  Basically, there’s no point in worrying about how hard it will be to change your software tomorrow when you’re not even sure there’s going to be a tomorrow.  Once a company leaves the startup phase, though, it’s time to think about paying down some of that technical debt.  If it doesn’t, the lack of agility means it may not be able to respond to customer demands quickly enough to thrive in the marketplace.

Now, technical debt is in many ways unique to every individual company, and there’s no one technique or approach that will work for everyone.  But everyone faces the same basic problem: I need my development team to keep making new features while they’re also paying off this debt; how can I have them accomplish even more than they were doing before without burning out, or creating new problems as fast as they fix the existing ones?  Hiring more people helps, of course, but it isn’t the complete solution.  But there are some general strategies that will work, and can be used by nearly every company that finds itself in the position of having a fair amount of technical debt to pay off.  These five areas nearly always need some attention, and they’re excellent things to think about when looking for ways to make your programmers more efficient, which not only gives them time to work on refactoring messy areas of your codebase, but also gives them more time and confidence to avoid creating technical debt in the first place.

Unit Tests  Few companies have no unit tests, but few have enough either.  I’ve heard people worry about creating too many unit tests, but honestly this is like your average American worrying about eating too many vegetables: I suppose it’s technically possible, but it’s unlikely to be a problem you’ll ever face.  It is possible for your unit tests to be too messy, though.  Remember: your unit tests are supposed to give you confidence.  The confidence you need to get in there and clean up some of that technical debt without being afraid you’re going to break something.  But your tests can’t give you confidence unless you’re confident in your tests.

Now, many people will tell you that you should put as much time and effort into your tests as you do your code (this is often—but not always—what people mean when they say “tests are code”).  I don’t necessarily agree with this.  I think that all the effort you put into your unit tests should go towards making your unit tests effortless.  I think your code should be elegant and concise: you don’t want it too simple, because it’s a short hop from “simple” to “simplistic.”  Imagine the Dr. Suess version of War and Peace and how hard that would be to get through—that’s what I’m talking about.  You need to use appropriate levels of abstraction, and using too few can be as bad as using too many.  You have to strike a balance.

On the other hand, your tests should be simple.  Very simple.  The simpler they are, the more likely your developers are to write them, and that’s crucial.  Whether you’re using TDD or not (but especially if you’re not), devs don’t particularly like writing tests, and anything that gives them an excuse not to is undesireable.  You want your tests to read like baby code, because that way not only will people not have to expend any brainpower to write new tests, but reading them (and therefore maintaining them) becomes trivial.  This doesn’t work as well for your code because of the crucial difference between code and tests:  Code often needs to be refactored, modified, and extended.  Tests rarely do—you just add new ones.  The only times you modify tests is when they start failing because of a feature change (as opposed to because you created a bug), and in many cases you’re just going to eliminate that test.  And the only times you should be refactoring them is when you’re working on making them even simpler than they already are.

So, in addition to trying to extend your test coverage to the point where refactoring becomes feasible, you should probably work on creating underlying structures to make writing new tests simple, and to make reading existing tests even easier.

Code Reviews  There are still plenty of companies out there not doing this one at all, so, if you fall in that category, you know where to start.  But even if you’re already doing them, you could probably be doing them more efficiently.  Code reviews are tough to implement well, and it has as much to do with the process you implement as with the software you choose to utilize.  Of course, it has a lot to do with the software you choose to utilize.  Code reviews, like unit tests, need to be simple to do, or people will find excuses not to do them.  Good software can really help with that.

Hopefully, like unit testing, code reviews are something that you don’t really need to be convinced that you should be doing.  But more people are resistant to code reviews than any other practice mentioned here.  They absolutely do require an investment of time and effort, and they absolutely do mean that you will deliver some features more slowly than you could without them.  Of course, if that extra time and effort catches a crucial customer-facing bug, you won’t be complaining.

But, honestly, catching bugs is not the primary benefit of code reviews ... that’s just the icing on the cake.  Code reviews just produce better software.  They’re the time and place where one developer on your team says to another: “hey, you know you could have used our new library here, right?”  (To which the response is inevitably: “we have a new libary?”)  They’re fantastic for cross-training too: don’t think code has to be reviewed by someone who already knows that code.  Have it reviewed by someone who’s never seen the code before and they’ll learn something.  Have your junior people reviewed by your senior people, and have your senior people reviewed by your junior people: they’ll all learn something.  It makes your codebase more consistent and builds a team dynamic.  It diffuses business knowledge and discourages silo effects.  If it happens to catch a bug now and then ... that’s just gravy.

Once you have code reviews in place, though, you’ll probably still want to tweak the process to fit your particular organization.  If you require reviews to be complete before code can be deployed, then code reviews are a blocking process, which comes with its own hassles.  Then again, if you allow deployment with reviews still outstanding, then you risk making the review process completely ineffectual.  So there’s always work to be done here.

Code Deployment  I suppose there are still software folks out there for whom “deploy” means “create a new shrink-wrap package,” but more and more it means “push to the website.”  At one company I worked at, deployment was a two-hour affair, which had to be babysat the entire time in case some step failed, and, if a critical bug was discovered post-launch, rolling back was even more difficult.  From talking with developers at other companies, I don’t believe this was an exception.

If your organization is big enough to have a person whose entire job is dedicated to deployment (typically called a “release manager”), then you don’t have to worry about this as much.  If that two hours is being spent at the end of a long day of preparation by one of your top developers, you’ve got some room for improvement.  But even if you have a seprate release manager, think how much you have to gain as your deployment gets shorter and simpler and more automated.  You can release more often, first of all, and that’s always a good thing.  And there are simple strategies for making rolling back a release almost trivial, and that’s absolutely a good thing.

Now, I’ve never been a fan of “continuous deployment” (by which I mean deployment happening automatically, triggered by checking in code or merging it).  But I do believe that you should strive for being able to deploy at any time, even mere minutes after you just finished deploying.  Part of achieving this goal is reaching continuous integration, which I am a fan of.  Having those unit tests you worked on so hard being run automatically, all the time, is a fantastic thing, which can free your developers from the tedious chore of doing it manually.  Plus, continuous integration, unlike code reviews, really does catch bugs on a regular basis.

Configuration Management  Similar to deployment, and for the same reasons.  If building a new production server is a heinous chore, you’re not going to want to do it often, and that’s bad.  Horizontal scaling is the simplest way to respond to spikes in traffic, and you should be able to bring a new server online practically at the drop of a hat.  It should be completely automated, involve minimal work from your sysadmins, and zero work from your developers.  There are all kinds of tools out there to help with this—Puppet, Chef, etc—and you should be using one.  Using virts goes a long way towards achieving this goal too.

For that matter, it should be trivial to bring up a new development server, or a new QA server.  Once that ceases to be a big deal, you’ll find all sorts of new avenues opening up.  Your developers and/or your QA engineers will start thinking of all sorts of new testing (particularly performance or scalability testing) that they’d never even considered before.  Figuring out how to handle database environments for arbitrary new servers can be a challenge for some shops, but it’s a challenge worth solving.

For Perl in particular, you also need to be able to reproduce environments.  You can’t spin up a new production web server alongside your existing ones if it’s going to be different than the rest.  If your server build process involves cloning a master virt, you don’t have to worry about this.  If you’re rebuilding a server by reinstalling Perl modules, you must expect that CPAN will have changed since you last built production servers, because CPAN is always changing.  For this reason, a tool like Pinto (or Carton, or CPAN::Mini, or something) is essential.

Version Control  In this day and age, I doubt seriously I need to convince anyone that they should start using version control ... although one does hear horror stories.  More likely though, you should be thinking about what VCS you’re using.  If you’re using CVS, you should probably be using Subversion, and, if you’re using Subversion, you should probably be using Git.  But along with thinking about which software to use and how to switch to a better one (preferably without losing all that great history you’ve built up), you also need to be thinking about how you’re using your VCS.

Are you using branches?  Should you be?  If you’re not, is it only because of the particular VCS you’re using?  If you’re using CVS or Subversion and telling me branching is a terrible idea, I can understand your point of view, but that doesn’t mean you shouldn’t be using branches—it just means you should probably be using Git.  Now, granted, branches aren’t always the right answer.  But they’re often the right answer, and they allow experimentation by developers in a way that fosters innovation and efficiency.  But it takes work.  You have to come up with a way to use branches effectively, and not just your core developers should agree.  If you have separate front-end developers, for instance, they’re going to be impacted.  If you have a separate QA department, they’re definitely going to be impacted—in fact, they can often benefit the most from a good branching strategy.  Your sysadmins, or your ops team (or both), may also be affected.  If you’ve tried branches before and they didn’t work, maybe it wasn’t branching in general that’s to blame, and maybe it wasn’t even the particular VCS ... maybe it was the strategy you chose.  Feature branches, ticket branches, developer branches—again, there’s no one right answer.  Different strategies will work for different organizations.


So these are some of the things you need to be considering as you look to reduce your technical debt.  None of these things address the debt directly, of course.  But, in my experience, they all play a part in streamlining a development team by increasing efficiency and cohesiveness.  And that’s what you really need in order to start paying down that debt.

Restoration of balance: anticipated

Once again I’m going to forego my usual blog post, this time because I don’t really have anything to say I haven’t said before.  About a year and a half ago, I posted a rather long, rambling musing on the topic of fate.  This week I’m reminded of that posting, in a very positive way.  I continue to believe that everything happens for a reason, and even things that seem to be bad at the time can often lead to a better outcome than expected (or hoped).  Not always, of course.  But the universe has a way of tempering the bad with the good in such a way that makes it difficult not to believe that there is an ordered plan.  My current plan is still ongoing, so I can’t guarantee it’ll end up where I think it will.  But, so far, my faith in the universe is back on track, and aiming at a destination that I’m currently pretty excited about.

Until next week.

Guides: Marion Burden

[I wrote this earlier this week, for my family.  I’ve decided to post it here as a part of my series about people who have had a great impact on my life.  You may wish to read the introduction to the series.]

For me, as a child, “family dinner” meant the mid-day meal on Sundays, with my grandparents on my father’s side.  Oh, we had dinners with my maternal grandparents as well, sometimes, but it was more infrequent, and more ... reserved.  Not as much fun.  And, once or twice a year, we’d go to family reunions, which were huge, sprawling affairs, with more relatives than I could keep track of.  My paternal grandmother had a very large family, and most of her brothers and sisters had decent-sized families themselves, and it made for quite a lot of “cousins” to keep up with.  Except they weren’t technically my cousins ... they were my dad’s cousins, or in some cases my second cousins.

My dad’s family was smaller, more intimate.  Dad has just one brother, and no sisters.  At first I was the only kid.  Then I had one cousin, then two cousins, and then two cousins and a little brother.  And that was as big as our family dinners ever got: grandmother and grandfather, mother and father, aunt and uncle, two cousins and a sibling.  We had a lot of family dinners—big dinners at Easter or Thanksgiving or Christmas, little dinners on your average ordinary Sunday—and I ate a lot of food at my grandmother’s table.  There were certain things that were very predictable at these dinners.  My grandmother would burn the biscuits.  Us kids would start eating before everyone was at the table, and we’d get yelled at.  There would be a minimum of one dish containing potatoes: boiled potatoes, mashed potatoes, or potato salad, and possibly two of the three, and, for a big dinner, probably all three.  There would always be homemade biscuits for everyone else, and canned biscuits because my uncle Jimmy and I liked those better.  And, if it was a holiday, there would be some sort of lime green Jello concoction, with whipped cream and unidentifiable chunks floating in it, and my aunt Marion would say “You know what that looks like, don’t you?”  And us kids would giggle, and my grandmother would sniff disapprovingly, but then she’d say that she only ever made the stuff just so Marion would get to deliver that line.

My grandmother and grandfather are both gone now, but all the rest of us are still here ... or at least we were, until a few days ago.  That’s when I got the word that my aunt Marion had passed away.  She’d been sick for a while now, so it wasn’t really a surprise.  Not that that helps.  When your family members die after a long illness, people will tell you that at least they’re not suffering any more, and when they die suddenly, people will say at least they didn’t suffer, but none of that really makes a dent in how you feel.  There’s a sense that you have of a person, regardless of how often you see them: it might be a large looming presence, or it might be just a comfortable feeling tucked away in the back of your mind, like the keepsakes you have up in your attic—you don’t take them out and look at them very often, but you’re comforted just knowing they’re there.  Then, one day, that sense is gone ... the loss might be overwhelming, or it might be like an itch you can’t quite reach, or it might be anywhere in between, but it’s always very sharp.  It cuts.  And it’s hard to adjust to.

I haven’t seen my aunt Marion for many years.  But I remember many things about her.  Some are superficial: her boundless capacity for the color red, and her endless delight in Snoopy, for instance, are things that everyone who knew her even slightly remembers.  Some are not even very well connected with her as a person: for instance, my earliest remembrances of my aunt and uncle are probably going out to their house, which was way outside town, and playing with their electric organ.  I don’t specifically see Aunt Marion in these memories, but the organ made quite an impression on me, as I was very young and it was very cool.

I remember giant stuffed Snoopies, and I remember elaborate piled hair-do’s, and I remember her candy-making business, with the rainbow assortments of white chocolate and the candy molds and she even made her own peanut butter cups, and that was pretty cool no matter how old you were.  And I remember lots and lots of family dinners.  I remember her bringing over my cousin Chris for the first time, and I remember her bringing over my cousin Cathy for the first time.  I remember that she laughed the loudest, and the easiest, and the most often.  I remember her giving us silly Christmas gifts, like bad cologne, just because she knew that my brother and I loved to say “Brut: by Faberge” in our best Eddie Murphy voice, and I guess she liked hearing us say it.

What I remember most about her, though, was her strength.  My Aunt Marion said what was on her mind, and she said it straight, and she didn’t care who heard her.  She was the only person in our family who did that.  My mother’s family was polite to the point of obsession; my father’s, more plain-spoken, but still proper.  But Aunt Marion went beyond plain-spoken and into what was to me a strange new world of honesty and forthrightness.  She came into a room like a whirlwind, dominated a conversation without monopolizing it, was brazen without crossing the line into shocking.  Well, I’m sure she crossed some people’s lines.  There were probably people who considered her rude.  There were probably those who were secretly jealous of her apathy towards what others thought of her.  I just thought she was cool, and, the older I got, the cooler she was.

So today I’m missing my aunt, even though I hadn’t spoken to her in forever.  Even though those family dinners are long gone, they remain fresh in my mind.  Even though I haven’t seen my cousins in years, my thoughts are with them, because they’ve lost their mother, and even though I haven’t talked to my uncle for just as long, my thoughts are with him, because he’s lost his soulmate.  My loss compared to theirs is very small, but I still feel it.  I’m going to miss my loud, crazy Aunt Marion because, in many ways, she was the best of us.  And that’s always worth celebrating.

Interesting

Well, it’s been an interesting week (more in the Chinese curse sense than the scientific inquiry sense).  I’m going to take some time to regroup and refocus, so I won’t be doing an extensive blog post this week.  Next week will be better.

Perl blog post #16

I had hoped the fact that the family was gone this week (camping) would allow me to get ahead on blog posts again, but, alas, it didn’t work out that way.  So I’m cheating a bit, by revisiting the same topic I essayed last week, since it seemed to stir up some strong emotions.  Toddle off to my Other Blog if you’re interested in seeing my rantings for this week.  This one doesn’t require any Perl knowledge at all, really; it’s more of a reflection of the nature of these sorts of debates on the Internet (such as they are).

Perl blog post #15

Still recovering from a bit of a cold this week—I’m in that lovely phase where you mostly feel fine, except every once in a while you start hacking and coughing until you hock up a big ol’ glob of phlegm—which was my second week at my new job.  Not the most awesome time to get sick.  Here I am trying to impress folks with how intelligent and savvy I am and instead I’m wandering around with virus-induced zombie-brain.  Ah, well.  I’ll have plenty more shots at it.

Anyway, I did I a quick tech blog post this week.  Just a response to some other blog posts I read recently.  Head on over there and check it out if you’re into Perl.  This one doesn’t require any technical knowledge, but a bit of understanding of programming languages in general and their evolution wouldn’t hurt.

Character Building

I fancy myself a writer.  I am, after all, in the midst of writing a book right here on this very blog, where anyone can read it.  Being an aspiring writer, I often ponder the various elements that one must master to create compelling literature.

Pacing, for instance, is one I struggle with a lot.  I tend towards a more deliberate (unkind version: slow) pace, and I have to push myself occasionally to keep from getting bogged down.  There’s also style (wherein I ponder if I’m being too verbose, or using too many adverbs) and setting (wherein I wonder if I’m describing things so thoroughly that people forget what’s going on in the action) and theme (which I have a bit of a love/hate relationship with).  But possibly the biggest one of all is: characters.

Characterization is one of the most important aspects of writing, at least in fiction (and, honestly, most non-fiction too).  Even if you write a story in which not a single human being appears, you will have characters.  Your animals will become characters.  Your haunted house, or old car (or haunted old car) will become a character.  As sick as I am of hearing some schmuck on a DVD special features video say “you know, the city itself really is another character in our movie,” it really can be true, when you’re writing.  We writers have a tendency to turn almost anything into a character—wind, diseases, furniture, electronic devices—and it’s because characters are so essential to a story.  If you’re a writer, there’s a pretty excellent chance that your reader is going to be a person, and they’re going to want to see a person in your story to identify with.  A person like them, or like someone they know, or like someone they’ve always wanted to know, or like someone they’ve always been afraid to get to know.  A character.

So, in order to draw the reader in, your characters needs to be as realistic as you can manage.  There are all sorts of tricks to achieve this.  You can base the character on someone you know, for instance; that’s always a popular one.  Or on some historic figure.  But of course the character will never be (can never be) exactly like another person.  They must have at least some qualities that are unique to them.  You will always have to, at least partially, make something up.

Now, as near as I can tell, there are two schools of thought on this.  This is not really an either/or choice, of course, but rather two extremes on a spectrum, with many people falling at either end, but many falling somewhere in the middle as well.  At one end are the authors who say “my characters do exactly what I tell them to and nothing more.”  At the other end are the authors who say “I just let the characters speak through me; I never know what they’re going to say or do until they tell me.”

The people at the first end tend to think of the people at the other end as New Age hippies spouting pseudo-mystical bullshit.  Contrariwise, the people at the far end tend to the people at the other end from them as fascist megalomaniacs who won’t let their characters “breathe.”  Given my belief in balance and paradox, it will not surprise you to hear that I think both camps are right ... and also that both camps are wrong.

Let’s pick on one of my favorite authors for a minute, Robert Jordan.  Now, please don’t accuse me of Jordan-bashing.  I’m not being facetious when I call him one of my favorite authors—I named one of my children after one of his characters, after all.  But that doesn’t mean I have to agree with everything he says.  Here’s something he said once:

The characters never surprise me. In terms of the book I am God. A writer who says that the characters take control is doing one of two things... either he or she is telling people what they want to hear because a lot of people seem to want to hear that the characters have taken over... or else, that writer is being exceedingly lazy and not paying attention. The characters NEVER really take over.^*

As much as I respect the man, I have to say I think he was wrong here.  And, if you’ve ever been reading the Wheel of Time series and wanted to reach into the pages and strangle one of his characters for making the same stupid mistake for the fifth or sixth time in a row, I bet you’ve wished he was willing to let his characters surprise him too.

On the other side, some of my other favorite authors, including Anne Rice (after whose character yet another of my children is named) and Stephen King (who is my ultimate literary idol) have implied or even come out and said that they never know what their characters are going to say next, and they’re just as surprised as the reader by their characters’ actions.  This is a bit too much hand waving for me.  It goes beyond metaphysics and into prestidigitation.

Basically, what I want is a theory that does allow my characters to surprise me, at least sometimes, but is still founded on rational, explicable thinking.  I want to be in charge as far as I can be, but not so far that I limit the organic reality of my faux people.

And, after a lot of pondering, I think I’ve found such a theory.

Let me approach this from an oblique angle.  Imagine your best friend.  Do you ever have conversations with your best friend, in your head?  You know, practicing for what you fear might be a difficult topic, or daydreaming about the two of you doing this or that, or whatever?  Sure you do.  In those conversations, your friend will say, or do, different things, and those things are likely exactly what your friend would do or say in real life.  But it’s all in your mind.  You have the ability to predict, with a pretty high degree of success, how your friend is going to react in a given situation.  And you know why you can do that?  Because you know things about them.

You know he never got along with his parents and left home at 17.  You know that she had an older sister that she always competed against, even though the sister herself never tried.  You know that he was raised Baptist and is now an agnostic.  You know that she was raised atheist and discovered Buddhism and fell in love with it.  You know that he hates peas but loves asparagus; you know that, when she goes to an amusement park, she’ll ride anything except the rides that go around in circles, because they make her queasy.  You know that, when he gets drunk, he gets maudlin and sappy; you know that she harbors a secret disdain for women who “pamper” themselves with massages or manicures.  You know that, in middle school, he was a bully, which he looks back on with shame.  You know that, in high school, she considered herself dorky and unpopular, but that there were at least two different boys who were madly in love with her.

And it doesn’t actually have to be your best friend.  Anyone that you’ve known for a long time will fall into the same bucket: family, even if you don’t particularly like them; out-and-out enemies, for that matter; even co-workers, if you’ve worked together long enough.  If you know them well, you know what they’re going to say in response to this or that.  If you can’t do that, you don’t really know them that well, right?  And, sure, you’re occasionally wrong, but that just adds another datapoint that will make you more likely to be right the next time.

We know that knowing all these details makes us more able to predict with certainty what a given person will do, how they will react to a given situation.  But we don’t know exactly how.  We know that all these details feed into a complex mental model, a sort of simulation of the other person.  The friend that you had that conversation with in your head isn’t actually your friend: it’s just a symbolic representation of that person.  But it’s close enough that you can use it to have a conversation with, just like a real person.  And, most of the time, your mental model of the real person will react in realistic, appropriate ways.

So how does knowing that your friend hates peas help you predict that he won’t take kindly to the suggestion that he’s treating his girlfriend badly?  We don’t really know.  But it all feeds into it, somehow.  We know that some mental conditions make it much harder for certain people to do this.  We know that, just like anything that people do, some people are better at it than others.  But everyone can do it, to a lesser or greater extent, and it works.  And the fact that we don’t entirely understand it provides the element of mystery to it.  Sometimes your mental model of your friend will surprise you with her answers.  And yet you still know it’s right.

Now you see how we can apply this to creating fictional characters.  Authors are famous for inventing countless details about their characters that never appear in the actual story: “backstory,” we call it.  Why do we bother with this?  Because we’re building mental models.  Our mental models of a made-up person have a major disadvantage that models of real people don’t have: there’s no feedback loop.  With a real person, their actions in the real world are constantly helping us refine our models of them.  On the other hand, models of fictional characters have a huge advantage over models of real people: they can be complete.  No matter how well you know another person, you will never know everything about them.  There will always be some secrets, something held back ... even if the other person doesn’t mean to.  There just isn’t enough time for someone to tell you everything that’s ever happened to them or everything they’ve ever thought about when they were alone, even if they could remember it all.  But a fictional character can’t hide anything from their author.  You know all: their deepest secrets, their innermost thoughts.  You can make up as much or as little as you need to, and you can always add more later.

Of course, you have to be careful about adding.  If your character has already appeared in the story, and you go fiddling with their backstory, you might inadvertently change how they should have reacted to something that you already wrote.  You also have to consider that the experiences that happen them in your story (that is, the plot points) are now experiences that feed into your mental model of them.  In this way, your characters will grow as the story goes on.

And now you can see how you are in charge of everything, and yet your characters can still surprise you.  With my characters, I find myself having long imaginary conversations with them, and, yes, occasionally they do surprise me with their answers.  I don’t always know why they say this or that; I just know it feels right.  And sometimes they even do things which completely mess up my authorial plans.  And, when that happens, you better just go with it.  If you try to force them into the course of action your plot demands, they’ll start to feel fake to the reader.  The reader won’t even be able to put their finger on why; they’ll just throw down your book in frustration and cry “Frederica would never act like that!” and storm off in a huff.

You see, readers have mental models too.  And they’re not required to respect your plot.

So, in a certain way, it is like your characters are talking to you, but there’s nothing mystical about it.  There’s a perfectly logical explanation, and it involves you maintaining ultimate control.  But that doesn’t mean you get to put words in your characters’ mouths all willy-nilly either.  There are boundaries.  And there can be surprises.

* from an AOL chat, preserved by Theoryland of the Wheel of Time

Perl blog posts #13 and #14

For only the fifth time ever, I missed a blog post last week.  I lost my driver’s license—actually, my entire money clip—and I was scrambling around, trying to replace everything before I had to get on a plane last Sunday.  So I have a reasonable excuse, I suppose.  Except for the fact that I had several posts all ready to go; all I had to do was get one of them up.  Ah, well.  My mind was fried.

Part of this was the moronity encountered when I was trying to replace my photo ID (which, you know, is sort of important for flying these days).  (If you were at YAPC with me, you probably want to skip this paragraph and the next, because I’ve already subjected you to this rant.)  Let’s start with the California DMV: the new driver’s licenses are all fancy and holographic, presumably to cut down on fake IDs.  But it means that, when you go to get a new license, they hand you a piece of paper off their printer.  Like a dot-matrix printer, even.  The fancy license gets mailed to you later.  Try convincing a TSA guy in Texas that the piece of paper printed off on 1980’s technology is your official state-issued ID.  But here’s the stupid part: there were 17 windows at the DMV, and, at every single one, there’s a thumbprint scanner.  Which scans your thumbprint and identifies you in real time.  Nice that I don’t really have to have much ID to get my ID, once I got my thumbprint in there in the first place, but the point is, you can afford 17 real-time biometric scanners, but you can’t afford one lousy holographic printer? really?

And then there’s Costco.  Your Costco card has your picture on it, and I actually read online that people had successfully used that with the TSA in a pinch.  So I went to get a replacement Costco card, just in case it might be useful.  They asked me for a photo ID.  I was tring to get a photo ID, I pointed out.  They said they couldn’t issue me a Costco card without a photo ID.  I pointed out that they already had my picture online: just bring it up on your computer and then look at me.  The lady looks at me and says: “But the picture is stored at the corporate headquarters.  It could take a few days to bring up.”  Seriously???  Have you people never heard of this little thing called the Internet?  I can get pictures from China in seconds, but you think it’s going to take you a few days?

And, after all that, the only person who really gave me any crap over not having a license with a picture on it was the dork at the cheap hotel I stayed at.  I even managed to get a rental car with my dot-matrix ID.  So that was nice.

Interesting side note: our best guess as to where the money clip went was that my youngest threw it away.  That’s her new thing: taking whatever she can lay hands on and thoughtfully putting it into the trash can, or recycling bins.  So helpful.

Anyhow, to make up for missing last week, I’ve posted not one, but two tech posts on my Other Blog.  So, if you’re into Perl, check out my post on notes in Vroom.  And you can also read about my experiences at YAPC 2013 if you like, and that one doesn’t require you to speak Perl at all.

I should be back on track starting next week.

Free at Last, Free at Last ...

Next week I won’t have a job.

This is by design, I should clarify.  I’ve given myself two weeks between jobs to decompress a little.  You know how some people say you should regularly do saunas or colonics to flush all the toxins from your system?  Sort of like that.

So for the next 15 blissful days, I’ll be lazing around, mostly doing nothing.  I’ll spend part of the time at a technical conference (where I’ll actually be delivering a talk, which is pretty nifty), but mainly just doing nothing.  Relaxing.  Winding down.  Chillin’.

Then I’ll start a new position at a new company, which I’m pretty excited about.  Not much to say about that yet, since all I know is what one can gather from the interview process and the background research that accompanies it, but I’m heartened by that fact that folks there seem to have read this blog (including the extensive series on the Barefoot Philosophy) and wanted to hire me anyway.  I think our goals will be plenty sympatico.

What I’m leaving is approximately six years at a company that I really enjoyed being with ... at least for part of that time.  Having signed a piece of paper that strongly enjoins me from saying anything that might cast my former employer in a negative light (and tell me that shouldn’t have been a danger sign), I will restrict myself to enumerating a few facts.

1. When I started work at this company, it was owned by eBay.
2. eBay was a pretty great place to work.  It wasn’t perfect by any means, but what complaints I had were mostly surmountable, and there were many layers of management between me and those policies, most of which layers were dedicated to making sure said policies didn’t impact my productivity.
3. This company was sold by eBay to a different company.
4. One year later, I’ve resigned.

There.  Nothing “negative” about that, right?  Just the facts.

I have noticed a trend in smaller companies that are acquired by larger companies.  The last company I worked for being owned by two different companies, I got to experience it twice.  Also at the company I worked for before that.  Also at a few of the companies I consulted for when I owned my own business.  Also at companies which I know of because they’ve employed friends, or family members.  Large companies which are essentially conglomerations of smaller companies (or one core business surrounded by many “satellite” subsidiaries, as in the case of eBay) seem to be run very differently than the smaller companies they were once composed of.  I’m not sure why this is.  The smaller companies were successful when they were independent: if they had not been, they would not have been purchased.  However, they inevitably fail as part of the larger entity, when they’re being run differently.  This is a trivial pattern to pick out for anyone who has spent more than a few years in the corporate workplace.  And yet the mistake continues to be made, over and over again.  I’ve always had a high tolerance for ignorance, but a very low one for stupidity.  When you make a mistake once, that’s ignorance.  When you continue to make the same mistake over and over, that’s stupidity.

The mistakes are somewhat varied, but the core of them is pretty much the same.  The smaller organization was nimble and responsive, but the larger company imposes rules and process.  The smaller organization had some lean years, but they perservered and grew stronger because of them; the larger company seems to expect an infinitely-increasing growth curve, with the result that even when you make money, you’re chastised for not making enough money.  The smaller organization valued employees and built its team slowly and with great precision, until every warm body was integral to its success, and there was no waste—not a single speck of fat to be trimmed.  The larger company sees the employees as faceless, replaceable cogs in a machine, and can’t understand why people with vast amounts of business domain knowledge stored in their heads leaving should be a big deal.  Just get some more people.  Lots of people out there wanting jobs.  Hell, you can probably find someone even cheaper to do the same job.  That’ll help the bottom line, too.  Win-win.

I continue to believe that there are companies out there, even larger companies composed of disparate subdivisions, that don’t have this rather large blind spot.  But that’s mainly because I’m at heart a romantic, even though I’m also a cynic.  One day I’ll have to do a blog post on Cynical Romanticism.  I’m also considering a longer post exploring some of the concepts above in more depth.  But for today, I’m just happy to be free.  To do what I want.  Any old time.  (And you’ll have to take my word for it that that’s an obscure 90’s song reference and not an obscure 60’s song reference.  That’s just how I roll.)

I’d ramble on a bit longer, but this is starting to cut into my lazy time.  I’m sure you can all find something to amuse yourselves.  The Internet’s a big place, after all.  As for my little corner of it, it’s about hang up an “Under New Management” sign.  In a couple of weeks.  This week, the sign just says “Gone Fishin’.”

Perl blog post #12

I’ve done another technical post on my other blog this week; it’s on the augment feature of Moose.  That’s Perl-speak, so pop on over there if you speak Perl.  If not, just relax and perhaps I’ll get something a bit more exciting next week.

Then again, my parents are visiting all this coming week, so perhaps not.  Who can say?

Another Mother's Day

Sometimes when you pick up your child you can feel the map of your own bones beneath your hands, or smell the scent of your skin in the nape of his neck. This is the most extraordinary thing about motherhood—finding a piece of yourself separate and apart that all the same you could not live without.

— Jodi Picoult, Perfect Match

Last night I had a dream.

In it, I was back in college—not my past, college-age self, but my present-day self.  In the dream, this was a bizarre experience, both better and worse than it was at the time.  On the one hand, age and experience makes it much easier to be able to handle some of the things that we handled badly at that age.  On the other, perspective and an ever-increasing awareness of the preciousness of fleeting time means that’s it’s very hard to take some things seriously, like whether you got an A or a B on some test.  At least that’s how it was in the dream, with the result that I would shake my head fondly (but calmly) at the things my fellow matriculates were freaking out about, but attack seriously the things they blew off to have one more beer.

Many of those attending classes with me were actual people I went to college with.  Not my close friends, but friends of friends, or people who were just in the same class with me, or lived in dorm rooms next to friends of mine.  You know the people I mean: the ones you’d drink with at the parties, or debate points of philosophy with in the library, or perhaps sit with in the cafeteria if there wasn’t anyone else around you knew, but that’s about the extent of it.  In the dream, more than going to class, we would sit around and talk about stuff—I don’t know about your college experience, but that was a big part of mine.  You’d take some class you never really knew much about before, like anthropology, or psychology, or Eastern religion, and you’d learn these things that blew your mind, and you just had to share them with people.  And they were sharing with you the things that they’d learned which had blown their minds.  And you all worked together to make these things relevant to your life, dithering over whether the Heisenberg uncertainty principle could be applied to Jung’s theories of déjà vu and synchronicity, or whether believing that the rites of cannibalistic tribes are acceptable for them but not for you was simply intelligent avoidance of ethnocentricity or downright moral relativism.  A whole hell of a lot of what you learn in college is just facts: sparkly, and exciting, but useless in isolation.  Those long talks over alcohol, nicotine, illicit drugs or no drugs at all, just constant lack of sleep—those were how we developed the framework on which we hung all the pretty facts.

For some reason, all my opinions and outlooks on life surprised my former classmates.  Perhaps it was just that they’d never known me that well.  But, the more we talked, the more I realized that my responses were peppered with phrases such as “there’s just no way you can maintain that philosophy once you have children.”  Which is odd, because all of my perspectives on parenting were developed back in my college days, and they really haven’t changed very much.  But none of these disucssion were actually about parenting.  They were about ... well, it’s hard to remember—you know how dreams are .. but things such as foreign policy and population control and spirituality vs religion and those sorts of abstract things upon which we all have strong but mostly uninformed positions.  But all my ways of looking at the world, my entire weltanschauung (to use a fancy word I learned in college), seemed subtly but irrevocably altered by my fatherhood.

And (I don’t know how I can know this, but, in that strange way of dreams, I do) it wasn’t merely the fact of my fatherhood.  It wasn’t just the existence of my children, but the children themselves.  Them as individuals, the particular people that they both already are and are growing to be.  There is a certain, inexplicable way that any new person you develop a close association with modifies your course in life, but the way that children do so is more profound, somehow. 

Abraham Lincoln supposedly once said:

All that I am or ever hope to be, I owe to my angel Mother.

(A shorter version of the quote is also attributed to George Washington.)  So it occurs to me that, if my children are responsible for changing the way I view the world, the ultimate repsonsibility for that lies with their mother.

Now, I’ve explored this concept before, both explicitly and abstractly, but apparently my subconscious felt there was more ground to be covered here.  Perhaps the annual recurrence of a day devoted to the celebration of motherhood was just seeping into the undercarriage of my brain.  Or perhaps my super-ego is trying to tell me that I need to appreciate The Mother a bit more.

On the one hand, it’s silly that I should need to be reminded to do this.  Without her, our children would never get educated, our bills would never get paid, our vacations would never get planned, and very little of our home would ever get improved.  Many of us would never get fed ... or would get fed infrequently, at least.  Tough to take all that for granted.

On the other hand, it can be too easy to forget the details as life goes whipping by.  There’s always something else to quibble over, some point of parenting to disagree about, some monetary issue to agonoize over.  Children can be annoying, whether human or otherwise: they pee on the carpet, spill your giant cup of water, feel sick to their stomachs, require help with video games or Legos or having their nails stuck in blankets ... there’s an endless amount of need to deal with, and sometimes you get lost in it, forgetting to pop your head up every now and again and remember how good you’ve got it.  Because they also curl up on your lap, nuzzle your legs, chase you around the house, challenge you to games, or just sneak up on you while you’re sitting on the sofa and lick your nose.  And none of that—not a single giggle or adoring look or nuzzled neck—would be possible without The Mother.

So one really shouldn’t require an annual day of celebration to remember all these things.  But I suppose one does, if only to force one to stop and ponder.  How much she has given.  Author Elizabeth Stone said:

Making the decision to have a child—it is momentous.  It is to decide forever to have your heart go walking around outside your body.

Author Debra Ginsberg went further:

Through the blur, I wondered if I was alone or if other parents felt the same way I did—that everything involving our children was painful in some way.  The emotions, whether they were joy, sorrow, love or pride, were so deep and sharp that in the end they left you raw, exposed and yes, in pain.  The human heart was not designed to beat outside the human body and yet, each child represented just that—a parent’s heart bared, beating forever outside its chest.

It’s a lot to risk, bringing a child into the world.  More than thrice as much, to risk bringing three, not even considering those who were lost along the way.  It’s hard, and joyous, and terrifying, and rewarding, and painful, and the most important, vital, life-affirming thing you get in this difficult, bitter world.  I’m lucky enough to have three quite pretty ones, and a mother for them who takes care of them, and of me.  It’s perhaps more than I deserve.  And a lot to be thankful for.

And I am.

In Search of Better Résumés

Today’s blog is about writing a better résumé.

Having run my own business for 12 years, I certainly saw my share of résumés.  In fact, in my current job, I’ve spent many months working on hiring.  Between the two, I’ve seen hundreds of résumés, and been involved in hiring dozens of candidates.  So I have a bit of experience in this area.

Of course, mine is only one opinion.  Some people are going to agree and others will disagree.  I’ve already been told by one person with some experience in these matters that he didn’t care for my personal résumé format ... too “fancy.”  But my format is informed by several rules that I have when personally reviewing résumés, and I have been, at several points in my career, the guy to impress when you wanted to get a job at my company.  So take that as you will.

Tip #1: Keep it short.  Résumés are almost universally too long.  The truth is that, when you’re faced with reading a dozen résumés a day, you can’t read them all anyway.  You’re going to just scan them.  And, even then, to be terribly terribly honest, I’m usually starting to drift off towards the top of page two.  Do everything in your power to reduce your résumé to one page.  And, realistically, unless you’ve been doing whatever it is you do professionally for a minimum of ten years, this shouldn’t even be difficult.  Having a two or even three page résumé when you’re just a year or two out of college isn’t impressive.  It’s pretentious.  Even at 10+ years, when it ceases to be unbelievable, it’s still unnecessary.

Let’s face it: the vast majority of résumé content is bullshit.  Everyone knows this.  Any decent résumé reviewer also knows this and will completely ignore most of the crap on your résumé anyway.  So don’t give them lots of crap to ignore.  Hit the highlights—that’s all they were really going to read in any case.  And this way you get to decide what the highlights are instead of having the reviewer take their best guess at it.

This year I’ll hit my 26th anniversary as a professional programmer.  I still got my résumé down to a single page.  If I can do it, you can too.  And people are far more likely to read the whole thing at that length.

Tip #2: Focus.  I’m a Perl programmer.  I generally am looking to hire Perl programemrs.  If you send me a résumé with a list of languages on it and Perl isn’t first in the list, I’m setting your résumé aside.  I’ve got plenty of other résumés where Perl is the first language in the list.  I want someone who’s passionate about Perl.  When you bury the lead in the middle of a rote list of languages you know, that doesn’t scream “passionate” to me.

Even worse, don’t put it in the wrong category, and don’t misspell it.  I have seen résumés for Perl jobs where Perl didn’t appear in the list of langauges at all, but in some other category like “Scripting.”  Sure, Perl is a scripting language.  Listing C++ and Java under “Languages” and Perl under “Scripting” isn’t going to win you points for being technically correct.  Even if I were to agree with you that you were technically correct—which I certainly would not—why on earth would I want to hire someone with so obvious a disdain for the language they were looking to be hired for?  And while misspelling anything on your résumé is pretty awful, misspelling the primary focus (e.g. “PERL” instead of “Perl”) is instant death.

And don’t give me any excuses about how you need a single résumé to submit to multiple different jobs.  If you’re seriously applying for more than one different kind of job—perhaps you’re both a Perl programmer and a C++ programmer, or perhaps both a programmer and a QA engineer—then make different résumés.  Even if the only difference is which language you list first, that’s a difference worth making.

Speaking of listing languages, don’t list every language you’ve ever dabbled in.  Hit the top 4 or 5 (or even fewer) and move on.  Remember: just the highlights.  I used to put Fortran on my résumé because I took a course in it once.  In college.  Thirty years ago.  I couldn’t program in Fortran if my life depended on it; why was I putting it on my résumé?  Just to pad.  And since it was tenth in a list of ten languages, I’m sure my reviewers had already decided they were drifting into bullshit territory long before they got there.  So why was I bothering?

Hopefully you can turn these specific examples into general advice.  If not, you probably have more issues than I can reasonably help you with.

Tip #3: Dates.  I don’t read most of the details on a résumé.  You know the one thing I do read?  The dates.  The dates on a job.  I look for particularly long gaps.  I look for how long ago you last worked with this or that.  I look for how long ago your first job was, because that tells me far more precisely how long you’ve been at this than some general “blah-di-blah years of experience” up at the top.

Every job should have a month and year that you started, and a month and year that you ended.  The most recent job (i.e. your current job, if you’re currently employed) should be first, and they should go in reverse chronological order, and your first job should be last.  I may very well jump to the end to see the start date on that first job.  Don’t bother with the exact day; I don’t care that much.  On the other hand, just years may not be fine-grained enough.

If you do have a large gap in employment, don’t try to hide it by leaving dates off altogether.  However bad it may look, I can always imagine worse.  When you don’t put dates on your résumé at all, I can’t see when you did what.  This irks me.  Don’t irk me.

Oh, and by the way: include every job you’ve held in the field you’re trying to get a job in now.  Some people will tell you not to do this.  I’ve been told, for instance, that I shouldn’t bother with my first couple of jobs.  They were a long time ago, after all, and there isn’t much there that’s relevant to my career now.  But when I review résumés, as I said above, I’m going to jump to the end at some point and look at the date on your oldest job.  That’s how long you’ve been in the business.  If you leave off your first job in the field, then I don’t know how long you’ve been doing this.  Do you not want me to know how long you’ve been doing this?

Now, don’t get me wrong: I don’t need to see (and actively don’t want to see) your jobs outside the field.  It doesn’t matter that you were a dishwasher or a pizza delivery guy or a construction worker or a paperboy.  I could care less.  But if it’s related to what you want to do—even tangentially—put it in there.  Be very brief in your description, since it doesn’t much matter and I’m likely not going to read it anyway, but put it in there.

Tip #4: Nobody cares about ...  Remember how, in high school, your teachers and your principal and your guidance counselor told you that your school record would follow you around for the rest of your life?  They lied.  I have never told a single person in my entire life what my high school grade point average was.  I never even put it on my college applications, although I’m sure they got it from the high school records upon request.  I have also never told a single person what my college grade point average was.  I don’t even remember what either of them were any more, to be honest.  I used to tell people what I made on the SATs every now and again, until I realized there were plenty of people in the world who had done better than I had and I should just shut up about it.  But I’ve never told an employer what it was, and I’ve never been asked.

I do not care what your grade on anything was.  It’s beyond irrelevant.  I also do not care what your hobbies are.  Some people will tell you that interesting personal details like this make you stand out.  They do not.  They make reviewers wonder why the hell you are telling them this.

One other thing: I have never called a personal reference.  Ever.  And I never will.  If you put them down on your résumé, they like you.  No, more than that: they adore you.  If you put someone down on your résumé as a personal reference who does not adore you, then you are a moron.  If you are a moron, I’m not going to hire you anyway, and I don’t need a bad personal reference to figure that out, so it’s a waste of time to call them.  If you are not a moron, any personal reference I call is going to tell me how utterly awesome you are, and I know they’re going to say that ahead of time, so it’s a waste of time to call them.  I don’t have time to waste.  I have hundreds of résumés to review, remember?

Tip #5: But they do care about ...  Every field is going to have a few unique things that don’t fit into a standard résumé format.  For me, it’s a link to my blog (my technical blog) and a list of the CPAN modules I maintain.  For you it might be professional organizations, or certifications, or who knows what all.  Put yourself in the reviewer’s shoes.  Pretend that you were going to hire a coworker.  If you had to work with someone for the next several years, what would you want to know about them besides all the other places they’d worked?  Would you really care where they went to school and what they majored in?  (There are perhaps some jobs where you would, but probably not.)  What about articles they’d written?  (Probably so, but then again maybe not.)  Only you, or someone else in your field, can answer this question.

Tip #6: Contact info.  Please, for the love of all that is holy, put your phone number and your email address on your résumé.  And absolutely under no circumstances allow your recruiter, if you must use one, to remove them.  Nothing frustrates me more than a résumé for someone I can’t contact.  And do not put either one or the other.  Put both.  Some people like phone calls.  Some people (like me) prefer emails.  You don’t know which type is going to end up with your résumé; don’t risk pissing off half of your potential reviewers.

Tip #7: Review.  Everything you ever write you must review.  Never, ever, under any circumstances, let a single thing that you write leave your possession without rereading it.  Nothing.  Not a letter, not a report, not an email, not an instant message.  And absolutely positively not something as vital as a résumé.  A résumé should be reread several times.  In fact, you should reread it before you send it to anyone.  Every time you send it to anyone.  You will constantly find mistakes or areas of improvement in your résumé, even when it’s been around for years and you’ve read over it hundreds of times.  Read it again.  You’ll find something else.  Pick apart the spelling, the punctuation, the grammar.  Give it to friends to read for you.  Pick the people you know who write the best and make them help you.  Read it aloud to yourself and listen to yourself.  Any time you hear yourself stumble over something, change it.

Tip #8: Don’t be afraid to experiment.  There is something to the idea that your résumé can be too over-the-top.  But there’s a long way to go before you go too far.  Résumés are depressingly similar, and when you have to go through hundreds of them, they all start to blur.  Anything that sets yours apart is far more likely to be positive than negative.  Look at it this way: even if the reviewer doesn’t like the risks you take, they’ll remember them.  I got a résumé once completely written in a strange, futuristic font.  I made fun of it mercilessly, but I still remember that candidate’s name.  Moreover, in the process of making fun of it mercilessly, I showed it to everyone in the office.  That’s the sort of exposure you can’t buy.

Once upon a time, people might recommend that you put your résumé on some sort of unique paper: pink, perhaps, or a heavier bond.  Nowadays everything is electronic, though.  Of course, you can do things with an electronic format that would be difficult or impractical to do on paper, if you have the skills.  You could, for instance, make your own watermark.  Or add a detailed image to your résumé, if that might have value.  You can definitely take this one too far—if you could somehow rig it so that, whenever I opened your résumé, a .wav file of the 1812 Overture played, I would consider that to be the résumé equivalent of the dreaded blink tag, and I would see you in hell before I saw you in the workplace.  But there’s a hell of a lot of room to play in before you reach that point.  Try it out on your friends before you try it out on an employer, if you’re worried.

Putting it all together.  So do I practice what I preach?  Well, here’s my résumé so you can judge for yourself.  Note that it all fits on one page, despite having quite a few years to fit on there.  In order to make that happen, I went with the two-column format, which is the experimental part.  I included a few things that some résumés don’t; I excluded a bunch of things many résumés have.  All my programming jobs are listed, and they all have dates.  Every job (except the first few, which are listed last) also includes exactly what technical things I was doing, so that anyone can see how old my experience with this or that is, or how long I’ve been continuously working with something.  My technical skills section has gone from being a long list of long lists to being a short, singular batch of bullet points, with only the top-tier skills listed.  And Perl is first, because that’s the sort of job I want to get.  And I’ve read it over and over again a hundred times.  At least.

In fact, the only piece of my own advice I didn’t take was including my phone number.  This is because I am a grumpy old man who doesn’t particularly care for phone calls, and I can afford to eliminate those people who can’t operate their email.  But this is definitely one of those do-what-I-say-not-what-I-do things.

So, there’s some advice on how to present your résumé, from someone who has some experience in those sorts of things.  Take it or not, as you please.  In fact, now that I think on it, the more people who listen to this advice, the fewer résumés I can toss aside without having to do phone screens.  So, actually, don’t take my advice.  Haven’t I told you not to read this damn blog?  Stubborn bastards.

The Barefoot Philosophy: Final Thoughts

[This is the final installment of an 8 part series: The Barefoot Philosphy.  It is based on my experiences as the founder of a business—Barefoot Software—which I ran for 12 years.  Please start with the intro.]


For the past seven weeks I’ve been telling you how awesome this philosophy is.  But it can’t be all good, can it?  No, of course not.  There are some downsides, and it’s only fair to point out what they are.

The first question that gets asked a lot is, if this is so cool, why doesn’t everyone do it?  My first answer is, this ain’t the way to get rich, and a lot of people seem to want that out of a business.  To be more explicit, I believe that you can use these techniques to build a very successful business, and the business will make a lot of money.  But not you personally.  There is a lot of sharing built into this model, and some people don’t like to share.

The second most obvious answer is that it’s hard.  It takes a lot of work to do all these things, especially since you’re going against the grain.  A lot of people will tell you you’re crazy.  Sometimes the talent you want to attract won’t be able to handle your “weird” business practices.  If you need to attract venture capital, you almost certainly won’t get it, or else you’ll have to compromise the model to do so.  People may applaud mavericks in public, but in private they want to hear the same old shit that’s “worked” for centuries.  They don’t hear it, their pocketbooks snap shut.  So following this philosophy is not going to be a walk in the park.  Valve puts it thusly:

... it’s really hard.  Mainly because, from day one, it requires a commitment to hiring in a way that’s very different from the way most companies hire.  It also requires the discipline to make the design of the company more important than any one short-term business goal.   And it requires a great deal of freedom from outside pressure—being self-funded was key.  And having a founder who was confident enough to build this kind of place is rare, indeed.¹

Notice how I put “worked” in quotes when I talked about the business practices that are considered tried and true.  This is because I don’t feel that those practices do work, in the long-run.  Of course, your average venture capitalist isn’t in it for the long haul.  There’s a fairly short window where they build the business up, then they sell it or go public, make themselves a tidy sum, and proclaim the process a success.  How often have you seen advice on planning your exit strategy when starting up your business?  If that’s your goal, this is definitely not the method for you.  It won’t work, first of all.  But secondly, it’s contraty to the spirit of the whole thing.  What happens to the poor employees after you’ve made your millions and absconded yourself off to the Caribbean?  The “tried and true” business practices may work for the venture capitalists and the founders looking for an exit strategy, but they don’t work for the employees, and that’s what this is all about.²

In fact, this methodology is pretty crappy at any short-term goals.  Giving employees the freedom and latitude to explore their own ideas means not being able to predict where they’re going to end up with any great accuracy.  On Valve’s list of “What is Valve Not Good At?”, number 5 is: “making predictions longer than a few months out.”³  You’re going to have to accept a little short-term volatility in exchange for long-term stability.

And, of course, never forget what I said at the very beginning: none of this is a substitute for having good sales and marketing.  You still need that stuff.  Only now you need to find salespeople willing to sign up to your crazy ideas on culture.

Can this work for all kinds of employees?  Hard to say.  My experience is primarily with technical people, mostly with managing programmers.  Valve and Netflix (and Google) are the same.  Netflix even draws a distinction explicitly:

In procedural work, the best are 2x better than the average.  In creative/inventive work, the best are 10x better than the average ...⁴

On the other hand, SRC, who is often credited with starting the move toward financial transparency and is certainly a proponent of employee ownership, is a manufacturing business, and Zappos⁵ is primarily a customer service business, so that at least gives us some belief that these are ideas that can be put to use regardless of what type of workers you primarily employ.

It’s also fair to note that most of my employees were doing hourly billable work.  If you’re charging your customers by the hour, it’s much easier to sell your employees on getting paid by the hour.  We experiemented with variations on the hourly pay—specifically a “salary bank,” where employees still got paid hourly, but that pay went into a virtual account from which they drew a regular salary—to help alleviate concerns over paycheck instability.  But it’s admittedly a harder sell to pay modern workers hourly when you’re not charging by the hour, and it makes determining profit figures (for calculating bonuses) tougher too.

The final question, of course, is “can it scale?”

Both Netflix and Valve are concerned with this question.⁶  As well they should be: according to Wikipedia, Valve has 400 employees and Netflix has 2,348.  SRC has 1,200.  Google has 53,861.  So at least some of these ideas actually are scaling.  Of course, no one is doing all the things I propose here, so I can’t answer the question definitively.  And even those success stories have their flaws: at least half of the things on the aforementioned “What is Valve Not Good At?” list are scaling problems.  But hiring high-performance employees and keeping them motivated (not to mention deliriously, ecstatically happy) goes a long way toward solving pretty much any problem—because the employees will solve the problems for you.  And I have no reason to believe scaling problems are somehow an exception to that.

But there is actually another question, one which might be the most interesting of all.  Would I use this philosophy again?

Well, in part that question devolves into “would I ever want to start my own business again?”  I’ve ruminated on this question before, and I didn’t come to a firm conclusion.  So I’m not sure about that aspect of it.  But I can say with absolute certainty that if I were to do it again, I would definitely use the Barefoot Philosophy.  The one thing that my experience taught me which I hold more dearly than any other lesson is that it is possible to create a company where the employees have fun, value their customers, focus on the bottom line, and still love coming to work every day.  It’s hard, but it’s possible.  And, once you achieve it, those same employees will fight fiercely to keep it going.  There will be never be a need to inspire them; they’ll show up that way every day.  There will never be a need to have them fill out surveys trying to ascertain their satisfaction; you’ll see it in every one of their smiling faces.  There are many things I do not miss about running my own business, but that one I do miss.  A lot.  Almost all my former employees are three thousand miles away from me now, so I rarely get to see them.  I miss seeing those expressions of delirious, ecstatic happiness that told me that, no matter how bad the stress was, it was all worth it.  So far, I haven’t found a place that could replicate it.  I want to see it again, that transportive joy to be at work with people you love, doing work that that you value, with respect, trust, and the freedom to make things happen.  I want to see it badly.

Perhaps one day I will.

Part: << 1 2 3 4 5 6 7 8

1 Valve Handbook for New Employees, page 49.

2 In fact, I just read an article that shows me that at least some tech entrepreneurs are starting to understand the downsides of the exit strategy, even for themselves.

3 Valve Handbook for New Employees, page 52.

4 Netflix Culture: Freedom & Responsibility, slide 36.

5 I didn’t go deeply into the Zappos business philosophy, but it’s focussed on employee happiness.

6 Netflix Culture: Freedom & Responsibility, slide 76, Valve Handbook for New Employees, page 42.

The Barefoot Philosophy: What Employees Want

[This is part 7 of an 8 part series: The Barefoot Philosphy.  It is based on my experiences as the founder of a business—Barefoot Software—which I ran for 12 years.  Please start with the intro.]


We’ve described all the cornerstones of the Barefoot Philosophy.  So, when you put it all together, what does it all mean?

That’s a tough question.  As I say, at the time I was involved in “the Grand Experiement.”  I was interested in proving a bunch of people wrong, and making a bunch of other people happy, and providing a kickass workplace (and a comfortable living) to as many people as I could manage.  I didn’t look much beyond that.

Now that I’ve had time to reflect, and now that I’ve gone back to working for others, and had a chance to find a few not-so-terrible (if still imperfect) workplaces to compare against, I think I can finally put my finger on what it all means.  I think that all employees want three things out of their jobs:

1. Respect
2. Trust
3. Freedom

And, when you think about it, those three things are not so much to ask.  They’re essential to basic human dignity, in fact.  But they’re mighty rare in today’s corporate workplaces.

Of course, none of those things can be unconditional.  Respect and trust must be earned; it isn’t just handed out to anyone who walks in the door.  Freedom is not absolute: it doesn’t mean that anyone can do anything they want.  There are caveats aplenty with all three.  But let’s consider each one briefly.

Respect means you listen to what people have to say.  In my line of work, we’re talking about programmers, or other technical professions.  In general, these people are highly trained, and very well-compensated.  In other words, you’re paying them a shit-ton of money.  Why would you not listen to them?  You don’t always have to do everything they suggest.  (In fact, they wouldn’t respect you if you did that.)  But when you ignore them, you make them crazy.  They’re not going to be content with just earning a bunch of money and not caring whether you ignore their highly trained advice.  And if they were content with that, why would you want people like that working for you anyway?

Trust means you believe that people want to do their jobs.  You don’t stand over them to make sure they’re doing it.  You don’t micromanage.  You don’t tell them they can’t work from home when they need to, or when they just feel like it.  You don’t insitute silly policies to try to control them.  You don’t ask them to justify every hour of their day.  I left my last job because of lack of trust, and, when I leave my current job, it will be for the same reason.  So if you’re trying to figure out how much trust is going to cost you, better factor in how much distrust is going to cost.

Freedom means giving people latitude to pursue their own ideas.  How can you expect to have any innovation without allowing freedom?  Google is probably the leader in this particular area, with their formalized “20% of your time on personal projects” policy, but very few companies have followed that lead.  Trying to direct the every move of your employees is doomed to failure on so many fronts: it’s distrustful, as we already covered, and it takes up way too much of your time.  Don’t you have better things to do?  And, in the end, you close off the avenues of exploration that lead your company to new and exciting places ahead of your competition.

You want highly motivated employees.  “High-performance people,” as they are referred to both by Netflix and Valve.  In fact, both the documents we’ve been dissecting contain this exact phrase: “high-performance people are generally self-improving.”¹  In other words, the best thing you can do to encourage these employees is just leave them the fuck alone.  As Netflix points out (emphasis in the original):

Responsible people thrive on freedom, and are worthy of freedom.²

What would you rather have: people that need constant coddling, or people who will take initiative, innovate, and get things done?  If you want the latter, you have to give to receive.  And what you have to give is respect, trust, and freedom.

And beware of rules.  Policies, and guidelines, and structure.  It has a tendency to multiply uncontrollably; don’t let it get a foothold.  We already talked about what what Valve thinks of corporate structure.  Netflix is more blunt:

Process-focus drives more talent out³

All those little rules and policies are going to drive your top employees—the ones who think out of the box and aren’t willing to be constrained by your rules—absolutely batshit crazy.  To people who think Netflix’s policy on vacation tracking (“there is no policy or tracking”) is insane, they respond:

There is also no clothing policy at Netflix, but no one comes to work naked

Lesson: you don’t need policies for everything⁴

Think about that for a minute.  I know, it sounds flip—it sounds like it’s supposed to be cute, and a little amusing, but not to be taken seriously.  But actually think about it.  Do you need to tell your employees not to come to work naked?  No?  Now go back and think about how many of the company policies you do have implicitly treat your employees like idiots.

In my experience, too many managers think their employees incapable of getting anything done on their own.  Even if they don’t believe that consciously, their actions scream it.  This why they come up with artificial deadlines, and guilt trips, and threats, and austerity policies.  These things are designed to put pressure on employees in order to get them to complete their work.  But these things are stupid: properly motivated employees don’t need pressure to do their work.  They want to do the work.  Now, perhaps you’re not properly motivating them (although that’s what the last 5 posts have been about, so you really have no excuse at this point).  But that’s not their fault.  It’s yours.

The only “pressure” I ever put on my employees was to foster some competition amongst them.  And even then I was very careful.  What you want is constructive competition, not destructive competition.  What’s the difference?  Simple:  Destructive competition is working hard to look better than the next guy.  Constructive competition is working hard to be better.  Looking better is most easily achieved by making the other guy look worse.  Being better requires self-improvement.  Merit-based pay and open pay rates and anytime raises and self-forming teams foster constructive competition.  Calibration and empty titles and infrequent compensation rewards and salary secrecy foster destructive competition.

At Barefoot, employees had a workplace that they valued.  They would do anything to protect that.  They understood the financial situation well enough to know how to protect it.  They knew where they needed to save money, and they knew exactly how valuable each customer was.  They fought to keep those customers: to keep them happy, to deliver top value, to go above and beyond and add personal touches.  When there was no work, they didn’t get paid, so they did everything in their power to make sure the work kept coming in.  I never had to stand up at a company meeting and remind everyone that it was their job to make the company successful; they knew it.  It was their company, after all.  There was no one “above” them whose job it was to take care of those things; it was their job.  Each and every one of them.  Every single one was a benefactor of the Grand Experiment, and they would do anything to keep it from failing.

I thought I was creating a utopia for workers.  It turned out I was creating a productivity juggernaut.

Next week we’ll climb down off our high horse and look at whether there are any downsides to this philosophy.

Part: << 1 2 3 4 5 6 7 8 >>

1 Valve Handbook for New Employees, page 38, Netflix Culture: Freedom & Responsibility, slide 122.

2 Netflix Culture: Freedom & Responsibility, slide 41.

3 Netflix Culture: Freedom & Responsibility, slide 50.

4 Netflix Culture: Freedom & Responsibility, slide 70.

The Barefoot Philosophy Cornerstone #5: Employee Ownership

[This is part 6 of an 8 part series: The Barefoot Philosphy.  It is based on my experiences as the founder of a business—Barefoot Software—which I ran for 12 years.  Please start with the intro.]


It’s time for the final cornerstone.  (Yes, I know that makes five cornerstones.  It’s sort of a pentagon thing.)  Merit-based pay and no salaries gave our employees a sense of financial independence and responsibility.  Financial transparency gave them the knowledge of how to run the company themselves, and no org chart gave them the ability to do so.  Now they just need the motivation to do it.

So give them the company.

I can’t tell you how many times I’ve heard people running a company say that they were frustrated because they couldn’t get their employees to act like this was their company.  I can, however, tell you how many times I’ve heard people running a company suggest that they solve this problem by actually giving their employees an ownership stake in the company: zero.  It’s done, obviously; I started out with cornerstone #1 talking about Jack Stack and SRC, which is an employee-owned company.  But none of the corporations I ever worked for considered it.  Occasionally, stock options were offered, but it’s just not the same thing.  Giving up ownership means giving up control, and giving up equity, and those are two things that most entrepreneurs just don’t cede.

Of course, I’m not most entrepreneurs.

I say, if you want your employees to act like this is their company, make it so this is their company.  Here’s how we did it at Barefoot.

When you first came to work at Barefoot, you were a probationary employee for 90 days.  At the end of that period, you were awarded one share of stock.  Not a stock option; an actual share.  It wasn’t much, but you were now a shareholder.  You had the right (and, again, the responsibility) to vote at the annual shareholder’s meetings, where we elected board members and occasionally approved tweaks to our articles of incorporation.

Of course, there isn’t much you can do with a single share of stock.  We were always privately held, so you couldn’t trade it on the open market.  You could sell it, but only to another shareholder—never to an outsider.  You could sell it back to the company for the current stock price (set by the board),¹ although the company could decline to buy it if it was economically infeasible.²  You could vote it, but one vote didn’t carry much weight.

But every year, at the end of the year (before the annual shareholder’s meeting), every current employee received another stock bonus.  This bonus was based on how long you had been with the company, and whether you held multiple roles (e.g., employees got stock, and board members got stock; if you were both, you got double shares), and a few other factors.  This stock distribution was mostly additional stock added to the general pool, so it diluted everyone’s percentage, but then everyone also received more stock, and in practice everyone always came out ahead.

Of course, the majority shareholder was me.  But, every year, I proxied the majority of my stock to the employees.  I split the proxies evenly amongst them, based on their current percentages.  So if you owned 10% of however much stock I didn’t own, you’d get 10% of the proxy.  I kept enough for myself that I was still a significant factor in the votes, but never so much that no one else’s vote mattered.  It would take a pretty serious coalition to go against me, but it was possible.

Also, every year I donated a chunk of my stock back to the company, which it used for part of the new shares it distributed.  I was slowly handing my company over to its employees.  I did it slowly and carefully, because I wanted to make sure I had the system right before I lept into it; the ability to squash any vote in an emergency situation was my safety net.  But, as the company finally ended, I was right on the verge of becoming a minority shareholder in the company I founded.

Is this crazy?  Jack Stack apparently doesn’t think so.

I don’t own 100% of SRC. I own 19%. The rest is owned by the employee stock ownership plan and various employees. I could have had more, but that was plenty for me. Not wanting to be accused of being greedy probably had something to do with it. But more important, I didn’t want to be alone. I was going to be leading the charge up the hill. I wanted to make sure that when I got to the top of the hill and turned around, there was a bunch of people coming with me.³

Netflix has a different approach.  Employees can choose to receive part of their compensation as stock options (not stock).⁴  Netflix points out that this lets the employees decide how much they want to invest in the company’s future.

But I didn’t want my employees to have to decide that.  I didn’t want them deciding that they didn’t care, or not having the money to invest.  So I just gave them the stock, whether they liked it or not.  I didn’t say to them, “act like this is your company.”  I said, “here: this is your company now.”

Now you see why I never worried about my employees ripping me off, or doing something that would be detrimental to the customers.  They would have been ripping off themselves; it was their customers they were looking out for.  With great power comes great responsibility, as the mantra goes, and I put that to work for my company and my customers.  Which were now my employees’ company and my employees’ customers.  Their reputation was on the line as much as mine was.  It was their money as much as mine that they were playing with when they made financial decisions.  They were not only earning top pay rates, plus a commission-based bonus, but any profit left over after all that was partially theirs too.

Did it work?  Well, I can prove that it did.  Because I had employees who would do some work for free.

In any company, there’s work that needs to get done that it just isn’t practical to pay someone to do.  Typically, the founders of the company do this work themselves.  This is why starting a business is such a time sink: you not only can’t pay anyone else to do it, you can’t really afford to pay yourself to do it either.  So it’s just extra work that somebody has to do after hours.

But, at Barefoot, there were no salaries.  Remember: if you’re working, you’re getting paid.  If that extra work was going to get done, either someone had to get paid, or ... someone had to agree to work for free.

Naturally, I was constantly putting in free work.  But I certainly never expected any of my employees to join me.  And, yet, that’s exactly what happened.

At Barefoot, you were allowed to work for free on company business as often as you liked.  You would still run a timer and track that time; you just attached the timer to a special internal “customer” which guaranteed that that time never hit your payroll.  At first, it was nothing more than a mark of pride: self-forming teams might take it into consideration when trying to decide between two close candidates (go with the person who’s more dedicated to the company), but it was mostly just for bragging rights.  We did eventually start using that time for other things, though: put in enough unpaid time and the company would start covering part of your health benefits; put in even more, and you’d increase the amount of stock you got at the end of the year.  We had to start adding these perks, because there were so many people doing it towards the end there that I was starting to feel guilty about it.  So if you ask me if know that my employees felt like this was truly their company, I can answer without a single doubt or hesitation.  Yeah, they knew it was theirs.

I set out to make my business employee-focussed.  To make it employee-owned was a natural outgrowth of that.  I never questioned whether that was the right thing to do or not.  I never meant to get rich, so I didn’t care about giving up the money.  I never wanted to be in charge, so I didn’t care about giving up the control.  I just wanted to love coming to work every day, and I wanted my employees to love it too.  The fact that it made my company financially stronger—because all the employees were now focussed on making their company run more smoothly and earn more money—was just a bonus, as far as I was concerned.

That’s all five cornerstones.  Next week we tie everything up and put a little bow on it.

Part: << 1 2 3 4 5 6 7 8 >>

1 In fact, technically you had to offer to sell it to the company first.  That is, the corporation retained “right of first refusal.”

2 Technically the company could decline.  In practice, I don’t think that ever actually happened.

3 “Being the Boss”, Inc., Bo Burlingham, October 1989.

4 Netflix Culture: Freedom & Responsibility, slides 103, 110.