Red Squirrel's Nuts

In February, 2000

I was a child and therapist, questioning whether I could become a software developer. My attempt at learning Java was stalling. The exercises in Java for Dummies didn’t seem to have any purpose. Even if I could get them to work (which I couldn’t), they didn’t seem to do anything useful. I was filled with doubt. Did I really want to switch careers? I had a good job and had just finished a master’s degree. Was I selling out?

After work, when I wasn’t writing for my About.com side job, I searched the web (sans Google) for local tech jobs. I marvelled at the long and impressive sounding lists of techno-acronyms that I needed to know in order to apply. I quickly realized that I was going to have to apply despite not knowing most of what they were looking for. Remarkably, I got an interview with a placement company who was looking for Java developers. I showed up and was unsurprised (but disappointed) when they cut the interview short when they looked more closely at my “resume”.

I kept looking for tech jobs. I even heard an ad for a Chicago “dot-com startup” on the radio. I wrote down the web address on a piece of paper, but soonafter lost it somewhere in my Chevy Lumina. I gave up on Java for Dummies, but dug deeper into HTML, and started learning some JavaScript. I wasn’t quite sure where this was heading.

[This year, I’m going to be blogging the year 2000, the year I started programming.]

In January, 2000

I was a child and family therapist. I worked in the Intensive Outreach Unit of the DuPage County Health Department. I had just finished my master’s degree in 1999 and was excited about my first gig as a “real” therapist. We worked in pairs and did in-home family therapy to prevent children and adolescents from being hospitalized for suicidal, homicidal, or psychotic behavior. We had a small case load and I was working with some great therapists. Compared to my cohorts from my master’s program, I felt like I’d found a great gig.

But I had another job too. I was the “Teen Advice” guide at About.com. I got the job to help pay the bills, but also because I’ve always been into computers, and was especially interested in the Internet since my uncle introduced it to me back in 1994. This job involved HTML, which felt magical to me, and I found that the time I spent coding HTML was giving me energy. I wanted to dig deeper into this seemingly magical art.

So, 10 years ago, between client appointments, I would hide out in my car in random parking lots reading Java for Dummies. Then I would go home and (when Staci and Rose were sleeping) try out what I learned. I worked hard at it for a while, and would get excited when I could make a button or JSomethingErOther appear on my PC, but it wasn’t sinking in. Applets seemed cool, I guess, but what’s with this javac thing? And all of these rules about public and static?

[This year, I’m going to be blogging the year 2000, the year I started programming.]

Second Nature

A Japanese translator contacted me last week. Apparently, Apprenticeship Patterns is being translated into Japanese. (In other news, Enrique might be working on Spanish and/or German translations.) Well, the translator wasted no time, and started asking Ade and me questions about the meanings of some trickier sentences in our dedication and Ward Cunningham’s foreword.

His question about the foreword forced me to rewrite Ward’s sentence, and I suppose anyone whose had to rewrite anything of Ward’s, I found the experience enlightening. The translator was confused by a sentence in the last paragraph:

The craftsmanship movement in software recognizes that making this stuff second nature isn’t, well, second nature.

Being the web geek that I am, the first thing I did was look up the definition of “second nature”: “An acquired behavior or trait that is so long practiced as to seem innate.” And after struggling with it for a bit, I rewrote the sentence into this:

The craftsmanship movement recognizes that practicing and acquiring the skills of software craftsmanship are not innate to humans. Not only do we need to acquire software development skills, but we need to acquire the skills of skill acquisition.

This satisfied the translator. I was pretty happy with it too, since it helps explain what the book is about. It won’t teach you how to be a great programmer, it will teach you how to learn to be a great programmer.

The Publication of Apprenticeship Patterns

Now that I’ve had the pleasure of holding my book in my hands I feel like it’s time to (re-)tell the story of how this book was born.

In the Spring of 2002, I worked at a big, old (bloated) non-profit organization in Chicago. My boss (IT manager) handed me a book that had been given to him by some local consultants. He had seen my accelerating appetite for software development books and figured I might be interested. I was skeptical of a book coming from my boss, but I knew the consulting firm had some respected software developers, so I took a look at it. The name of the book was Software Craftsmanship: The New Imperative. I read the back cover, set it on the shelf, and went back to reading yet another book on Extreme Programming.

