Fear of failure

This entry was posted in Uncategorized on by .

By most measures, I led a charmed life growing up. My family wasn’t wealthy, but I never missed a meal other than when my dad took us on adventures and forgot that children need food to make it through the day. I went to good schools, with good teachers and good fellow students. I traveled the world courtesy of the US Navy. Both of my parents were around as much as they could be. Dad got deployed regularly, yet I remember him coaching most of my soccer teams and serving as a leader in my Boy Scout troops. Mom worked the night shift at hospitals, and still managed to drive my brother and me to and from school every day. They read to us, took us hiking and fishing and camping, told us stories, and planned reunions with our extended family. They provided my brother and me with all the love and support any kids could hope for. They took an active interest in our own interests, and it has paid off. My brother, aka “Grease,” flies an F-15 for the Oregon Air National Guard. My software career has taken me all over the world and helped me make hundreds, if not thousands, of wonderful friendships in the process. Basically my parents did everything in their power to set us up for success, to prepare us to go out into the world and make of ourselves whatever we want. I think they did a damn good job.

One thing they didn’t prepare me for, however, was failure. Now that’s probably unfair to say, because I got the “it’s not getting knocked over that matters, what matters is picking yourself up” lecture from my dad more times than I can count. “Stick-to-it-iveness,” as my mom calls it, is highly valued in our family. My brother inadvertently coined the term “gription” when he was 8 in order to describe that never-give-up nature of his own, unable to string together as many syllables as my mom or separate the concepts of “grip” and “traction.” In some twisted way I think I can take a bit of credit for preparing him to deal with failure, having spent over a decade beating him in every contest where a physical advantage was an unfair advantage. As for me, given the world I grew up in, I never knew real failure. Looking back it feels like I was walking along the blades of a powered-off blender, unaware that life had its finger on the button, just waiting for the right moment to push.

I remember the first time I failed, or at least the first time I feel like I failed. It was my senior year of high school, when my soccer team lost in the semi-final round of the Colorado state soccer tournament. Heartbreaking as it was, losing that match wasn’t my failure. My failure came a month or two beforehand, during an after-school practice. Earlier that week, a couple of the younger players had screwed up in a big way and our coach was pissed. He began the practice by having us run “suicides,” where you start at one end of the pitch, and run sprints to and from each of the lines across the pitch. After ten of these, a downright exhausting workout, he lectured us on the behavior that he expected from our team. Then he announced that our practice would be the usual two hours, only this time we were to run suicides the entire time! We could go home when we felt like we had worked hard enough that day. Then he blew the whistle and that was that. I ran two or three suicides before calling it a day. I had AP Chem to study for, and after all I wasn’t one of the screwups so I wasn’t going to take their punishment. That’s where I failed. I failed to push myself. I failed to support my coach. I failed to stick it out with the one player – our team captain – who ran until our coach forced him to stop because he looked like he was going to fall over and die. I failed to serve as a good example to the younger players on my team. I failed to share with them the lessons that I had learned from the truly excellent leaders I was blessed to work with in my life up to that point.

I won’t be offended if you’re laughing at me by now, at this self-indulgent account of failure which doesn’t even begin to touch the realities of life. I direct you back to my blender metaphor. That was the year that life pushed the button on me. Still, I think it was closer to a puree setting than full on ice crush or liquify.

That was the year that my parents got divorced, my high school sweetheart dumped me, and I voluntarily enrolled in an engineering school in upstate New York. Lacking any sort of motivation to get out of bed most days, and feeling a billion miles away from the supportive family I grew up with, I started getting bad grades for the first time in my life. I got my first D, and my second D, and then I dropped out before I could get my first F. I moved to Washington state where I could play poker, and lived with my dad for a month when he took me in in an effort to bridge the relationship that I had chosen to sever. Living with mom wasn’t an option. She liked to tell us that her job was that of an archer, drawing the bow back and aiming it as best she could and then relinquishing control once she had let the arrows loose. She was pissed, hurt, and fearful when one of those arrows chose to drop out of an excellent university and play poker instead.

At this point I’m still 19, and the blender is still set to puree. Most people know what the higher settings feel like, as I’ve learned since then – family members battling cancer; friends going to prison; friends going to fight a war, and not always coming back; people lying and cheating and stealing; loved ones passing way too soon.

If I’ve made you depressed, I’m sorry. This stuff has taken the last ten years of my life to sort out and it’s pretty clear that I need to get it out now. I promise to turn things around and end on a positive note.

I was not prepared for any of the nasty things life threw my way. I was not prepared to be hurt far beyond anything I had experienced before, for reasons that I could not understand. The world I grew up in – the happy, blissful, charmed existence of my youth – was shattered, and I was fucking terrified. I stopped doing many of the things I loved. I stopped opening myself up to new people and new experiences. I stopped pushing myself because I was scared to fail, that I would fail to achieve every outcome that I wanted. I was given plenty of lessons that I couldn’t predict and control every outcome, and that all I could control was my own response – just as my parents had taught me growing up. Being young and brand new to this reality thing, I denied it. Hard. When things didn’t go my way, I got hammered, or high, or took my anger and frustration out on people that I cared about. I didn’t think the rules applied to me, that I was exempt from the harsh realities of life. I spent the next ten years engaging in the parts of life I enjoyed and escaping from those I didn’t.

Some folks who know me might find this post strange. After all, I’m a happy guy, I do cool things, I have incredible friends and family. I’m certainly not a giant fuckup. The reason I can spend this much time writing about the negative things from the last ten years is that there’s not enough time in the world to write about all the positive things that have happened in that same time.

I feel weird. Despite all the positives and success in my life, I feel like I have been just a shadow of who I really am, who I can be. I have been so afraid of failure and pain that I have denied myself opportunities to achieve the success I want. I didn’t really have any idea until recently. Several months ago, one of my best friends flew down to see me to find out what was going on with me. He looked me in the eye and said, “You have so much potential, and it seems like you don’t even know it and you’re throwing it away, and it fucking kills me. What’s up?” All I could manage was “I don’t know man…I don’t know.” I was too scared to tell him the truth, scared to tarnish the image I felt he had of me as someone having my shit together. I was too scared to tell my best friend – one of the few people who cared enough to ask and cared even more to listen – that I struggled with addiction and depression, both made worse by the fact that I didn’t understand why and was too proud to tell anyone or ask for help.

I have made big changes for myself. I’ve kicked the bad shit and cut back on the not-quite-as-bad shit. I am now willing to face the unpleasantries that are part of the reality of life. I choose to face them instead of escape. I choose to get over my fear of being exposed as imperfectly human to myself and others, to share my failures and get help when I need it.

Looking back, I feel bad for the kid who felt the need to escape whenever he didn’t like what life threw his way. But I get it – I am that kid, just a little older and wiser. I’m still scared of pain and failure, that hasn’t gone away. I don’t need to succumb to it anymore. I don’t welcome it, but I acknowledge it, and choose to experience it as a part of my life. I understand now that each moment where I actively engage in my own life is a blessing that I give myself. There’s nothing profound about that statement, I must have heard it hundreds of times in various forms from other people. What is profound, for me, is applying it to myself for the first time that I can remember.

To the people who have helped me through tough shit: thank you. You engaged me when I couldn’t do it myself. To everyone who has seen the spark in my eyes when we work or play or talk or hang out: thank you. You engaged me in that moment and in doing so helped me engage myself. You helped me get a win that I didn’t even know I desperately needed until now. You let me experience my true self in those moments. After enough practice, I’m able to do it on my own, even when the moments are unpleasant.

TGIF. Let’s kick some ass today :)

Learning about my privilege

This entry was posted in Uncategorized on by .

Well, yeah. Part of my privilege is being able to go through life basically unaware that bad things happen to good people solely because they’re women, or brown, or muslim, or gay, or any other number of attributes that don’t apply to me. I’m not completely unaware, but I certainly was for the first 25 years of my life. That’s part of the privilege of being a white dude born to educated parents who worked for the United States Navy, I guess.

What has changed? Well to start, I dated a woman who wouldn’t let me off the hook for being ignorant just because I’m mostly a good person. She made me aware of social and cultural dynamics that I never knew existed. She clued me in to issues that I have the privilege of not experiencing first-hand.

Second, I work in an industry that over the past few years has become more aware and vocal of the social and economic gaps between privileged groups and marginalized groups. I don’t know how this awareness compares to other industries, but I do know that technologists – software technologists in particular – are uniquely suited to address disparity problems. Collectively we have a great deal of privilege that many people throughout the world do not enjoy. We can work from home, the beach, Paris, wherever we feel like. We can build successful businesses without ever stopping to put on pants. We can drop out of college and still pull down six figures. We can stretch our minds every single day, play with new concepts and ideas and never have to do the same thing twice. Most importantly, we can teach others to do all of these things.

Folks that enjoy privilege need to participate in this conversation. We need to start by listening. We also need to express our ideas in order to get feedback and learn. By necessity we start off simply, because we don’t share the same experience and perspective. I don’t expect a pat on the back for trying not to be an ignorant asshole, but I am aware that for me personally, playing with duplos represents progress. At the very least, I’m starting to put pieces together.

Why not to pair

This entry was posted in Uncategorized on by .

After 10 years in the game, I’ve finally managed to articulate the reasons why I feel it’s not worth pair programming. Behold!

It costs twice as much

I get so frustrated when I board a plane and see two pilots in the cockpit. If airlines would stop paying two people for one job, maybe I could check my baggage for free.

Earlier this year I had ankle surgery, and there were five doctors in the operating room – FIVE! How does someone call himself a surgeon if he needs other people to help him perform a surgery? The operation set me back 10 grand…greedy bastards.  I could have gotten a pimped out Mac Pro with the money they overcharged me.

You can’t tell me that it’s a safety issue in aviation and surgery. Commercial airplanes are basically giant computers that fly themselves. They’re not prone to drinking before flights and don’t give in to terrorist demands in the petty hope of making it home alive to see their families. Navy corpsman have performed countless field surgeries with far less training and in far harsher conditions than the so-called “elite” surgeons that work in the comfort of sterile operating room.

Problem solving is not a social activity

I hate articulating problems to others and processing their feedback. It uses up valuable bandwidth that would be better dedicated to holing myself up and tinkering away until I come up with something to brilliant. Everyone knows that Crick was just a pain in Watson’s neck.

Learn on your own time, not on the job