Toward the end of that summer, I took some time off up in Ontario with my wife and some friends. Since I’d finished reading all the available XP books, I thoughtlessly grabbed Software Craftsmanship on my way out on my last day of work. Later that night, we were hurtling northward on the overnight road trip to Ontario. I had already put in my time as driver and everyone (except the driver) was asleep so I figured I’d try to get some sleep too. Naturally, I couldn’t, so I pulled out the book and started reading (with a flashlight). I read almost all of Software Craftsmanship that night. It was one of those “right book, right time” moments for me. Although the target audience for the book was managers and leaders, and I had been programming for less than 2 years, I was old enough (28) to understand what Pete was getting at despite my inexperience. When I put the book down, I had a direction for my career. The context that Pete had set in his book gave me a (albeit vaguely defined) path to follow, and showed me where I was on that path: I was an apprentice.

A few years later, I had switched employers and was working at ThoughtWorks. One of the main advantages of working at ThoughtWorks (2004-2006) was the doors it opened for me. After working on the dream team for my first gig, I gained a lot of confidence (and some competence) and started trying to make some waves. So, I rolled onto my second ThoughtWorks gig and started explaining how I had pair programmed with Dave, Obie, and Aslak. I realized it would be nice to have a name for the style of pairing we practiced. And so I wrote a blog post that helped name the practice of “Ping Pong Programming”. After I wrote this I felt compelled to email Brian Marick to see if the blog post might make sense to publish in Better Software. It apparently didn’t, but it did end up on StickyMinds (thanks to Brian). As a result of that article, I got a call from a StickyMinds editor who told me she just signed up the Prags to write about Software Craftsmanship and asked if I would like to write a column on the same topic. (The Prags didn’t really write much about craftsmanship, it was more a precursor to Andy’s excellent Pragmatic Thinking and Learning.) Whoa! Cool! I immediately agreed to write the column. But then I had to ask myself, what was I, an apprentice, qualified to write about?

The only aspect of Software Craftsmanship that I was qualified to write about in 2005 was developing one’s own apprenticeship. And then it dawned on me that there was a gaping hole between Pete’s Software Craftsmanship: The New Imperative and The Pragmatic Programmer: Journeyman to Master. Where does someone learn how to become a journeyman? And so, in March of 2005, I let my tiny corner of the blogosphere know what I was hoping to do. Earlier that month, a blog post by Chris Morris planted a seed that quickly grew into the first apprenticeship pattern: Be the Worst. Not surprisingly, Chris’s blog post inspired another aspiring author, Chad Fowler, who included a section on “Be the Worst” in his My Job Went to India book (now rewritten as the excellent Passionate Programmer). But I digress. A small pattern language started forming in my mind and I quickly dumped it into a private wiki so I could access it from anywhere (like, say, the hedge fund where I was consulting at that time, hey, the build took a long time!).

The pattern language format felt like a natural fit for the material that I was imagining, mostly because I had been profoundly inspired by A Pattern Language when I read it in 2003. For a while there, all I could “see” were pattern languages. One of the advantages of using the language format was that it connected me to the patterns community, who provided us with excellent feedback and encouragement when Ade and I presented at PLoP. But I’m getting ahead of myself! Who is this Ade character?

A month or two after I had started writing Apprenticeship Patterns, I contacted the Prags about having it published through their new publishing company. Andy had a look at my wiki and asked me to write him a sample chapter (they later passed on the book). This was just the sort of push I needed to get me out of wiki-land and into book-writing land. I soon realized that the book wasn’t going to work if it was just “the stuff that worked for Dave”, and I knew enough about patterns that they needed to be tried-and-true solutions to common problems. So I set out to test the Apprenticeship Patterns against the experiences of other software developers and look for new patterns in their stories. I started interviewing both experienced (Ron Jeffries, Norm Kerth) and less experienced (Desi McAdam, Micah Martin) developers. Working at ThoughtWorks made it easy for me to connect to a worldwide network of excellent developers which helped this process a ton. The most enthusiastic participant in these interviews was Adewale Oshineye. His responses were so well thought out and well written that after a few interchanges, I felt compelled to ask for his help.