If you don’t know exactly what to do at all times, you’re really not qualified for the job in the first place. Go home and study until you get your skills up to snuff. All problems that arise in a software project can be avoided with a little more upfront analysis and design, so don’t expect to be paid to figure things out.

Develop software, not people

Nobody mentored me, I had to learn this stuff the hard way through good old fashioned hard work. Unless other people go through that same process they won’t appreciate the secrets of professional software development. I once spent 10 hours tracking down a syntax error, and I didn’t even know what a syntax error was! That built character. Programmers these days give up too easily. No wonder they need crutches like automated tests and version control – if they spent more time making sure their code worked right they wouldn’t need all those tests, and wouldn’t feel the need to go back to an older version from time to time.

On the flip side, explaining things to others is just a waste of time for senior developers. They won’t learn anything from someone who has different experiences. It’s not worth seeing the programming world through the eyes of another person. Nobody ever deepened their understanding of a subject by teaching it to others. In fact they risk losing their expertise by being forced to water it down.

Culture happens from the top-down

When people work closely together, they risk forming bonds and working styles that differ from those outlined in the corporate culture handbook. They might start to spend their lunch breaks together, talking about non work-related things, and miss out on the team-building nerf gun fights & foosball tournaments.

Loss of personal freedom

I love putting on headphones and listening to music when I program, but I can’t do that when I pair. I have to share a stereo with the people around me and occasionally negotiate with them about what music we listen to. We have to take turns sharing equipment and space, and I’m forced to share a bit of another person’s perspective.

Get on with your bad self, by yourself. I know I will.

Exploiting the GitHub profiling problem

This entry was posted in Uncategorized on by .

Late last week I read two articles about the problems that arise when companies use GitHub and open source as a way to evaluate job applicants. Ashe Dryden examines it from an ethical perspective, arguing that it disproportionately favors white men, who already enjoy disproportionate favor. James Coglan argues that a GitHub profile doesn’t say nearly as much about a person as some employers might think. Both articles are worth reading if you haven’t yet done so, and serve to help move our industry forward.

While reading the articles, particularly Ashe’s, I couldn’t take my mind off the obvious solution to a small part of the problem. If employers look at GitHub profiles…post something to GitHub.

Of course this does nothing to address the broader issues that Ashe and James discuss. That’s a lot harder and will take time and effort, and I’m grateful for people like Ashe and others in the community who have dedicated their time and effort to increasing diversity and tolerance in the software community and the world at large. Unfortunately, change is slow, particularly when it comes to righting injustices against disadvantaged groups of people. Slavery was abolished in the United States less than 150 years ago, but still continues in parts of the world (including in the US in the form of human trafficking).

We absolutely must continue working to level the playing field in our community. GitHub helps do that by being a freely available service that allows you to connect with other people. Any problems that arise are not because of GitHub or open source, but from a culture that permits people to attack and threaten others because…well, I don’t know why. If you’ve been paying attention, you’ll realize that our culture doesn’t actually permit that behavior at all – those people are assholes.

I understand that many people do not have time to dedicate to open source. That’s fine. I think you can make a favorable impression on a potential employer by spending 5 minutes per day posting something new to GitHub. I understand that many people might not want to have a public profile. In that case I suggest creating a semi-anonymous profile that you use only as a way to share code examples with potential employers. You might even explain to them why you aren’t publicly active on GitHub – Ashe has provided plenty of examples.

I admit that as someone who has benefitted from my involvement in open source, and has used open source as one indicator when evaluating job applicants, I was not aware of and cannot fully relate to the problems that Ashe has brought up. I think this discussion gives us an opportunity to evaluate and improve hiring practices moving forward. I also think it’s an opportunity for anyone – regardless of gender or race – to help themselves by posting some code. All it really takes to become an open source contributor is to share some code and slap an open source license on it. Hack the planet!

Why I think Google and Facebook are creepy and the NSA is criminal

This entry was posted in Uncategorized on by .

My dad and I love to talk politics. After Edward Snowden leaked his information about the NSA’s massive spy campaign against American citizens, we had plenty to talk about. My dad has been a Navy officer for nearly 30 years, has served overseas for a third of that time including a tour in Iraq, and currently lives overseas. The words “Obama”, “Congress”, “war”, and “terrorism” regularly come up in our conversations. I suspect that our phone calls get “flagged,” whatever that means. I’m okay with that. My dad knows some shit that neither I nor the US government want him sharing, and of course he never would. When he signed up for the military he chose to sacrifice some of his Constitutional rights in order to protect mine and yours.

When we first talked about NSA’s prism program, he argued that companies like Google, Facebook, and Amazon have been collecting information on their users for years, and exploiting it for profit. He’s absolutely right. I find it disgusting and creepy, and I think that this profit-above-all-else mentality we’ve come to adopt in the US is diminishing in social acceptability. I hope that over time we choose to legislate such activity in order to protect people’s personal information.

NSA’s Prism, on the other hand, is criminal.

What’s the difference? Google & Facebook are companies that I can choose to engage. I had a Facebook account, now I don’t. I used to be a user and champion of all things Google, now I keep my distance. I can’t do anything about our past history – they have info on me and will do with it what they see fit – but I can choose not to give them any more info from this day forward. I can opt out. Not so with Prism. I have absolutely no power there – the NSA collects whatever information they like without being accountable to anyone. They use American tax dollars to observe the behaviors and communications of the very taxpaying citizens that until recently have unwittingly funded their own surveillance. I consider such surveillance to clearly be a chilling effect on freedom of speech, a threat to our Constitutional freedom. That’s before we go down the slippery slope of what corrupt governments have historically done with the information they obtain from surveilling their citizens.