Ade and I cranked out a bunch of solid work on the pattern language in 2005, but even before we met at PLoP, I had lost my momentum. It was getting to be late 2005 and I had just spent the better part of the year writing about learning, and I was missing out on actual learning. This was the year when Ajax hit the mainstream and Ruby on Rails exploded. I couldn’t not take advantage of the opportunities I saw, so I set Apprenticeship Patterns aside and started reusing the patterns I had been writing about to learn these new techologies. I ended up leaving ThoughtWorks to join Obtiva, which at the time was a 6-month-old 3-person software development consultancy. A year later, in 2007, we started Obtiva’s Software Studio so that we could more easily take on end-to-end Rails projects and bring on our first Apprentice.

Later in 2007, I was contacted by an editor at Manning who saw our patterns online. (We always kept our most “polished” patterns online to elicit feedback.) The editor from Manning encouraged me to finish the book. And then I remembered Mary Treseler from O’Reilly, who found our patterns back in 2005, encouraged us to continue, and even did some pro-bono editing for us. Before I proceeded with Manning, I wanted to talk to Mary. Once I contacted her, publication was immediately assumed and a contract was signed before the end of the year. Cool! They even gave Ade and me some advance money as we progressed through the milestones toward publication. And progressing we were!

Throughout this little story, I’ve been referring to the book as Apprenticeship Patterns, but up until March 2008, I had usually referred to the book as Software Craftsmanship: Apprentice to Journeyman. The name was a mashup of our inspirations from Pete’s book and the subtitle of The Pragmatic Programmer (Journeyman to Master). To be honest, I still like Apprentice to Journeyman quite a bit, but a couple things happened (some painful) in March 2008 that convinced me we should change the title to Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.

Obtiva grew a ton in 2007 and 2008, and madmimi.com launched in mid-2008, so my life got crazy busy. I started missing deadlines, a lot of deadlines. We were supposed to be finished by mid-2008. We didn’t actually finish until mid-2009. We did a huge push in December 2008, and that was basically the end of my work on the book. After that push, it turned out there was still more work to do, so I asked Ade to see the book through to publication, and if he could make it happen, we’d alter our royalty split from 75:25 to 50:50. Obviously, Ade got it done. He added a bunch of content and polish, and oversaw a ton of details that I would have missed. Along the way, I asked Ward Cunningham to write the foreword and I was surprised that he not only accepted, but wrote an excellent little story about him and Kent back in the old days to provide an introduction to the concept of an apprenticeship pattern.

And so, our little pattern language got printed. I hope you were able to learn something (or at least laughed a bit) from reading this story. More importantly, I hope that you have a look at the patterns and give a few of them a try. Let us know what happens!

What are you practicing for?

I’m running the Chicago Marathon this Sunday. I’ve done a bad job of preparing for this race, so I don’t expect my time to be better than my first two marathons. One of the reasons I haven’t had much time to prepare is that I’ve been coaching football 3 days a week. We practice Monday, Tuesday, and Thursday evenings, with games every Saturday. So, between the marathon and football season, I’ve got sports and practice on the brain, and like I’ve been prone to do in the past, I’m going to compare sports with software. Right, so, if you want to improve as an athlete, you need to practice. Furthermore, if you want to be competitive, you need to practice specific techniques. Guess what? Both are true for software development too. You’ll find that the best software developers have had a series of toy/side projects that they’ve used to practice ideas and hone techniques on. If you’re not practicing, and practicing well, your performance will suffer.

One of the patterns in our soon-to-be published book is named “Practice, Practice, Practice”. This pattern is all about creating a safe environment to make mistakes so you can experiment and learn. For the apprentice, questions about practice are generally “Why? Why do I practice?” The answer is simply, “To get better!” And you could keep drilling down and play the 5 Whys and you’d eventually get to something like “to make more money” or “to work on a project I enjoy”. For the journeyman, the question evolves to “What am I practicing for?” Now that you are a competent software developer, practice is still important, but I think it’s important to focus your practice a bit more.

Something I’ve noticed in my journeyman years is that I’m starting to learn what sort of work I like best. During my apprenticeship years, I was learning how to learn, becoming generally competent as a software developer, and experiencing a variety of different projects. After experiencing nine years of variety, I know what I like. And I’ve noticed that my peers have learned what they like too. Some of them like coaching, some like to teach, others like to facilitate change, others like to architect enterprise systems, and on and on. People in the software craftsmanship community tend to enjoy writing code, but of course, each of us has our favorite contexts and mixtures of activites that we enjoy best.

The software craftsmanship manifesto states “we are raising the bar of professional software development by practicing it”. And I notice that many of us are living up to this. Corey does katas. Micah creates tournaments. Jim leads small groups of learners through the exercises of the Wizard Book. Now, all of these are great forms of practice, but I chose to participate in just one of them, the Wizard Book.

Why did I choose the Wizard Book over other alternatives? Because I felt that learning and practicing examples in Lisp would bend my brain in new directions. You see, I’ve learned that the sort of work I like best is the sort of work that lets me work directly with “the business” and deploy code every day. These sorts of collaborative, fast-paced situations are typical of startups, so when I practice, I focus my practice on becoming a better “startup developer”. I’m not learning Lisp so I can write my next project in Lisp, but I am planning on taking what I’ve learned and applying it to help me write more expressive code more quickly, which is super-important in startup-land.

Why didn’t I choose to spend time on a tournament or a kata? I’ve done the code competition thing and I know how much fun it can be, but I think it would provide diminishing returns for me right now. I’ve done kata, but since I’m self-taught, I prefer to couple practice with reading since I’m light on theory. Both of these types of practice could help me be a better “startup developer”, but I felt that the Wizard Book fit best for me right now.

So, if you’re in the first 5 years of your career (yes, you’re probably still an apprentice), practice as much as you can! Try out a bunch of different types of practice. They will likely lead you into interesting and unexpected places. If you’ve transitioned into your journeyman years and have learned what sort of work you like best, focus your practice!

OK, I need to go for a run now. :)

The Growing Role of UX at Obtiva

[P]eople are recognizing that UX work is important, but I don’t think they realize quite how important yet.
Michael Feathers in Thoughts on the Future of the Boutique Software Shop

In his post about “boutique software shops”, Michael pondered the future of companies like 8th Light, Obtiva, Hashrocket and Edge Case. I can’t speak for those other shops, so I’m going to focus exclusively on Obtiva in the post. Except for this: these 4 shops, along with others like Atomic Object and Relevance, are slowly but surely starting to connect with each other and form a loose network of businesses that I predict will create some interesting opportunities for themselves and for our industry in the years ahead. But that’s a different story.

Michael’s point about the importance of UX for “the high-end restaurants of software development” was bang on in my experience at Obtiva. We started as a developer shop, and we’re still more focused on development than other activities like coaching, training, or user experience. That said, the role of UX has significantly increased for us over the years, particularly since we started our Software Studio in 2007.

In the past, when Obtiva has used a design firm for a customer’s user experience needs, we have sometimes had our customer engage directly with the design firm. To stick with Michael’s restaurant metaphor, this is like asking a restaurant customer to interact with two different servers who are collaborating to serve a single meal. Not surprisingly, this situation was annoying for our customer. Even if we acted effectively as a single team, the customer still had to negotiate with two different companies. Lesson learned: now we act as a subcontractor to design firms, or vice versa, so customers have a more coherent experience.

Michael goes on to say…

[I]n a high-end restaurant it is completely about the user experience. Everything is subordinate to that. I don’t mean subordinate in the sense that if a customer wants a quick and dirty burger rather than what is on the menu he’s going to get it, but rather that he’s going to get something special which reflects someone’s deep knowledge of the art of cooking, something which they can’t get any place else. Now, here’s the trick. That thing which constitutes that specialness in software probably isn’t clean internal structure. It’s more likely wonderful experience as a customer both in the engagement and in their experience of the application. To put it more boldly: it’s not that development teams need UX people, it’s more like UX teams need developers.