With Google & Facebook, I have a rational choice: I can decide that I get enough value from their services to justify sharing my personal information, or not. With Prism, I am forced into an irrational choice: call bullshit on my government and help our nation change (good), go with the flow and accept the chilling effect of a government that spies on its citizens (weak sauce), or renounce my citizenship (decidedly un-American). Our nation was founded on a principle of freedom of choice, and for nearly two and a half centuries has served as an example of the power and importance of that freedom. We may have gotten off track recently, but I’m optimistic about our ability to regain our American principles and be a good example to and citizen of the global community. Ending unchecked surveillance against law-abiding citizens will be a massive step in that direction.

What Peyton Manning can teach us about agile development

This entry was posted in Uncategorized on by .

Peyton Manning is having a historic season, and looks poised to take my beloved Denver Broncos deep into the playoffs and hopefully bring home a Super Bowl trophy. How does he do it? It turns out that the Denver Broncos are a high-functioning agile team, and we can see how several key agile principles play out in a football context.

Rapid planning, rapid execution

Football teams work in short iterations in order to achieve their objective of shipping touchdowns. Each play has two parts – planning and execution. Before the play, the offense huddles up to determine which play to run. When they line up, each player understands how he’s supposed to contribute to help his team move the ball closer to the end zone. Once the ball is snapped, each player performs to the best of his abilities to make that play a success. As soon as the play’s done, they do it all over again. Each play looks a bit different, but follows the same cycle of planning & execution.

Common skills, unique talents

Peyton Manning is one of the best quarterbacks to play the game, but that doesn’t mean he’s only good at throwing the ball. Football requires all players to practice a core set of skills – running, blocking, tackling, ball-handling, and passing. Although Peyton doesn’t participate in tackling drills to the same extent as defensive players, you can bet he still practices this basic skill in case he needs to make a key tackle (or at least help with one).

Communication is key

When offensive plays fails, it’s usually because of breakdowns in communication. A lineman misses his blocking assignment, or a receiver breaks from his route too late, or the quarterback fails to notice an oncoming blitz. Good teams communicate constantly, and nobody does it better than Peyton Manning. He has a plan before the snap, but once the teams line up he has new information. Taking in this new information and communicating with the rest of the team is key to adapting to the situation and making successful plays.

Getting up when you’re knocked down

Everyone gets knocked down from time to time. Cliche as it is, success comes from picking yourself up, dusting yourself off, and giving it another shot. Every team faces setbacks, whether it’s a result of human error or something far beyond our control. In each case we have an opportunity to respond to the situation and learn from it. Experience, especially the bad kind, is the first step in learning.

I hope this will make the next football game you watch just a little more interesting. Where else do you see agile principles applied outside of software development?

Join me for an online hangout where we’ll talk about RSpec, TDD, software design, and more

This entry was posted in Uncategorized on by .

Update: We’ve scheduled a date and time for the session. Get the details here.


I got an email the other day asking if I’d be interested in hosting RSpec office hours using enginehere.com. I love thinking and talking about this stuff, and when I checked out EngineHere I found a platform that looks like it makes it really easy for a group of developers to talk shop and argue about code. Here’s what we can do on EngineHere:

  • live text & audio chat
  • live edit & run code
  • live stack overflow-style q&a w/ voting & discussion

Basically it’s for doing stuff live! Combining the different ways that developers communicate into a tool that makes live communication as simple as longer-cycle asynchronous communication. Kinda like what Google Wave was supposed to be, only useful :)

I expect a lively discussion…I wonder if digital medium means we’ll break the record for shortest time before someone brings up mocks and all hell breaks loose. It’ll be an open forum, we’ll talk about whatever people want to talk about, but I’ll guide it as best I can from my experience in software testing and working with people to study and improve their own practices.

The hangout is totally free, and signup takes 10 seconds via github. Ben, the guy who built EngineHere, said he’s got a few kinks to work out before we can do it, so I’m guessing it’ll be a couple weeks. If you want to participate, there are three ways I can notify you of the details:

Tell your friends, bring a loved one, it’s gonna be a good time!

How I’d like to handle my future public fuck up

This entry was posted in Uncategorized on by .

I’m still a relatively young guy, I speak my mind, and I have a lot to learn about the world. This means that I will almost certainly fuck up in a public context. Not because I’m inherently a dick, but because I’m inherently human and make mistakes. When you see me fuck up, here’s what I’d like you to do:

  • get up and leave if you find it that offensive
  • track me down and address me in private
  • have an earnest conversation with me and allow me to think things through

Should you decide to call me out publicly, which is totally your right, then please do it immediately. Raise your hand, grab a microphone, or just shout out. Whatever it takes. I will take it in stride as best I can. I will say:

Thank you for bringing this to my attention. I hadn’t considered that. I will be mindful of this for the remainder of my time here. Can we please meet up afterward to discuss this in detail so I can understand where you’re coming from?

After said conversation, I will make a public apology if I feel it is warranted.

That’s it. I don’t expect this to work for everyone, and I don’t expect it to play out like this. I do want to put this out there in the hopes that folks with whom I share time and space can give each other the benefit of the doubt once in a while and learn from one another.

Some Books for Software-oriented Humans

This entry was posted in Uncategorized on by .

Here’s a list of (mostly) software-related books I love. None of them are a big secret – they’re all written by people that go to the same conferences you and I go to, published by the typical software book publishers, and sold in all popular bookstores (except for the Real Options comic book).

I’ve kept the descriptions short and sweet mostly for pragmatic reasons, but also because I’m not trying to convince you to read any of these. Rather I’m simply offering them up as a bookshelf that you might peruse to see what strikes your fancy. I consider all of these to be “the best” books or “my favorite” books. That is, if you were pull any of these books off of my bookshelf I would smile and say “nice choice.”

After forming the list I grouped them into categories that made sense given the selection of books. Inside each group I’ve listed them by the date they were published. When reading any book, technical texts in particular, it’s important to take note of when the book was written and published. Sometimes readers criticize a work for its ideas “being a bit out of date.” That might be an accurate criticism of a book published in the late 90’s, but certainly an unfair one! I’m also a big fan of reading several books about the same topic at once, and I like knowing where they each fit into the conversation.

I’ve included links to freely-available online versions if I know of them, otherwise the links will take you to Amazon. If you know of a freely-available legal copy of any of the books here, please email me with the information and I will update it on this page.


Non-software-specific books

I’m starting off the list with these two books because they’re the only two non-software-specific books on here. Pragmatic Thinking and Learning will help you digest this reading list (or any other), and Fearless Change will help spread new ideas you learn to your workpace.

Fearless Change: Patterns for Introducing New Ideas

Mary Lynn Manns

September 2004

What it’s about

Creating positive change within yourself, team, and workplace

Why I love it

You’d think that sharing awesome new ideas with people would be welcome and easy, but it turns out that a lot of people hate change. This book has helped me fight the good fight numerous times.

Pragmatic Thinking and Learning: Refactor Your Wetware

Andrew Hunt

November 2008

What it’s about

Strategies for learning, and maintaining a sharp mind

Why I love it

It gives some insight into cognitive theory, and is packed full of strategies on how to learn effectively by retaining information and creating learning curriculums. This continues the PragProg theme of being responsible for your career and personal growth. It serves as a great starting point for learning about learning.


Agile

Extreme Programming Pocket Guide

chromatic

June 2003

What it’s about

A small handbook of XP principles and practices

Why I love it

It’s a super handy reference for XP ideas and great for giving to people to give them a first exposure to XP

Extreme Programming Explained: Embrace Change (2nd Edition)

Kent Beck & Cynthia Andres

November 2004

What it’s about

Effective, sustainable, ethical software development

Why I love it

I spotted the first edition of this book when I was 15 and was immediately drawn to it because I though “Extreme Programming” sounded cool. It was way over my head at the time but it did introduce me to unit testing which I was able to apply right away to my little IRC client that I was building. Through the years I continue to go back to it and am always impressed with the focus on human interaction and behavior. It’s an important work on ethical software development.

Agile Principles, Patterns, and Practices in C#

Robert C. Martin

July 2006

What it’s about

Pragmatic agile development

Why I love it

It gives a good rundown of the different practices you might use in an agile software project, and goes into great detail on important design patterns and principles for building high-quality software systems. As far as I know this is the first published reference to SOLID.

Agile Software Development: The Cooperative Game (2nd Edition)

Alistair Cockburn

October 2006

What it’s about

An analysis of what makes software development tick, and how to arrive at an effective development model for your team and organization

Why I love it

This book taught me how to think about software development methodologies instead of simply how to follow one. This is another book that is focused squarely on the human element of software development, which is by far the most important aspect.


Business / management / less-technical

The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

Gerald M. Weinberg

January 1986

What it’s about

Getting paid to give advice

Why I love it

Consulting can be like trying to navigate around Cape Fear. This book serves as lighthouse, map, and tidetables…but it can’t change the weather.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Fred Brooks

August 1995

What it’s about

The realities of managing software projects

Why I love it

People screw up software projects in a lot of ways, and this book covers nearly every one of those in some form or another. “Adding manpower to a late software project makes it later,” “no silver bullet,” and the temptation and tragedy of software rewrites are all in this book. It’s a set of essays that you can read one at a time.

Peopleware: Productive Projects and Teams

Tom DeMarco

February 1999

What it’s about

How humans interact on software projects

Why I love it

It covers serious topics in a light-hearted manner, and challenges a lot of the “established wisdom” about managing software projects.

Beyond Software Architecture: Creating and Sustaining Winning Solutions

Luke Hohmann

February 2003

What it’s about

Bridging the gap between business and technology

Why I love it

It turns out that running a software business requires way more expertise than just writing good code. This is basically a handbook on running a software company.

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity

Alan Cooper

March 2004

What it’s about

Creating technology that humans love to use

Why I love it

This got me thinking about software from the user’s perspective, which I had never really done before. I consider this another important work on ethical software development.

Chris Matts Presents Real Options at Agile 2009

Chris Matts

2009

What it’s about

An economic approach to software development

Why I love it

This book opened my eyes to the reality that software projects are economic problems. It’s a quickly-read comic book that will change the way you think about planning software development.