Michael’s bold statement overstates it a bit, but the spirit of the statement is true. In the past we may have needed a little design work here and there, but these days we find ourselves partnering with firms like Webitects (who presented at Agile2009) on projects in order to give our customers the sort of exceptional experiences they expect. To be clear, Webitects employs some of their own developers. And Obtiva employs a few of our own designers. But when either firm is faced with a project that requires deeper knowledge of a discipline that the other firm possesses, we partner.

Michael’s next point is near and dear to my heart…

What do you need to be a world class Chef? You need an incredible work ethic, talent, and taste. It’s hard to find all of that bundled in a single person, but typically the people who have it rise through the industry. Steve Freeman was telling me a story the other day about a master Chef who got so angry at his crew that [he] threw them all out of the kitchen and did the entire service himself. He was a master because he could do it all.

Two weeks ago, Jeff Patton and David Hussman gathered 12 agile developers and UX practitioners at Obtiva’s office to discuss what the two communities could learn from each other. Most of the people there were community leaders, people like Brian Marick, Ward Cunningham, Alan Cooper and Hugh Beyer, so they were often looking at things from a macro level. Being the inexperienced one in the room, I was looking at things from a micro level. It is (currently) less interesting to me to figure out how to get two communities to come together than it is to encourage developers to learn the fields of User Experience Design. I see this as similar to how Extreme Programming encouraged many developers to learn about testing 10 years ago. At the end of the workshop I was excited about learning UX because I see it as a crucial step toward mastering the craft of software development. I aspire to be a strong enough software developer that I can take on any aspect of a project, and when necessary, every aspect of a project. Ultimately, I want to work with a team of multi-disciplinary developers, rather than a multi-disciplinary development team. Which one sounds more like a kitchen to you?

If you’re interested in what each of the participants took away from the workshop that day, Ward Cunningham recorded our thoughts and posted them on his Youtube channel.

Be careful what you are good at

Michael Feathers wrote about his shift in focus from people to programming, which got me to thinking. To me, the two pivotal points of Michael’s post were:

1. He feels himself pulling away from a deeper involvement in teams and organizational change
2. Be careful what you’re good at

Being the self-centered guy that I am, I immediately wondered how I might fit into Michael’s post. I feel similar to Michael about pulling away from a deeper involvement in teams and organizational change. One of the reasons I felt compelled to start Obtiva’s Studio was because I had grown more interested in developing software than consulting. Coming from my previous career as a family therapist, I suppose I shouldn’t be surprised by my tendency to move from people into programming: I was drawn from a people-centered career into one that involves a balance of technical mastery and teamwork.

Michael’s post sort of implies that there are only 2 activites for him to choose from: 1) agile transitions, and 2) legacy code improvements. I think I know what he’s saying when he advises us to “be careful what you are good at.” Michael is probably better than most everyone on our planet at these 2 complex endeavors, but it sounds like he’s reached a point where they have become less interesting. Maybe I’m wrong about that? Michael can correct me. :)

But he makes a super-important point: be careful what you are good at. I have found myself purposely holding myself back in certain situations because I didn’t want to distinguish myself at something that I didn’t enjoy. I feel strange about that, but I feel like it has helped me grow into a role where I am best suited. Now, imagine writing a book about legacy code but not enjoying improving legacy code. Or writing a book about apprenticeship but not enjoying apprenticing people. Can it actually be dangerous to blindly do your best with every opportunity that comes your way? Do you risk finding yourself promoted into a role that you’d rather not be in? For instance, should you write a book just because a publisher has agreed to publish it?

I think one of the critical tasks to maximize your career is to know yourself. It sounds like for Michael, he has recognized that learning and sharing the deep, fundamentals of programming are what makes him tick. I have recognized that working closely with startup founders and delivering rapidly for them energizes me like few other activities. What makes you tick? Are you carefully becoming good at that activity?

Who are you comparing yourself to?

One of most important moments in my 9 year career came in year 2. I had spent the previous two years diving head first into Perl and had quickly become a strong-ish Perl developer. But then I saw some of the leaders in the community talk about books and ideas that were not Perl-specific, and they made it sound like reading these books (like “Code Complete”) and understanding these ideas (like Functional Programming) were important. Intimidated but interested, I branched out, started reading fewer Perl books, and eventually wandered onto Ward’s wiki. It was there I first learned about Extreme Programming. Soon after I grabbed a copy of Kent’s white book and I was completely hooked: he was describing the way I wanted to spend my working days. I found out the XP conference was going to be near Chicago that year so I paid my own way and took some time off work to attend. It was there that I had that uncomfortable, critical moment: I discovered a group of people who were many orders of magnitude beyond me in the knowledge, wisdom, and implementation of complex software systems. It was overwhelming, but inspiring.

To me, these moments are the hallmark of a successful conference. So many of us can quickly grow into big fish in little ponds and it’s important for us as craftsmen to connect to the larger pond and witness the mastery of the people ahead of us. This was one my goals for Software Craftsmanship North America: to help our community achieve an accurate self-assessment. Our speakers continually pointed at foundational books and concepts that we need to understand: Michael Feathers pointed us to the Wizard and Dragon books, Paul and I pointed us to the Mythical Man Month and the Pscychology of Computer Programming, and Uncle Bob pointed us to Structured Design and studying the Quicksort algorithm. I doubt anyone left SCNA with a warm fuzzy feeling of competence. I believe all of us came away with a uncomfortable (or overwhelming) feeling of how far we each have to go on the long road to mastery.

One of the things that motivates me to continue on that road to mastery is comparing myself to masters rather than the average programmer. I don’t want to slip into the false sense of confidence that comes from localized success. Just because I’ve reached a few small peaks doesn’t mean I should look down around me and feel satisfied, it’s when I’m on those peaks that even higher peaks are most visible! I haven’t worked with Fred George on a project yet, but I have the sneaking suspicion that he is one of the few practicing master software craftsman on our planet. When I get a warm, fuzzy feeling about the success of Obtiva, Mad Mimi or the publication of my book, I motivate myself by thinking about Fred. The guy loves delivering software more than anything, and he’s been doing it for decades. Why do I call him a practicing master? (I’m using the term “practicing” in the sense of actively engaged, like a “practicing physician”.) Because he’s still actively delivering software under the constraints of a business! He is not a trainer (though he constantly trains his people) or a consultant (though he engages people at every level of his company), instead he stakes his reputation on delivering software for a business, and he delivers. I think we need more of our masters behaving this way.

(Inspired by Seth Godin)

Alternatives

My colleague and friend Todd Webb and I were riding the train to the office discussing my motivation for writing my Breeding post. Todd is very good at asking questions and our conversation helped me verbalize my motivations for a couple ideas I’ve been pushing recently. The two ideas are that:

• Software developers can remain technical for their entire career
• Software developers can become exceptionally good at what they do AND enjoy marriage and parenthood

One of my goals for Software Craftsmanship North America is that the attendees are exposed to alternative career paths. Our speakers have all had extraordinary careers. They have all had opportunities to trade in their credentials for better pay, better titles, and a more normal-sounding life. But they have all chosen to cultivate their craft, to not allow themselves to stop doing what they love, even as they’ve broadened their careers into writing, business leadership, project management, and coaching. I want people to understand that while this sort of career isn’t normal, it is possible, for far more people than are currently choosing it. And we need people to choose this alternative path. We need people to retain their ability to code, even as they develop skills in user experience, business analysis, exploratory testing, marketing, and sales. As our technical tools become increasingly powerful and technical knowledge becomes easier to acquire, the opportunities for generalists and multi-talented individuals will flourish. The result is that in the coming decades, our generation will bring up more master software craftsmen than any previous generations.

My primary motiviation for blogging about Obtiva’s birth and divorce rates was not to pimp Obtiva (that was a secondary motivation :), it was to simply share some statistics that might encourage some geeks who are weighing the pros and cons of marriage and parenthood. Similar to my motivation with SCNA and lifelong programming, I believe there is power in alternatives. My thinking about these alternative paths stems from my training in graduate school.