OOP & Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software

Richard Helm, Erich Gamma, John Vlissides and Ralph Johnson (“Gang of Four”)

November 1994

What it’s about

Designing object-oriented software

Why I love it

I never thought about design before this book, I just wrote code and tried to make it work. The GOF book introduced me to the idea of object-oriented design and gave me plenty of ideas for writing understandable, maintainable code.

What Every Programmer Should Know About Object-Oriented Design

Meilir Page-Jones

August 1996

What it’s about

How OOP is supposed to work

Why I love it

Wrapping your code in objects doesn’t necessarily mean you’re “doing OO” and certainly doesn’t mean you’re doing it effectively or deriving the benefits of a well-implemented OO approach. I think this is the most important book when it comes to conceptualizing OO programming.

Analysis Patterns: Reusable Object Models

Martin Fowler

October 1996

What it’s about

Domain-specific patterns that show up in all types of applications

Why I love it

The world doesn’t need any more accounting software, yet on nearly every project I’ve worked on I’ve been tasked to build at least a little bit of accounting functionality. This book contains an in-depth analysis of accounting patterns (how exciting!), as well as patterns for measurements, planning, and contracts. If it sounds a bit dry it’s because it is, but it is still a great reference for working on these sorts of problems. Also with a bit of imagination you’ll start to see how these patterns appear all of your code even if it’s not in the same domain language as this book, and you can draw on it for inspiration. This book introduced me to the layered architecture.

Smalltalk Best Practice Patterns

Kent Beck

October 1996

What it’s about

How to write good code

Why I love it

It manages to strike a fine balance between telling me how to write code and how to think about writing code. Every pattern in this book presents an example of good code and explores what makes it good.

A Little Java, A Few Patterns

Matthias Felleisen and Daniel P. Friedman

December 1997

What it’s about

An approachable introduction to object-oriented programming and design patterns

Why I love it

It’s written by the same folks and in the same style as “The Little Schemer.” It introduces some of Java’s basic features, and covers object-oriented theory and design patterns in a fun, approachable manner.

Refactoring: Improving the Design of Existing Code

Martin Fowler

July 1999

What it’s about

How to safely take any bit of code and rework it so it makes sense to you

Why I love it

It’s one of the best-written books that I’ve read and has stood the test of time. I still refer to it when I have a design problem and am not quite sure what to do.

Object-Oriented Software Construction

Bertrand Meyer

March 2000

What it’s about

The nuts and bolts of writing robust applications in an object-oriented style

Why I love it

It convinced me that object-oriented systems can be every bit as rigorous and provably correct as functional systems. Half of SOLID is from this book.

Smalltalk, Objects, and Design

Chamond Liu

April 2000

What it’s about

An introduction to smalltalk that quickly moves onto object-oriented design principles

Why I love it

This book made smalltalk accessible to me and improved my thinking about object-oriented design in general to apply to other programming languages.

Streamlined Object Modeling: Patterns, Rules, and Implementation

Jill Nicola, Mark Mayfield, Mike Abney

October 2001

What it’s about

Organizing logic in an object-oriented software system

Why I love it

It completely changed the way I think about object-oriented design. I’ve used the patterns in this book on several projects, and the parts of code that use these patterns are by far my favorite to work with. It’s the most worn out book on my shelf.

Object Design: Roles, Responsibilities, and Collaborations

Rebecca Wirfs-Brock

November 2002

What it’s about

The fundamentals of object design

Why I love it

I think this is the first book I read on object design, and it really helped me start to understand the difference between wrapping code in objects and object-oriented programming. It provides a straightforward methodology for analyzing problems and breaking them down into OO solutions.

Domain-Driven Design: Tackling Complexity in the Heart of Software

Eric Evans

August 2003

What it’s about

Focusing on the business logic in software

Why I love it

The second most important lesson I’ve learned about software development is that software is a knowledge acquisition process (the most important is that it’s always all about people). This book started me on my journey towards understanding how we learn in software projects and what we do with that knowledge. It argues that understanding the business logic of software projects is so important that you should make every effort to keep those concerns separate from all other concerns. It covers how to have conversations with domain experts, analyze problems, and ultimately implement them in code. I’ve also given away several copies of this book, and it served as the basis of my Domain-Driven Rails talk at Aloha on Rails (video) and Domain-Driven Rails Redux at RailsConf 2010 (slides).

Object Thinking

David West

February 2004

What it’s about

Understanding a software system’s behavior and organizing responsibilities

Why I love it

At this point in life I’m better served by books that give me a new way of thinking about things rather than just telling me how to do something. This is that book, for OOP.

Refactoring to Patterns

Joshua Kerievsky

August 2004

What it’s about

Moving code towards and away from design patterns

Why I love it

I definitely became “patterns happy” when I read the gang of four book. This book helped me identify the patterns hidden in my code and make them explicit, rather than try to force design patterns on my code. It was a critical book in my understanding of evolutionary design.

Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition)

Alan Shalloway & James R. Trott

October 2004

What it’s about

Object-oriented design with a focus on design patterns

Why I love it

It taught me how to think about object-oriented design and design patterns, not just tell me what they are.

Implementation Patterns

Kent Beck

November 2007

What it’s about

How to think about and write good code

Why I love it

It’s the same idea as his Smalltalk Best Practice Patterns, only in Java and with an extra decade of experience

Design Patterns in Ruby

Russ Olsen

December 2007

What it’s about

Structuring Ruby code

Why I love it

It’s the first book I read that really focused on beauty as a desirable end goal when writing code.


Automated Testing / TDD

Test Driven Development: By Example

Kent Beck

November 2002

What it’s about

An introduction to TDD

Why I love it

This is the book that started it all. Whenever I learn a new language or test framework I go through the examples in this book.

Test-Driven Development: A Practical Guide

Dave Astels

July 2003

What it’s about

Using TDD to write real software

Why I love it

After I read TDD by example I wondered, “where do I go from here?” This book was the answer for me. It builds on Kent’s work and builds a working, useful application start to finish using TDD, with a focus on refactoring. It also introduced me to the idea of “programming by intention” which has served me well.

JUnit Recipes: Practical Methods for Programmer Testing

J B Rainsberger

July 2004

What it’s about

Practical considerations when writing automated programmer tests

Why I love it

The recipes in this book have one underlying theme: how to think about automated testing. Even if you skip over the huge section on J2EE, you’ll get your money’s worth from the chapter on testing design patterns and appendix of essays.

Every recipe is presented in a “Problem, Background, Recipe, Discussion” format, making it a very pragmatic, approchable book and another one of those books you can digest in chunks.

Working Effectively with Legacy Code

Michael Feathers

October 2004

What it’s about

How to confidently make changes to gnarly, untested codebases

Why I love it

Life sucks when you don’t have automated tests to back you up. Follow the strategies in this book and you’ll eventually turn a codebase you hate into something enjoyable to work on. Note: It’s hard work.

I’ve given away more copies of this book than any other. It inspired my Working Effectively with Legacy Rails Code talk at Scotland on Rails 2009 (video) that I expanded with BJ Clark at RailsConf 2009 (slides)

xUnit Test Patterns: Refactoring Test Code

Gerard Meszaros

May 2007

What it’s about

How to write and refactor your way to a clean test suite

Why I love it

I’ve worked on many software projects where the team was dedicated to refactoring and keeping their codebase clean, and the test suite was a horrific mess. I never understood why. Then this book came out and I realized that it filled a hole: there simply was no literature on what makes for clean test suites prior to this book. There are different forces at play in your test suite than your production code, so the way you keep it clean necessarily differs from time to time. If you’ve wondered how to write a particular test, you’ll find some good hints in this book.

Growing Object-Oriented Software, Guided by Tests

Steve Freeman & Nat Pryce

October 2009

What it’s about

How to use TDD to build a software system from the ground up and continually refine its design to incorporate new understanding and keep things simple

Why I love it

Earlier books showed you how to do TDD. This is the book that shows you how effective TDD helps you write good software.


General Programming

The Pragmatic Programmer: From Journeyman to Master

Andrew Hunt & Dave Thomas

October 1999

What it’s about

Crafting a career as a software developer

Why I love it

It introduced me to several important programming practices and served as a starting point for deeper research and explanation. It gave me practical ideas on how to be responsible for my growth as a programmer. To this day I think it is the most beautifully constructed, organized software-related book that I’ve read.

Code Complete: A Practical Handbook of Software Construction

Steve McConnell

July 2004

What it’s about

Constructing robust software applications

Why I love it

I call it “Object-Oriented Software Construction, Millenium Edition.” It’s not an OO book, but it’s in the same vein as OOSC in that it provides a detailed approach for constructing software that can withstand users and technology.

Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition

Dave Thomas, Chad Fowler, Andy Hunt

October 2004

What it’s about

Our most favoritest programming language ever

Why I love it

This might be the best language-specific book I’ve ever read. I remember it being so approachable, and it got me excited about programming again. Nearly every page led me to yell “no way!” and go experiment. Had I not encountered this book, I may not have pursued a career as a programmer.

There’s a 1.9 edition that I’ve not read yet.

Ruby for Rails: Ruby Techniques for Rails Developers

David A. Black

May 2006

What it’s about

An in-depth look at Ruby’s powerful features, with a focus on how they’re used to implement Rails

Why I love it

This book really opened my eyes to what you can do with Ruby. I had dug into the Rails source code but found a lot of what looked to me like magic. Ruby for Rails explained the magic and inspired me to do some crazy stuff with Ruby.

Clean Code: A Handbook of Agile Software Craftsmanship

Robert C. Martin

August 2008

What it’s about

Developing the habit of writing the best code you’re capable of, and constantly raising the bar

Why I love it

This is a great “15 minutes a day” book. It’s basically a list of of tricks and rules of thumb that old people like Bob wish young people like me knew. You can literally open the book to any page, read for 15 minutes, and come away with something to use in your work that same day.

The Clean Coder: A Code of Conduct for Professional Programmers

Robert C. Martin

May 2011

What it’s about

Bob’s treatise on what it means to be a professional programmer

Why I love it

Whereas Clean Code is all about the nitty gritty details of writing and thinking about code, The Clean Coder takes you up 10,000 feet and advises you on how to approach your career and growth as a programmer.


Software Architecture

Patterns of Enterprise Application Architecture

Martin Fowler

November 2002

What it’s about

Architectural design patterns

Why I love it