I was trained as a family therapist in an approach called narrative therapy. Fundamental to this approach is the notion that we live our lives through the lens of our stories about the world. These stories are constructed socially, usually derived from the stories of our parents, our families, our friends, and our cultures. Often, the psychological troubles that people face can be traced back to unhelpful stories (or narratives), and usually these unhelpful stories are dominant cultural narratives, such as: a beautiful woman is a thin woman, or the sign of a successful person is his bank account. Now, it’s not that these dominant narratives are wrong. There are most definitely a lot of thin, beautiful women in the world. Just as there are many successful people who have a lot of money in the bank. The problem comes when these narratives dominate a person’s life to their detriment. If thin is beautiful, then thinner must be more beautiful, right? If money means success, then more money means more success! And so part of what narrative therapists do is help people find alternative stories, exceptions to the dominant narratives, and help people build up their own narratives that better fit their lives. Because it is absolutely possible for a woman to be beautiful and not thin, and for a person to be successful without having a lot of money in the bank.

Nine years ago, I chose to become a software developer because I fell in love with the creative act of crafting software. My definition of success for me has always been that I love my job while providing for my family. I hate the idea of yearning for retirement. I understand that life is a reality for many people. But I am lucky, I found a career I love that pays well enough to sustain our family. I am not alone! Geeks all over the world have discovered the power of software development and have experienced its rewards. What breaks my heart is when I see some of them giving up what they love in order to move up an organizational chart. Several years later, they hate their jobs and have fewer career options because their concrete skills have atrophied. If you enjoy what you do, cling to it. Cultivate it. You can have your cake and eat it too. And it tastes great.

Breeding

been around the world and found
that only stupid people are breeding
Flagpole Sitta, Harvey Danger

As Obtiva has grown to about 20 people in the last few years, we made a key decision that was guided by a simple principle. We decided to make Obtiva a Chicago-focused company. At the time, this felt like a big move to me, but it’s actually not that big a deal. After all, Chicago is an enormous city with a ridiculous number of businesses that need our help. We made this decision based on a principle that our founder Kevin Taylor has often repeated to me: “We’re not going to ask Obtivians to do anything the owners of Obtiva wouldn’t be willing to do themselves.” Since Kevin and I both have kids at home and place a ton of importance on seeing them everyday, we’re not going to ask people to travel very often.

What strikes me (and is a source of pride for me) is how we’ve been able to cultivate a developer-friendly culture while creating an environment where families flourish. This is a stark contrast to my time at ThoughtWorks where there was a signficantly high percentage of people who were divorced, single, or married without children. Now, there’s nothing wrong with singlehood or marriages without children. And while there are certainly valid reasons for getting a divorce, I think most of us can agree that divorce sucks. I feel stupid even having to say that. But families and children are the foundation of our society, and it certainly is a good thing for our country to have a strong birth rate relative to the rest of the world. Yet, I’ve heard echoes of Harvey Danger’s “Flagpole Sitta” lyrics among some of the software elites I’ve hung out with. I still get looks of shock (and sometimes horror) when I tell people I am married and have 3 kids. I don’t blame anyone for being surprised, my situation is just not normal for people my age, I guess. Over time though, I’ve definitely picked up on the vibe that you’d have to be a bit stupid to sacrifice your career, your money, and your freedom to raise a family. But now I find myself helping to lead a company of very smart people who are doing exactly that. These people love delivering software, and they love delivering babies too.

In Obtiva’s four year history, we’ve had 6 births, 1 adoption, 2 marriages and 0 divorces. We currently have 14 married people who have 21 children, with 4 more kids on the way, which includes our first pregnant programmer. There are a ton of stories behind these numbers. And while they’re just numbers, I find them to be significant. Maybe companies like Obtiva are the norm? I’m not sure, it doesn’t feel that way to me. I do feel that these numbers are good indicators that:

1. We’ve stayed focused on local clients
2. We work at a sustainable pace

After all, when you’re on the road all week or in the office late at night, you just don’t get as many opportunities to make babies (with your spouse).