Design patterns in day-to-day code is nice, but what about application architecture? The way you divide your app into business logic, infrastructure, and error-handling code has a huge impact on how robust and maintainable your software is. My favorite part of reading this book was noticing how many ideas in Rails’ architecture came from this book (and how other parts of Rails could be improved!)

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Gregor Hohpe & Bobby Woolf

October 2003

What it’s about

How to connect large software systems in a loosely-coupled manner

Why I love it

If I’m looking to split an application into services, expose an API, or consume an API, I consult this book for ideas, and it delivers.

The Architecture Of Open Source Applications

Amy Brown & Greg Wilson

June 2011

What it’s about

This is an anthology of essays written by open source software authors about software packages that you know and love (or hate)

Why I love it

It provides a pretty in-depth look at a wide variety of open source projects, in which the authors of those projects tell you funny stories, discuss the historical context of the software, and present some of their major challenges and how they solved them. If you want to understand how productive programmers make pragmatic decisions to ship useful software, this is a great starting point.


Functional Programming

The Little Schemer – 4th Edition

Matthias Felleisen, Daniel P. Friedman and Duane Bibby

December 1995

What it’s about

Recursion

Why I love it

It’s written in an extremely pleasant socratic dialogue style and introduced me to scheme. It focuses on breaking down problems into recursive solutions which can yield extremely elegant results.

The Seasoned Schemer

Matthias Felleisen, Daniel P. Friedman and Duane Bibby

December 1995

What it’s about

Thinking about computation

Why I love it

It introduced me to important functional programming concepts as well as computation concepts in general that I’ve been able to apply in my work every day since I read it.

Structure and Interpretation of Computer Programs, Second Edition

Harold Abelson, Gerald Jay Sussman and Julie Sussman

August 1996

What it’s about

The theory and practice of computer science

Why I love it

This is one of the absolute classics, and working through it gave me a solid foundation for reasoning about computer programs. The chapter on implementing a scheme interpreter in scheme blew my mind and excited my imagination.

The Haskell School of Expression: Learning Functional Programming through Multimedia

Paul Hudak

February 2000

What it’s about

Solving programming problems using functional thinking

Why I love it

My favorite thing about this book is how the author takes multiple approaches when solving problems. That’s the way most good programmers I know work – they try out a few different things and pick the best one. It’s refreshing to see a book advocate that sort of work ethic.

Practical Common Lisp

Peter Seibel

April 2005

What it’s about

How to build useful programs using Common Lisp

Why I love it

It took me a while to wrap my head around some of the stuff in this book but after typing in every line of code and studying it I started to come to grips with Common Lisp and felt comfortable writing programs on my own with it. It also has a chapter on building a TDD framework, and you know I’m a sucker for that.

The Reasoned Schemer

Daniel P. Friedman

October 2005

What it’s about

Merging functional and logic programming

Why I love it

It introduced me to logic-based programming in the style that I loved about The Little Schemer and The Seasoned Schemer

Let Over Lambda

Doug Hoyte

April 2008

What it’s about

Hardcore Lisp programming

Why I love it

Section 1.1 is titled “Macros”

Land of Lisp: Learn to Program in Lisp, One Game at a Time!

Conrad Barski

November 2010

What it’s about

Having fun while learning Lisp

Why I love it

This is probably the most fun I’ve had reading a programming book, and it’s so deep. It starts you off with “so what are these parentheses anyway” and takes you all the way to writing web apps. Along the way you learn all about the features that make Lisp so powerful. Plus, cartoon aliens!

Learn You a Haskell for Great Good!: A Beginner’s Guide

Miran Lipovaca

April 2011

What it’s about

A crash course on functional programming using the purest functional programming language around

Why I love it

“A language that doesn’t affect the way you think about programming, is not worth knowing.” – Alan Perlis

I enjoyed learning about Haskell but it had always been sort of a tough nut for me to crack. This book made it dead easy to start writing simple programs in Haskell explore what makes it such a unique language.


Scaling

The Art of Capacity Planning: Scaling Web Resources

John Allspaw

September 2008

What it’s about

Scaling web software, by the guy who kept Flickr.com running while transferring everything over to Yahoo’s datacenters

Why I love it

It’s the nuts and bolts of figuring out how much scale you’ll need to handle and how to actually handle it. Even if you don’t work on something the size of Facebook (cause let’s be real here) there’s a lot of knowledge you can apply to the web app you’re working on. One of the most important points is how to make sure that you plan for the load you’ll actually have and not to waste time building added complexity to handle load you’ll never have.

The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise

Martin Abbott & Michael Fisher

December 2009

What it’s about

Scaling people, process, and technology

Why I love it

It’s a higher level book that points out that even the best technology in the world can’t save an organization from itself if they don’t figure out how to manage people properly. In that sense it’s 2/3 organizational scaling and 1/3 technical scaling.

Scalability Rules: 50 Principles for Scaling Web Sites

Martin Abbott & Michael Fisher

May 2011

What it’s about

Everything you need to consider when building web applications with scalability in mind

Why I love it

Every application has different forces acting on it that help or hinder the scalability. This set of “rules” teaches you how to uncover those forces and deal with them. It’s not just about implementing for scalability, but also covers how to plan your development process to account for discovering scaling requirements, and what to do once you’ve actually shipped the thing.