Open Source, Tech, and Tribalism

The open source community can be a turbulent place, and this turbulence often plays out in public. Periodically, people leave a community, and when they do, the swirling drama can be fun or bemusing from a distance. The “Why I’m leaving community X” blog post from a prominent Community X member is common enough to qualify as its coming-of-age milestone.

But recently, as I found myself and people I care about involved in one of these situations, I no longer had that bemused objectivity. Wait a minute, Community X is my community, and it was being harmed. I felt personally attacked. I watched others become defensive, which seemed to justify my own feelings.

As I started seeing lines being drawn, I realized that my reaction over someone deciding not to use a thing that I use was putting relationships at risk.

I had to stop and do some personal soul-searching around this topic, so I’ll try to be sensitive to the fact that others may, like me, have their identities wrapped up in the various communities and tribes they belong to. This is tribalism. It’s perfectly normal, but it’s crucial to understand, and I don’t think it gets its due when talking about open source.

A person could create a college-level course defining and exploring tribalism. For the sake of definition, I’ll leave it at this: Tribalism is the act of attaching one’s own identity to a shared group identity.

And it’s a tough one to fight: as a pre-programmed default, tribalism was key to the survival of the human species for hundreds of thousands of years. 

Coalitions, communities, tribes, and cults: a spectrum

Let’s call this the identity spectrum: the degree to which one’s identity is subsumed by the shared identity of their affiliation with a group.

Coalitions are, essentially, “frienemies”. A federated group of people, in Ayn Randian self interest, unite to achieve some common goal.

Communities are also loosely united by a common goal, but often act in the group interest above self-interest.

Tribes are communities that are bound by a shared identity as members.

Cults are a tribe that shun all identity except as a member of the tribe.

The tribe of open source

It’s easy to spot an open source developer from across a crowded room, as we usually broadcast our preferences. Borrowed perhaps from skateboarders, we wallpaper our laptops in stickers representing our interests. Everything’s fair game: Products we use, technologies we love, perhaps even our favorite My Little Pony character.

This was a big deal for me.

I’ve felt like an outsider for pretty much my entire life. Even my other “tribes” (professional, religious, etc.) never really fit me quite right, until, at 30 years old, I discovered a new sense of inclusion and belonging in the software community.

Like most tribal affiliations, I got some amazing benefits: lasting friendships, support, and a sense of purpose outside oneself. As a new developer I was welcomed, guided, mentored, and offered opportunities in a way entirely new to me.

And thanks to the network of open source developers on Twitter and elsewhere, I now know hundreds of wonderful people in cities around the world who share many of my interests, passions, and values. I can visit a conference on the other side of the country and be welcomed as if I was a longtime neighbor. It’s amazing stuff, and it deepens my faith in humanity every time I experience it.

And I should take a moment to note that I do not have the GitHub profile of a prolific open-source contributor. GitHub is not my CV.

I have my own ways of helping: writing, organizing, hiring, etc., and no one has yet stopped me to tell me I’m a fraud and kick me out of the community. In open source, your best is good enough. (Perhaps that’s just until you manage a popular project, but that’s another post.)

Tribal affiliation as a shortcut

The tribes I belong to offer some great shortcuts in describing myself to people: Rubyist, Javascript programmer, Embereño, Mormon(ish), Beatles fan.

These are great for allowing someone a small insight into my activities and interests. A shared interest in Javascript development means I’m probably game for interesting conversations on the subject. Knowing I’m Mormon lets people know I’m a pretty good bet as a designated driver.

But if I’m not careful, it can be easy to slide toward the right side of the spectrum, and start letting these shortcuts define who I am.

Bad tribal habits

If we’re not aware, we often fall into habits programmed into our brains from thousands of years before we were born. Here are some common net-negative tribal behaviors:

Blind evangelism: A sense that your tribe’s cause is a one-size-fits-all solution, and that the entire world would be best served by relentless evangelism until they join.

This allows you to feel confirmed in your belief, but it erodes empathy for the desires and needs of others.

Buying into one ecosystem: Have you ever been to the home of an Amway family (or lived in one, as I did)? All of their products are Amway. Is Amway shampoo the best? Their detergent? Eyeliner? It doesn’t matter, because the Amway families are so financially locked into the system it doesn’t make sense for them to buy anything else. (But if you ask an Amway family, yes, the Amway everything is the best.)

Using Windows makes me physically ill. Is Windows really that terrible? Or am I conditioned to think that Windows is terrible because I’ve spent a decade building an Apple fortress? Either way, counting business expenses, I fork over the cost of a decent car, every year, on Apple products.

Narcissism of small differences: Few things divide tribes more sharply than being ideological next-door neighbors.

It pains me greatly when I see communities (in religion and in technology… but I repeat myself) who all want the same thing bicker incessantly about the right way to do it.

Burning the heretic: People who speak against a tribe are often vilified. And you’ll rarely see as vitriolic a reaction as when a person leaves a tribe. And if they don’t have the decency to go quietly, they receive ten times the furor, thus justifying their decision to leave.

It’s enormously satisfying to burn the heretic. When someone leaves the tribe, they’ve just questioned our collective identity. Our rightness. Our specialness. The natural reaction is to fight back, and invalidate that person and their obviously wrong opinions.

But know this: Every time you defend a tribal identity, you sacrifice a little more of your own. And a tribal identity is incredibly fragile, encouraging defensiveness and fear.

Cult behavior: when tribalism turns evil

What’s ironic is that people who are opposed to a given tribe are themselves defined by tribalism. In fact, the notion of “enemies” pretty much only exists at the tribe/cult end of the spectrum.

For example, consider the childish, abhorrent behavior of those within the “Gamergate” pseudo-movement. It’s a form of tribalism carried to the “cult” extreme. They’ve spent so much energy defending an inherited group identity that their individual identities are completely subsumed.

This invites the mental laziness of stereotyping those outside your tribe, dehumanizing them to the point where violence becomes a natural-seeming option. Opposing, heretical voices so threaten the fragile identities of the group members that the offenders must be silenced.

It’s a textbook example of the danger and potential dark side in allowing a group identity to become your only identity.

Taking back your identity: a self-check

After all this, you might think I’d warn away from tribes and tribalism, but that’s not my point. The trick is simply owning your own identity.

Personally, I don’t enjoy coalitions. I have friends who say “get over it, these are just tools you use to make money”, and that’s great for them, but I like communities. I even like tribes, when I’m on guard against my biases. Cults, though… I’ve had enough of those for one lifetime.

Whatever your personal preference, my request, my plea, is this: be aware. Keep some self-check questions at the back of your mind:

Do you define yourself by your job? It’s easy to catch oneself saying “I’m Prestigious Title X at Recognized Company Y”. Or “I’m the creator of Cool Thing Z.” It’s incredibly tempting to lead with this stuff when talking (or thinking) about yourself.

Does your social media profile offer any hints? When given 140 characters to describe yourself, what do you say? “Cat expert, sandwich artist, alligator hunter”? I mean, that’s super cool, but are you 100% sure that’s who you are?

Do you perhaps feel like you are enlightened in a way that others aren’t? A good test of this is how much of your time you spend evangelizing the things you like vs. listening to things others like.

How do you react when someone leaves the tribe? Do you write them off? Get mad at them? Gossip about what a huge mistake they’re making?

These are your cognitive biases. It’s OK! They’re helpful in daily life. But becoming aware of them, while painful, is crucial. Every bias you recognize, acknowledge, and work to compensate for allows you to reclaim more of your individual identity.

What owning your identity buys you

As you internalize more of your own identity, it becomes less fragile, and you’ll find the freedom to enjoy the benefits of participating in communities and tribes without the same drawbacks. It increases your “cult resistance”, lowering your susceptibility to manipulation by sociopaths, which is pretty handy in the workplace.

You’ll be able to manage and maintain cross-community relationships, which often has a positive effect on all sides. You may even find yourself as an influence for good, helping focus community efforts away from tribal wars, and toward shared purpose and inclusion.

This is far from a complete formula, but separating personal from tribal identity is a crucial step in truly being yourself, which, as far as I can tell, is a key ingredient in living a happy, regret-free life.

A few cautions on open source and tribalism

When you’re part of a community, you’re an ambassador. Your responsibility is to embody the kind of community you’d like to see, because those are the people you’ll inevitably attract to join you. It doesn’t matter whether you like it or not, or whether you go on TV to say “I’m not a role model,” every public interaction you have is someone else’s window into your community.

When someone leaves your community, they’re not betraying anyone. People’s interests change. Their preferences change. They may even take occasion to vent frustration with your own community, tools, or ecosystem. That’s OK too. Related: if people defect from another community to your community, it’d be wise to let them know that disparaging their previous community is poor ambassadorship for their new community.

Get out of your bubble. I spent my first few years as a Rubyist feeling a sense of superiority to PHP developers, despite never having written a line of PHP. Now I’ve interacted with so many communities that I have a deep and abiding respect for anyone who builds things in the toolset of their preference.

Cross-community competition is less valuable than cross-community pollination. In free-flowing ecosystems, you get the benefit of people taking the best of a different community and trying to bring it to the new community. Tribes that prefer the “way we’ve always done things” miss out on these improvements.

And lastly, a piece of advice I received a few years ago:

Don’t yuck someone else’s yum. It can be unfathomable to me that someone would use some outdated, obtuse, or clearly-inferior technology to get their jobs done. If they’re doing it with a smile on their face, trying to make them realize how wrong they are is petty, egotistical, and unkind. I’m as guilty of this as anyone I know, and have worked to add “don’t yuck someone else’s yum” as a mantra for myself.

I haven’t yet seen an argument about tribalism that wasn’t also an argument against it. I hope this helps make a little bit of a case for the value of hopping into a shared culture and identity with people, just so long as you know who’s in charge of your own.

Letter to an aspiring developer

Nearly 18 months ago, a person emailed me out of the blue asking for advice on breaking into software development.

He was full-time student, trying to start a career in software development, but was paralyzed with worry of making the wrong choice.

My response was applicable, I think, to anyone trying to get into software, and I’m going to leave it largely unaltered.

I want to offer some thoughts based on what I see as main themes:

1. Getting your foot in the door in software development

I had to spend 2 years taking non-dev jobs, with the express understanding that my goals were to become a software developer, before I was able to assert my role in one job as a developer (after a pretty fierce battle to do so).

Just about any dev job you get is going to be just fine. Seriously, you can relax about that. The first couple are supposed to suck. If they don’t, you won’t know what you don’t want in your own company someday.

That’s not to say you should necessarily take the job in front of you, I’ll address that in a bit.

2. Setting long-term goals

You know how you have no idea right now which direction to go in? Get used to that feeling. Right now, a bunch of Rubyists are nervously looking around as they watch their platform stabilize while JavaScript takes off like a rocket. Nothing is set, nothing is guaranteed, and the notion of long-term goals is flat-out stupid.

It’s crazy. Eleven years ago my job was to get lunch for people, and I decided I wanted to be a graphic designer. So I got a Mac and got really good at photoshop and illustrator. Then I got a video camera, learned Final Cut Pro, and decided to be a video editor. Then I got MCSE certified and decided to be a sysadmin. Then I started writing website copy and got into marketing for 5 or 6 years. Then I decided to try to learn to program and here we are. I defy anyone to look at that and determine a pattern that could tell me what I should do next.

So no, none of us know where we are in 5 years. But what you do want is a platform. You want to have a set of internally-consistent values that, when followed, add up to the kind of person you want to be, doing the kind of things that make you happy.

Maybe, at your age, all you can hope for is to have lots of different experiences so you can observe yourself in lots of different situations to learn the things that excite and motivate you. I don’t know what that translates to when some douchebag asks where you see yourself in 5 years, but that question is dumb.

The only thing I know for sure is that 5 years from now there’s basically no chance I’m working for someone else. And I know I like helping other people understand their own capability. And I like building things. And I like technology. So advancing those things help me build my platform. At some point in the future, these things will converge in surprising and unforeseeable ways.

3. The role education plays in your career and future opportunities

I am SO the wrong guy to trust on this topic, but here are my thoughts. I dropped out of community college. It has closed the door on exactly zero things I want to do with my life. YMMV.

I work for a CEO who wants to only hire CS-grad developers. If you want to do hardcore shit, a CS degree is often the first hurdle hiring managers will set up. But here I am, college dropout, contributing alongside my CS-educated teammates. I’ve not run into a situation where someone has said “you have all the right experience, if only you had a degree”, while grads actually are likely to hear the opposite from time to time.

If I need to tell you why a bubble sort is inefficient or implement a binary tree search algorithm, I’ll just keep borrowing that knowledge from people who paid good money to go get it.

I’ve got a real problem with formal education in today’s world, and I’m sad to say that when it does matter, it’s about the piece of paper. Schools are no longer the institutions that push the boundaries of what is possible (they can no longer keep up)… that’s going to happen at your workplace.

Here’s what’s crazy to me: You’re becoming book-smart at school and street-smart on your own time. How in the world does that not make you completely unstoppable? (Hint: it does make you completely unstoppable).

4. The type of culture to select for

The underlying question is: how “you” can you be? You’re always going to deal with cultural values that don’t match your own in various degrees, but my time at my last employer felt extremely constrictive in that regard. It was like wearing a cultural straitjacket.

And you know what? It was totally fine. Glad for the experience. Wouldn’t do it again, but I have no regrets.

But developers are a lucky bunch, and get to pick the kind of places they want to work. You’ll soon be in a position to say “no” to a lot of places, and I’d recommend you evaluate culture on this alone: How comfortable are you being exactly yourself in this space? There’s stuff you value and do automatically, is it rewarded here? Or do you have to sort of pretend to be something you’re not?

5. Building your mentorship

I’ve received a bunch of advice by asking one-off questions at local meetups. But it all pales in comparison to that first couple of jobs. You don’t have to announce that you need a mentor. You’ll just work with smart people and steal fire from the gods.

With dedication and patience, this will provide a mentorship to you that will rival anything you could have done by taking one of these bootcamp-style “become a developer” programs.

It’s up to you to stitch it together, but you’re doing all the right stuff.

6. Practice shipping

When I was just getting started, I felt like I had to know everything about everything, so I could ship something impressive. This is ego and it is folly.

I remember a meetup where a new developer demoed his first public work, and I had to stifle a chuckle, it was so naively built, simple, and unattractive. And then I bit my lip in shame when everyone heaped praise on him, because he showed up and shipped software.

If you don’t yet have all the skills you need to ship your idea, you’re thinking too big. Start smaller. Don’t worry about the design. Don’t worry about doing it perfectly. Don’t worry that it’s unoriginal, elementary, or even embarrassing.

You’re on the second rewrite of your sample app? Did the first one work at all? Ship it. Did it almost work but not quite? Ship it. Was it ugly? Ship it. Untested? Ship it. “If it doesn’t embarrass you, you shipped too late.”

That lesson, the ability to let go of perfection and get something into the world, scales up as you become more broadly skilled. Learning that is vastly more important than learning proper CSS technique or TDD. True story.

7. College degrees are not for job applications

I very, very rarely offer blanket-statement advice to people. But here is some: you should go to college to learn and do the things that fascinate you. Period.

As time marches on, when it’s time to wave your piece of paper in front of someone, it matters less and less what that paper is for. Most of my favorite developers are former designers and writers. These are people who approach code from a variety of philosophical angles, rather than a predetermined set of problems that need the right algorithm to be solved.

You’re obviously a sharp written communicator, and that bodes well for you as a developer, as they’re strikingly similar pursuits in many ways. More importantly, communication skills open doors for you in areas of software that are typically closed to engineers who prefer to let their code do all the talking for them.

College is not the networking opportunity that it once was. That’s all extracurricular now due to meetups, groups, Twitter, etc. If CS continues to fascinate you, go crazy, but if you’d rather go into the humanities, philosophy, accounting, whatever, please do what your heart dictates and don’t put your as-yet-undecided career goals in the driver’s seat.

Lastly, a note about tailoring your degree to get jobs:

HR people post jobs. HR is a relic. HR is a joke. HR speaks buzzwords, degrees, and checks off boxes. Prerequisites like years of experience, technology-specific requirements, and even college degree requirements are a lie.

You’ll get damn few jobs through the traditional Apply => HR Screen => Interview process. Maybe your first couple. But it’ll snowball from there and it’ll all be your existing body of work and your reputation, until the only people that hire you are people that want just exactly you in a role that they know will suit you perfectly. So it’s pretty shortsighted to tailor your expensive, multi-year, potentially mind-expanding educational experience to please some resume-shuffling HR rep at one or two companies you’ll only be at for a year.

8. Switching jobs

I think a given developer is 6-12 months from being proficient in any language/framework of their choosing. Don’t let 5-to-10-year veterans intimidate you: many of them have had the same year of experience, 5-10 times.

In fact to prevent this, you should plan right now to switch jobs frequently (every 18 months or so), at least at first. You’ll watch your experience diversify and your pay jump up ferociously. (But don’t get addicted to the money… it levels off after that and studies show over $75K actually decreases happiness.)

So in essence: Ignore money, and pick the place with smart, helpful coworkers and a technology stack that you want to develop your skills in.

A note on self-effacing honesty:

What people refer to as “honesty” or “humility” in your cover letter (and your telling people in no uncertain terms that you’re “junior” in need of “mentoring”) is actually pessimism. Pessimism is a precursor to depression. Many of my bouts of depression can be directly traced back to prolonged moments of pessimism, masked as “honesty”. Go buy the book Learned Optimism. Seriously. Do it now. The book won’t solve all your problems, but it will open your mind to the idea that you have the ability to change these thinking patterns.

This self-effacing form of pessimism is one of my big downfalls, even up to this very day and minute. If you want to get a 10-year jump on me, start projecting an undeserved air of confidence, because you deserve it more than you currently know.

This advice is for me as much as it is for you: Stop apologizing for what you don’t yet know, and take some damn credit for being bright and hardworking enough to know it in the future.

I’d suggest trying to load that into your brain and taking another crack at your cover letter. You’re a startlingly bright dude, and I’m delighted that you don’t yet see your absolutely limitless potential, because I’ll get to steal some credit when you’re a big famous programmer.

There’s a lot more I’m sure I could say, but I’m too tired to think straight right now. I’m glad to know you and excited for your prospects.

To him, these choices were life-altering. Choosing one job over another, being rejected by potential employers, pursuing higher education… all these seem like life-or-death situations in the moment, but with the benefit of time & an external perspective, a person can relax about most of it.

This person I barely knew at the time is now one of my closest friends, and I think the advice was helpful. With the benefit of 18 months of additional hindsight, I’ll doubly endorse the words above for any aspiring or new software developer.

If you’re looking to break into software, hit me up here or on Twitter, I’m curious to gather people’s experiences and questions for a proper blog post in the future.

The question that made me quit the best job I ever had

"Great Wall" by akasped via Flickr

I was grinding my teeth, I was wasting my youth
And using up my teeth

Now, I’m done chewing my nails
Hanging my head, chasing my tail
It got so bad I quit my job
Then I got a new job climbing the walls

-They Might Be Giants, “Climbing the Walls”

I was haunted by that song. From time to time, I’d realize it described my exact situation at a job, and the song would get stuck in my head. I would “vaguetweet” the lyrics, hoping to express the faintest shadow of the existential malaise I actually felt, while hoping my bosses didn’t realize I was scouting for the next job.

Yet this was a massive improvement over my prior situation.

I’m going somewhere with this, but I’ll have to start at the bottom.

Bottoming out

Four years ago, I was on the marketing team for a company that we all knew was (very slowly) circling the drain. Nearly every time a meeting was called, my heart would race, and the halls filled with chatter about whether people would be laid off. This had gone on for years, but I felt unemployable enough that I didn’t see an option but to endure and agonize.

On this particular day (December 30, 2009, but who’s keeping track), they brought the designer and me in, the last of the marketing team, and let us go. I put on a brave face, but I was crushed. I’d poured years of my life into the company, and they’d rejected me.

I cleaned out my desk, said a few goodbyes, and went home to an empty house with my wife at work and my 1-year-old in daycare. I heard a strange noise, as if someone was running the shower, and came downstairs to find that a hot water pipe had burst, caving in part of the ceiling and flooding my basement with five or six inches of water.

Gravity seemed to instantly quadruple. I collapsed into a chair, surrounded by water, unsure of how I would deal with everything that was happening, and sobbed.

But as one does, I quickly shifted into management mode, shutting water off, calling a cleanup company, contacting insurance, arranging a place to stay with family. Within a few weeks, the house was livable and I was in a new job.

Waking up

Being laid off was miraculous. First, I learned that losing my job didn’t kill me. My spouse didn’t leave me. We didn’t get our house repossessed. My kid was as happy as ever. The flooding thing was probably not a direct result of losing my job, so we’ll chalk that up to coincidence.

Just as importantly, I learned that I could interview for, land, and perform a job to the satisfaction of the people that hired me. That may sound obvious, but it was a revelation after being beaten down by a job culture that essentially said, “where else are ya gonna go?”

Most of the fear that had paralyzed me into staying in a terrible job for years was just gone. I was employable.

The seven-month itch

I’d been working toward becoming a professional programmer, a goal that seemed out of reach to me at the time, so I took a job that I thought would get me closer to my goal.

(The “breaking into the software development game” post will have to wait for later, but I was very lucky to have friends who guided me through this process, including Dave Brady, who is so good at this he’s writing a book.)

In short, after becoming disillusioned with the broken promises at one job, I’d move on to another. And then another.

I was grinding my teeth, I was wasting my youth, and using up my teeth

— Brandon Hays (@tehviking) July 28, 2011

All in all, over the course of 3 1/2 years, I took (and quit) five jobs, ranging from 3 to 14 months. But a pattern did start to emerge: at each job, I’d start with excitement and optimism. After a few months, I began to notice an organization’s problems, which would then fade into a general sense of anxiety and frustration, rooted in the fact that the company was a mess and there wasn’t much I could do about it.

I’d sit in the parking lot, staring at the building each morning, working to summon the will to go inside.

“I was grinding my teeth, I was wasting my youth, and using up my teeth…” @tmbg‘s “Climbing the Walls” regularly makes me rethink my life.

— Brandon Hays (@tehviking) December 21, 2012

I always saw myself as a responsible, dependable person, so it was very difficult to look at this and wonder if the problem was me. But each time, typically after a six-month honeymoon, I’d start looking around and seeing my workplace’s dysfunction and a deepening sense that I was just in the wrong place. I’d work to improve things, then try to fake it for a while, and ultimately, I’d leave.

The dreamiest dream job ever

Then, after leaving yet another dysfunctional company, a good friend helped me find my dream job. It ticked off everything I could possibly want. Working from home on a 100% remote team. Great compensation. The opportunity to learn from some of the kindest and most intelligent people I’ve worked with.

I spent a lot of time pairing with amazing developers who also happen to be good friends, leveled up my skills as a programmer, and felt valued for bringing my own unique flavor to the team.

And my boss! He is, to this day, the best boss I’ve ever known. No one is perfect, but I could (and definitely should) spend an entire article examining what sets him apart. But in short, he is kind, empathetic, and sees his role as a protector of a team’s autonomy from organizational pressures. His reputation precedes him in this regard, so he attracts some amazing people to work with him, creating a virtuous cycle.

In every area, professionally, I’d finally hit the jackpot. To this day, I thank my lucky stars (and that good friend) for the opportunity to work on a team like that.

There’s simply no way the four-years-ago version of me, sitting in a chair, sobbing, could have even dreamed that I’d find myself in that work situation.

Things were going great. And then I quit.

What is wrong with me?

Believe me, I resisted. Strongly. I didn’t want to quit this time, honest.

I’d interacted with an open source developer several times over the last few years, online, and then in person after moving to Austin. He stuck out to me as someone uniquely worth listening to, and I was struck by how kind, empathetic, and whip-smart he was in our interactions.

Everything about it was less attractive on the surface: It wasn’t remote, less flexible, more work and stress, and a huge (over 50%) cut in pay. Initially, I was firmly against the idea.

But these conversations started gnawing at my subconscious, and a sense began to grow in me that I was heading down a path that wasn’t mine: a path of comfort at the expense of seeking my own destiny.

The deciding question

For me, it came down to one question:

“Will I regret not having tried?”

I was actually angry to have to admit that the answer was an unequivocal “Yes.” I couldn’t run from that fact.

There are a lot of reasons backing that up that I won’t delve into here, only that my heart knew with crystal clarity something that took me weeks to begrudgingly admit to myself. That I prefer adventure to comfort. That I can’t be happy only exercising a small portion of my capabilities, no matter how great the other circumstances are.

What I’m up to now

So I quit my dream job to help run a software consultancy. My boss, in typical fashion, was amazing and magnanimous about the whole thing, even though I was very embarrassed to leave so soon after starting.

So now, I’m working with The Frontside, an Austin-based software studio focusing on Ember.js and Ruby on Rails applications. We think we’re on the leading edge of the next wave of web applications, and it’s been a thrilling ride so far. I think the two of us can’t help but build something special, and I’m excited to start showing it off to the world.

My partner, Charles Lowell, is a mensch. I’ve learned so much from him over the past few months, not least of which that running a business is hard. From sales to hiring to the technologies I work in, the learning curve has actually been incredibly painful. But those lessons will have to wait for another day.

So what’s the point?

So am I telling you to quit your job? Obviously, that isn’t the point… you could quit any number of jobs without growing as a person or advancing in your career. Here’s what I want you to get from this article: It’s time, right now, to think hard about the next step in your career.

The next real, meaningful step is not a title, salary, or lifestyle upgrade. Those are side effects, and rarely (if ever) wind up justifying quitting one’s job.

The meaningful steps include things like:

• a greater understanding about what you want and what you don’t.
• new relationships and friends for life.
• lessons that deepen your character.

I used to feel permanently glued to my job, so when I lost it, I felt like I’d lost everything. Since then, I’ve learned when to stick with a job and when to quit, and they’re counter-intuitive. It was time to stick it out when I was at my most frustrated. The lesson I kept having to learn was how to shape my environment, and more importantly, myself, to find happiness amidst the chaos.

Once it felt like I’d learned the most challenging lessons and things started to click into “autopilot” mode, my heart told me it was time to move on. And each subsequent move has brought with it even more perspective and relationships.

I don’t know what’s next for me. I am excited to see if I can put my money where my mouth is and build the business I always dreamed of working for. I do know that whatever happens, having tried is one less regret I’ll have, and I haven’t for one second felt like I was “climbing the walls” anymore. That’s gotta be worth something.

Benji’s priority box

Last week, I lost a close friend to cancer. Benji Edmund was the best of us: Kind, cheerful, inclusive, and irrepressible.

He was a nerd of nerds: he fully owned and embraced the things that made him different, and did them better than most of us. He also embraced the things that made others different, and brought people together from every area. It was no surprise to me to see a huge group of people at his funeral, each touched by him in some way.

All this week, I’ve really resisted the urge to analyze his life and try to draw lessons from it, because I mostly just want to be sad and hurt, to wallow in the unfairness of losing him.

But after seeing his family and friends selflessly share what they learned from him, I feel compelled to point out some of the ways Benji was so special to me.

Living without regret

It’d take much more than a single blog post to describe the ways he inspired and influenced me, so I’ll focus on one or two things that are on my heart.

At his funeral, people shared what they admired about Benji, things I thought perhaps only I’d noticed. He had a genuine confidence that came not from lack of fear, but from understanding that he could accomplish anything if he simply never gave up. In the 8 years I’ve known him, I’ve never, ever seen him give up or back down from an intimidating task.

What struck me most, though, was that after he learned that the treatments weren’t working, he looked at his life and declared he was happy with the result. He said he was proud of his family, proud of his career, proud of his hobbies, and wished only that he’d had more time to keep doing what he’d been doing.

How many of us can say that? How many of us are so contented that if the worst happened, we could say we lived without regret?

Benji’s priorities

His peace of mind was no accident. Ultimately, Benji’s greatest tool in living a happy, fulfilled life was his perfectly clear set of priorities, and his rigor in defending them.

Benji’s family always came first. He was like a superdad. Being present for his family was never a question, and there was never any doubt that his wife Heidi and kids came first. He didn’t wear a badge saying this, and never uttered the phrase “my family comes first”, but everyone knew where he stood.

Although Benji’s work took a permanent backseat to his family, he always rose to the top and excelled at every career turn. He always managed to pick a professional challenge that was just outside his grasp, and was willing to leap from a place of comfort, trusting that he’d somehow make it to the other side. He took genuine joy in his work, and everyone that worked with him remembers him as the “glue” that united everyone. At a relatively young age, he became highly sought after for anything ops and devops related.

Benji’s hobbies were equally impressive. If he was into it, he was really into it. He also seemed to prefer hobbies that he could share with other people. Video games, brewing beer, movies, music… he was never content to keep them to himself. He preferred relationships and experiences to “stuff”, trotting the globe with friends and family while still driving his same busted old Ford Focus the entire time I knew him.

Defending his priorities

It’s not enough to know your priorities, you have to defend them. And Benji defended his vigorously.

Benji’s family-first philosophy, to the 25-year-old version of me, seemed weird. He would frequently turn down offers to go hang out, he wanted to go straight home to his wife (and later, his kids). If we wanted to do something, we were welcome to come over and spend time with his family.

At the time this was hard to understand. But with hindsight, it was a master class in understanding and defending your priorities.

Benji’s boss, the CEO of Instructure, spoke at his funeral and told his story of recruiting Benji. It took months, because he absolutely would not jump over to this new startup until they had health and life insurance benefits buttoned up. He simply would not make that sacrifice. I’m sure this seemed inconvenient or even odd to the team there.

But for Benji, this was a simple decision, because he took his priority list, put a family requirement up against a work requirement, and knew which one would win.

Shaking the box

Clay Christensen, in How Will You Measure Your Life, talks about understanding long-term vs. short-term gains in your personal life. The benefits from sacrifices on behalf of your family can take years or even decades to come to fruition. Work and other pressures can offer immediate benefit and immediate consequence.

So when it’s time to look at our priorities, we often sacrifice these long term benefits for our family, knowing they will understand. Instead, we often choose short term gains to placate the people who won’t understand (a boss, for example).

I imagine priorities like this: imagine writing every thing that is important to you on a slip of paper. You probably have a sense of their order, and after ordering them, they go into a box.

However, there are 2 unavoidable challenges for your priority box. First, over the course of time, more things will become important to you, and you’ll start adding more slips of paper. Second, at random intervals, life will come and shake up your box. You can’t prevent this, nor can you predict when it will happen.

So the construction of this box is of utmost importance. But most of us just leave it the way it is, a simple box containing all the stuff we care about, and the thing that seems most important at any given time is plucked out and given our time and attention.

What was different about Benji’s priority box

Benji, however, built compartments into his box, keeping his priorities from being mixed up. Benji took great care with the construction of his box. He recognized it for what it was: the container for all that he cherishes and the only tool he has to protect his most limited resource: his time.

So yes, more pieces of paper were slipped in, and life came and shook his box with all its might. But Benji never had any doubts about which activities got the bulk of his time and attention, because they rested in their appropriate compartments.

It’s shocking to me that Benji understood his long-term priorities at such a young age. He’d set up his hierarchy pretty much by the time he’d graduated high school. He married his high school sweetheart, placed her at the top of his list, and never, ever took her (or the rest of his family) down.

I can say with some confidence that this was Benji’s formula for a regret-free existence.

I’m not proud of my priority box (yet)

My box is shoddily constructed at the moment. I have a lot of mixed-up priorities, coming in faster than I can handle them, and little sense of how to put them in order. But I now have a model to follow for choosing how to build my compartments and protect the things that I cherish the most.

I can’t express in words how broken my heart is right now. My heart hurts for my loss, for the pain his family is in, the long road they have ahead, for the loss the world experienced by losing him. But I can take a small measure of comfort in knowing that Benji truly lived his life, with kindness and on his own terms.

I love you forever, Benji. I miss you terribly. Thank you for reminding me to live and love without regret.

What’s so great about getting things done?

Each of these contains months- or years-old tasks that now exist solely to mock me

One of the fundamental principles of marketing is to sell relief from pain. So it’s no surprise that Getting Things Done has become a perennial phenomenon.

It offers the promise of freedom from the feeling of being buried beneath a task list that grows faster than you can cut it down.

It’s a nearly ubiquitous pain point. We have more things to do than we can keep track of, let ourselves get overwhelmed, and give up before accomplishing our goals.

And for its adherents, GTD seems to deliver. They are finally able to climb up out of their to-do-list deficits, feel less overwhelmed, and regain a sense of control over their work.

As for me, I could never finish the book. Maybe it’s the corporate-speak delivery, or more likely my own life situation, but I just can’t seem to get into it. I have studied it through vicarious means, via podcasts, cheat sheets, tutorials, etc.

Organizational systems are overrated. There, I said it.

Every organizational tool, system, or book I have tried has either failed me or I have failed it. The tools on paper, computer, and smartphone I’ve used comprise an elephant graveyard of dashed hopes.

My track record over the past 15 years proves this out, from Franklin Planners, to notepads, to desktop software, to writing my own pomodoro-based todo web app, to GTD, only to expose my own lack of discipline by giving up and going back to my old ways.

I ran through the OmniFocus tutorials and implemented the whole system: setting up contexts, projects, assigning next actions, toggling context based on my location, and it all seemed great, but it just didn’t click for me. I just couldn’t get emotionally invested in the reward cycle for accomplishing stuff past a month or two in GTD or any other system.

And yet, my life is not an aimless train wreck of unaccomplished goals. So what gives?

I’m a bit concerned about the “things” part of GTD.

I’ve now spent the last several months doing nothing but getting things done. Tasks checked, issues closed, code written, yaks shaved, and I’m pretty proud of what I accomplished in that time.

But for all the stimulation I got from this time of hyper-productivity, I’ve also created a tremendous emotional debt by ignoring friends and family, and have been blind to other opportunities in my life. I’ve managed to become so dependent on the mental “cookie” I’m awarded for productivity that I’ve forgotten to be present for the rest of my life.

It’s ironic that many of the most important activities in our life don’t seem to fit in our todo list backlogs. Things like truly listening to a friend, helping out with the dishes, or taking time to build a lego fortress with your kiddo don’t stack up against “call Janet to get forecast numbers for Q3″

Short-term vs. long-term optimization

Life is about a lot more than the buzz we get from short-term accomplishment, yet we tend to torture ourselves over leaving near-term tasks unchecked. Or, we pat ourselves on the back for all the things we accomplish within a given workday, not realizing the decades-long effects of what we’re ignoring in favor of these near-term goals.

Clay Christensen explains better than I could about this optimization for “near term” versus the “long term” (check out the video at the end of this post).

Achievement = purpose + effort

I believe people are capable of profound productivity when driven by a sense of purpose and desire. For me, when I’m in “purpose mode”, things are crystal clear, and I’ll plow through uncertainty and obstacles to accomplish something. But often in my work, I shuffle around and pick at things without feeling like I am making progress.

To me, GTD is too often about trying to reduce the amount of perceived effort to accomplish things we don’t necessarily care about. I can take these things I’m shuffling around, apply GTD, and suddenly have a plan of action to accomplish this thing I don’t feel like doing.

But long-term, meaningful achievement means directing your effort to things that are truly connected to your own sense of purpose.

For me, the solution has been to figure out how to go back to the root and care about what I’m doing. Sometimes that means crumpling up the work I’ve done on things I don’t care about to start from scratch on something I do.

Overcoming overwhelm (without neat little boxes)

But what about that sense of being overwhelmed that GTD solves? In my experience, GTD’s main benefit is that it helps you make a perspective shift: moving your view of things to be done from a vertical wall (now) to a horizontal path (over time).

It’s not easy, and it’ll have to remain a subject for a future article. But suffice it to say, I don’t believe it requires the implementation of a “life management system” to achieve this perspective shift.

How about “Getting Thing Done”?

Maybe instead of beating ourselves over the head daily with all the things we *must* do, we should pick up one, exactly one, thing we would like to have done or have made meaningful progress toward by the end of the day.

I have tried this pattern in my life, each time to a surprising amount of success. A lot of the meta-stuff will take care of itself (checking email, responding to calls, getting my oil changed, etc.), but allowing myself to focus on only one significant accomplishment a day actually causes me to get more done in the course of weeks/months than when I’m trying to check off properly-broken-out tasks all day.

Some friends of mine (I found out, coincidentally, after writing several drafts of this article) are creating a new iPhone app, tentatively called One Thing. It won’t be ready for a little while, but it certainly sounds like a better fit for me than tools that promise to become a wellspring of focus, until they become a stagnant pool of tasks begging for my attention.

I can’t quit you, ubiquitous capture

One component of GTD will stick with me for the rest of my life: I love ubiquitously capturing thoughts, desires, goals, and fragments of information in tools like Evernote. It’s just the “getting things done” component of GTD that didn’t work for me.

Not that writing todo lists is useless! I do think that writing down all the important stuff you need to get done is a good exercise. Then, a few years later, go back and look at it, and have a good laugh at all the things that seemed so blasted important at that moment in time.

Lastly, please watch this video of Clay Christensen speak about living a life of purpose by moving our focus beyond the near term.

Closed allocation: A failed system of control

A couple of years ago, I found myself boxed into a corner. I wanted to become a developer, but my workplace kept pigeonholing me into a management role, where I would break down (very important!) tasks to give to our other, more experienced developers.

Thanks to an intervention by a brutally honest friend, I found the strength to basically quit one (very important!) job internally to become a developer. I got to stay at the company, but took on an entirely new role, letting the old one languish and die. This was very scary at the time.

Then, six months later, my prior (very important!) position was eliminated and everyone else performing it was laid off. But I had left that role to become part of a central, truly indispensable team that was regarded as the engine of innovation for the company.

All the stuff that the organization told us was critical was actually of no long-term benefit, even harmful, to the company. The worst part is that we, the performers of those jobs, knew this, but couldn’t do anything to change it.

This is the curse of closed allocation.

The article: You should read it

A couple of months ago, I read an article by Michael Church that gave voice to many of my recent thoughts on company culture. It challenged me, and although I disagreed with some of its prescriptions, I believe it’s well worth your time.

It also taught me some labels for a critical distinction in corporate cultures: open allocation vs. closed allocation.

These terms help define a unified theory that pulls together the differences between older-industrial-revolution-era cultures (think Goldman Sachs or the military) and post-internet-era cultures (such as Netflix, Valve, or Github).

Open vs. closed allocation: what’s the difference?

Closed allocation is the traditional system of having organizational leaders translate a company’s mission into a specific set of priorities and projects, then creating a management layer to break these down into tasks, which are then delegated to employees.

Open allocation is a radically different system of having organizational leaders communicate the company’s mission to all employees, skipping the management layer, and offering the employees complete self-direction and self-organization.

Closed allocation relies on a scarcity philosophy and zero-sum math. There are so many things to be done, and so few hours. Employees should leave the decision-making to us and perform their tasks quickly and well.

It’s also pretty cynical: If people aren’t told what to do, they’ll do the wrong thing. If they aren’t monitored and prodded, they won’t do anything at all.

Open allocation systems operate on an abundance mindset and exponential math: If people buy into our goals and apply their passion and talent, they’ll uncover paths to success that we can’t even envision. 

Open allocation is the Trust portion of the culture triangle carried out to its maximum. If we entrust our vision to good people, they’ll focus on solving problems that are truly high-value.

What about drudge work? Doesn’t it just pile up?

The number one fear I’ve heard from people regarding open allocation is “but what about the work no one wants to do?”

First, it’s important to break these kinds of work apart.

Michael defines a matrix along two axes: A work’s importance to the business and its pleasantness.

I. Pleasant/Unimportant (R&D) Developers are all too happy to experiment with new techniques and technologies, or to rebuild an existing system from scratch. Google calls this “20% time”, and open allocation shops don’t place a limit on it. While activities in this quadrant don’t appear to have immediate value, letting developers “play” produces incredible long-term value for businesses. In fact, nearly every major innovation from Google in the last 5 years has been from this “20% time”.

II. Pleasant/Important (High-visibility projects) Shipping new features is fun, and there are plenty of intrinsic organizational rewards. Knocking out a bunch of small, quick bugs or features carries an immediate, visceral reward. Both open and closed allocation systems do this well.

III. Unpleasant/Unimportant (Junk pile) Developers, by default, will avoid unpleasant tasks that add no value to the business. It’s why they hate meetings like vampires hate sunlight. (Some developers hate sunlight too, but this is unrelated.) A huge amount of time in closed allocation systems is wasted here, and it’s virtually eliminated in open allocation.

IV. Unpleasant/Important (Maintenance) I’ve sometimes heard the term “maintenance developer” used as a pejorative. But developers doing “maintenance” are the unsung heroes. And here we are. This is what people fear losing by moving to open allocation.

First, let me attempt to unburden you of the belief that this work gets done or done well in a closed-allocation system. Most likely, this work is being picked at and pushed around like the steamed carrots on a 4-year-old’s dinner plate.

And this is where Michael and I part ways. His advice is to incentivize, which is yet another tactic that has been proven to have the opposite of its intended effect. (You’ve probably already seen this video, but it’s a great, concise explanation of why.)

What I’ve noticed is that if you have a collaborative team, the unpleasant tasks carry their own intrinsic rewards within a team. The deepest desire of many of my favorite developers is to make their work and that of other developers easier and less tedious.

It’s only in closed allocation systems that developers quietly accept work that comes to them on a conveyer belt. In open allocation, developers will automate the work that comes in via conveyer belt so they can go do something more interesting.

Competition between ideas, not people

When what you work on is not your choice, the only influence you have is to try and compete to get better work. People compete to avoid doomed, unpleasant, or unimportant projects and to get assigned to high-visibility, high-impact work.

In fact, management often views this as a valid mechanism of control, and actively fosters competition between teams or team members.

In a closed allocation system, people compete for the right to work on good ideas, while in an open allocation system, ideas compete for the right to have people work on them.

Competitive environments add an unnecessary layer of stress and interpersonal discord among team members. This leads to burnout, causes good people to leave, and inspires people to put their energy into “managing perceptions” rather than producing excellent work.

My experience is that the only environments that create lasting value foster a collaborative environment where the reward structure is tied to making your team better, rather than being better than the rest of the team.

Either way, a company will grind something up in the course of making progress. But it’s up to leadership to decide whether ideas or people are the grist for that mill. And grinding people instead of ideas turns out worse products. You’d think this would be an easy decision, right?

If open allocation is so great, why are so few doing it?

Closed allocation is the default for almost all companies. If open allocation is so superior, why hasn’t it immediately become the go-to organizational structure for new companies?

First off, almost every company starts with open allocation. It’s the DNA of a “startup” or “small business”. But amazingly, no one seems to notice as the open allocation inherent in a 5-person company starts closing up, management starts getting injected to wrangle the chaos, and employees start losing their voices and autonomy.

But the question stands: Why is closed allocation the dominant philosophy?

• It’s how you manage people who don’t want to be there. If someone’s job is to sew a boot to its sole at a rate of 500 per day for minimum wage, it’s conventional wisdom that they require external motivation to stay on task at maximum efficiency (although this is debatable).
• People are conditioned for closed allocation. Public schools, churches, and most areas of modern Western society condition people that how their time is spent is ultimately decided by those “in charge”.
• Change is scary. Every part of every organization is highly optimized, even dependent, on closed allocation systems. Most people in closed allocation systems fear the increased responsibility of an open system, even if they’d excel in it.
• Lots of other reasons. It’s a mechanism that provides stakeholders with a feeling of control over chaos. It protects people who make decisions, even if they themselves are unneeded. (When have you ever heard of a management team opting to lay itself off?) Maybe the company is hiding from the fact that it has no compelling vision. But ultimately, the fact is that everyone in a closed-allocation system eventually buys into it, even if they complain about it.

But how do I know who to fire?

This is the other question I’ve heard about open allocation. How do you know which employees are valuable and which are harmful without targets, measurements, or stack ranking? Michael Church’s article covers it well, but in short: you’ll fire fewer than you’d think. People will find more ways to contribute in an open allocation system than if they’re pigeonholed into a rigidly-defined role.

Open allocation systems only let go of the people who are so political, passive aggressive, or poorly-performing as to cause a serious morale drag amongst your other team members. It will be obvious who doesn’t fit in your open allocation system, because their team will share a set of concerns and will have tried everything they could think of to make them successful.

Ignoring this can cost you your best people, even your business

At most companies, try to talk about turnover, and you may be shocked to encounter a “fingers-in-ears-lalalala-can’t-hear-you” level of denial. But this makes sense in closed allocation companies.

To confront how, when, and why employees might exercise their right to leave is to realize that 100% of the control closed allocation offers is an illusion. Each human being has a limited tolerance for being treated like a puppet or a cog. And at some point, they’ll run out of tolerance and find a reason to quit or be fired.

Losing key employees is the most expensive thing that can happen a company. Finding, training, and growing talent for knowledge work is ridiculously expensive. That’s to say nothing of the fact that at smaller, wobbly-kneed startups, high turnover could sink the company.

By the time you actually start experiencing turnover, it’s already so late in the cultural decline that no one seems to know what to do. So, executives tend to go into deep denial.

Can’t I just use some components of open allocation?

Short answer: No.

Much like any ground-up rethink of an existing system (such as the Getting Things Done system or the Paleo diet), you can’t sample pieces to see how they work individually. It’s a package deal.

I’ve been inside multiple companies that decided to “try out” these open allocation systems. And I can promise what will happen is company leaders will quickly realize that almost every person in the building is dependent on this closed allocation ecosystem, and go back to what was comfortable. Every time.

In fact, I can’t point to a case study of a company ever converting, in part or in full, to open allocation from closed allocation. I’m not saying it’s impossible, but I can’t advocate it. What I am advocating is that high-performing people start selecting themselves into open allocation environments, and as they found companies, to build and protect an open allocation system within them.

I’m stuck in a closed allocation system, what now?

Unless you work in a 5-person startup or the government, chances are that your workplace is someplace in between these two extremes, with a strong bias toward closed allocation.

First off, you should know that you have more room than you think if you throw some elbows around and redefine your job. If you’ll take a bit of risk, you’ll find more ability to define your own job than you previously thought. If you assert yourself as someone who understands your job well, and that you understand the company’s goals, you’ll find yourself with more input into the kind of projects you work on and they way you do them.

The sad truth is that ultimately, if you are a high performer, you will find yourself out of patience with the system you’re in. If you’re not careful, you’ll let this frustration drive you into the arms of another closed-allocation system, unaware that the cycle is simply beginning anew.

But I hope you’ll break the cycle and select for open allocation cultures (or go start one yourself), rather than reacting by simply job-hopping.

Who should switch to open allocation?

Imagine your employees, highly engaged, working on the exact thing that rings their bell, finding novel solutions to your most important problems, and pushing your organization closer to its ultimate vision, automatically, without needing to oversee every detail.

This is the promise of open allocation. If your organization has a true vision and a culture of honest feedback, you stand to benefit greatly from this style of management. If you lack either… well, open allocation might not be a fit.

But if you run a shop that you’re confident has vision and feedback, you may wonder if it’s possible to try at all. You could create this type of team that reports directly to the CEO and that has full autonomy, but not without majorly disrupting the rest of the organization, which I’ve seen inspire jealousy and backbiting. It’s treacherous territory, but if you’re bold enough to try it, you’ll discover that you can attract and keep the kind of talent that does great work autonomously.

Lastly, if you run a closed-allocation shop, make note of this warning: Open allocation shops are so fast, so nimble, and have so much energy that if a competitor runs one, they’ll someday be the Muhammad Ali to your Sonny Liston.

You get to choose which to be, but make no mistake, you will be one or the other.

Ali vs. Liston by Dave Rr via Flickr

LivingSocial, knowing your business, and gloating

Yes, LivingSocial is imploding. Yes, we saw it coming. Yes, we knew that the multi-billion-dollar valuation was silly and to be short-lived.

It’s easy to be snarky. And fun! I get a laugh from my friends, I get to show how smart I am for having “seen it a mile away”, all from the comfort of my armchair, having taken no risk.

But when I participate in such snark, I also feel a bit hollow inside. Because I know people, human beings, work there. Hell, I know people who work there. And sarcasm and snark only pile on insult for these (typically) innocent people.

And an additional danger: flippant, snarky responses are rooted in an “I was right” mindset, preventing us from learning anything more. But there is always more to learn.

My daily deal near-miss

A few years ago, I helped create a startup with some pretty audacious (and ultimately insane) goals. Things weren’t panning out with the original, mathematically-impossible business model, and we discussed “pivoting” into the daily deals space.

It was around then that my pre-arranged 3-month contract came up, and although I received some pressure to stay, I made the decision to leave, while my friends stayed behind. And their daily deal business started to catch fire.

I watched their office jump from 3 to 5 to 10 to 50-plus employees. I still held a significant stake in the company and wanted to see them succeed, but something about this rate of expansion concerned me. In fact, a friend of mine worked there for exactly one day before the environment creeped him out to the core and he quit.

My friends told me that the company had to expand quickly, that everyone in the daily deals space was growing more quickly than was sustainable, because only the largest survive, while the smaller firms would wither and die. (Interestingly, the opposite seems to have happened.)

Their work environment disintegrated as the pressure ratcheted up, paychecks started bouncing, and the entire thing became a news-worthy fiasco. I was comfortably off in another position elsewhere, but it still broke my heart to see my friends suffer (and to toss yet another worthless stock grant into the shredder).

Don’t let bad business models catch you by surprise

One lesson in this is simple: Take the time to analyze the business model of the companies you choose to work with. Do they make money? From whom? Who benefits? Look at the founders. Are there happy customers in their wake, or a string of disappointed people?

Do a gut check. Does it feel right, or does it feel like you’re selling out a little? You know, that feeling when you put that thing you want, but don’t need, on a credit card? The trading of the long-term consequences for an immediate thrill?

If you get that second feeling, stop. Weigh it more carefully. You may not change the decision, but your reasons need to be much more clear, or you’re creating a recipe for regret.

Being right is not a license to gloat

The other lesson is for us spectators: Maybe let’s stow the sarcasm on this one. For a lot of people, LivingSocial’s (likely) collapse is going to be very personal and very painful, so please take a moment to remember that before dancing on its grave at the expense of human beings who are hurting.

Dumb stuff we say to non-programmers

Nearly fifteen years ago, I left my home to serve a two-year Mormon mission in Minnesota and Wisconsin. But one does not simply walk into the “mission field”. They must first spend three weeks at the LDS Missionary Training Center in Provo, Utah, which is probably best known for its unlimited supply of Marshmallow Mateys.

In the sixteen-hour-a-day crash course of the “MTC”, one major recurring theme was on using language that is familiar to the listener, rather than Mormon terms and colloquialisms.

In fact, it’s quite easy to spot members of the LDS church that have had this training, as they tend to use terms such as “congregation” (in the LDS church, this is referred to as a “ward”), “lay minister” (“Bishop” in Mormon parlance), or “church responsibility” (known as a “calling”).

There are scores, if not hundreds, of such “insider” terms woven into Mormon culture.  Imagine my disappointment after joining the church at age 11, upon discovering that not only was there to be no steak at steak conference, but also that stake conference was a two-hour-long marathon of back-to-back sermons.

The LDS church knows what many of its members do not: that the language you use has the power to invite people to participate or to shut them out.

There’s no “PTC”

Programming has a much larger, much more deeply embedded intrinsic language, except there’s no Programmer Training Center where ambassadors from the world of programming are taught this essential principle. Perhaps there should be.

One of my regrets is that at a prior company I never got to hold a training session I’d planned for our development team, where our accountants would come talk to them in tax code, to convey a sense of what developers often sound like to their coworkers.

It’s not that insider language is bad. It’s quite necessary. The fact that police communicate urgent information via short, numeric codes actually saves lives. For the rest of us, our jargon provides invaluable shortcuts when discussing complex concepts within a group that has a shared background and a similar level of understanding. Developers, in their efficiency, cram oodles of meaning into words and phrases that sound like total nonsense to non-technical folks.

But even knowing this, I often catch myself spouting jargon and terminology that draws blank stares from less-technical people around me.

Terms that shut out non-programmers

It’s hard to keep in mind that you’ve accumulated your vocabulary over years, or even decades, and that people around you may not share that same type or level of experience.

But even more difficult is the mindset change that requires modifying, defining, or even skipping terminology to accommodate people that don’t share your technical background. Here are some terms that triggered a sense of being “locked out” of programming conversations or intimidated me as a new programmer:

• Algorithm: That word’s pretty big for its britches, considering it just means “a solution” or “a way to get to a solution”.
• Abstraction: It’s a great term for programmers, but “stepping up/back a level” may suffice for non-technical folks.
• Interface: Another fancy way to say “the way two things talk”
• Parse/parsing: Another great term that is tough to unpack. The closest I can define is “to digest”.
• Boolean: It’s just true/false, except when it means something completely different.
• Design patterns: I don’t know how the Gang of Four did it, but they somehow created a naming strategy that is 100% guaranteed to make a non-programmer’s eyes glaze over.*
• Parts of your technology stack: Unless for some reason you need to explain a technology, its purpose, and its benefits and drawbacks, it’s not helpful to let non-programmers know you’re going to create a Git topic branch to migrate your denormalized serialized data to a REST-based document database while preserving your Solr indexes.

Those are just a few of many, many terms that can sound odd or intimidating to people. Even terms like “array”, “hash”, or “object”, which to programmers is like “flour”, “sugar”, or “eggs”, are an alien language to 99.9% of people.

Now, if you’re a developer, you may look at that list of terms that intimidated me and wonder why I didn’t just “get over myself”. I can assure you that most people, when confronted with unfamiliar language, are silently wishing for you to speak at their level (or worse, misinterpreting you or tuning you out entirely).

The danger zone: misunderstood terms

I could devote a whole, hilarious post to programmer jargon that non-programmers think they undersand (and before I was a programmer, I was sooo that guy). The danger here is that instead of tuning out, people may get a completely incorrect picture (think “steak conference”).

• API: For a thing that basically means “how you talk to my software”, this is frequently misunderstood.
• AJAX: I used to think this meant any interactivity on web pages. In all likelihood, so does your CEO.
• Object-oriented: I literally once told someone I was pretty sure it meant programming directly with graphical objects, you know, like buttons and stuff.
• Technical debt: This is too often used as “parts of the code I don’t like” rather than “remnants of the best way we knew how to solve problems at the time”. So nontechnical decision-makers often discount the entire concept.
• Refactoring: To you, it may mean “We’re paying down some of this high-interest debt.” To a stakeholder it means “I won’t get anything that I want while the developers play in a sandbox.”
• Scalable: To me, this means “able to handle occasional traffic spikes” while a stakeholder thinks it means “racks and racks of stock-photo-style servers, ready and waiting for our inevitable million users.”

In my opinion, these terms are fine, with the only trick being to make sure you toss in your definition to check that you have a shared understanding.

My favorite programming metaphors

There are some programmer colloquialisms that I will never apologize for. And in fact, each time I explain them to non-programmers, they’re grateful for having them in their lexical toolbelt. They’re also great because each tells a specific story:

• Yak shaving
• Cargo culting
• Bike shedding

If you’re not familiar with all of them (or even if you are), Matt Nielsen has written a terrific, laugh-out-loud funny post defining all three.

A path forward

Developers can’t even agree on the definition of terms among themselves, so what hope have we for a shared understanding with our non-technical cohorts? Well, like all language, it matters less what the terms mean and more what the shared understanding is of the people who are communicating.

Half of the solution can be handled by good process, and half is deeply personal.

Solution part 1: Shared definitions

Extreme Programming (guitar solo squeeedleedeedleedeee!) predates my career by a wide margin. But I love the concept of the “Metaphor” principle, which is similar to the “ubiquitous language” principle in domain-driven design, which advocates for a shared set of metaphors and language between the stakeholders (the problem definers) and the developers (the problem solvers).

I also think that non-developers and new developers are more than willing to meet somewhere in the middle. Stakeholders are quite happy to pick up technical terms when they’re core parts of the business or when they save time.

In my experience, the best results come from starting to reach out and show an interest in a business domain’s language, then slowly walking folks toward the technical implementations, bit by bit.

Solution part 2: Conversational empathy

The other half is in developing a specific kind of empathy: learning to have a running thought that wonders, “How are the things that I’m saying coming across to this person?” In doing so, you are forced to think from the perspective of the other person, to imagine what they hope to get from the conversation, and to think about what you’re saying that might trip them up.

But I really do believe that by adding one extra layer of thought during conversations, and periodically sitting down with stakeholders to nail down business-domain terminology, a developer can become as effective a force for good as anyone in the organization.

*I want to come up with design patterns with awesome names. The Sandwich pattern. The Exploder pattern. The Hug pattern. Who’s with me?

“A players” and redefining your job

credit: nettsu via Flickr

Not long ago, I engaged in a conversation on Twitter about the de-motivating effects of placing extrinsic motivators on A players.

This resulted in a fun discussion about the nature of motivation and whether the concept of an “A player” is even a useful classification.

I’ll leave the discussion of extrinsic-vs-intrinsic motiviation stuff to Dan Pink. But what I don’t see is a really coherent explanation about what it means to be an “A player”, how a person becomes one, or whether the term has entered the MBA-buzzword graveyard with “proactive” and “synergy”.

Is the term “A player” fair, or even useful?

Popularized recently by the management style of Steve Jobs, the term “A player” has come into broad usage by management types who wish to sound knowledgeable. Which, sadly, is where good business terms go to die.

That said, the term does carve out a spot in your brain to understand that not all people in an organization are equally valuable. “A player” refers to the power plants of your organization: the people who supply an abundance of high-quality output.

This means that there are “B players” and “C players” who produce less useful output and are more likely to be sort of “along for the ride” in an organization.

“A player” is a role, not a permanent label

Yes, it is dangerous to use a term that looks and feels like a classification or labeling system for people, especially one that implies a judgement as to that person’s value. But it is a hard truth that some people are more valuable to an organization than others.

That said, it’s crucial to note that “A player” refers to a role a person plays. I’ve been an A player, a B player, and a C player at various times in my career, and sometimes even at the same job.

Identifying an A player

Whether you’re looking to hire and keep A players or trying to figure out if you are one, here are some observations I’ve made about people I’ve seen as A players:

Has a trail of accomplishments: A players leave behind visible, tangible results of their work, as they are results-oriented. A players ship.

Seeks out feedback: They don’t reject criticism outright, and actually seek feedback, since their ego is less valuable than getting something done.

Has confidence in own abilities: They’re not confident as in boastful, but as in the opposite of insecure. A players rarely shy from a challenge, knowing that it is a matter of patience and work to see something through.

Not big on seeking permission: They tend to choose the work they think will have the biggest impact and go for it, steamrolling obstacles in their way.

Self-evaluating and self-correcting: A players tend to introspect, are driven to improve themselves, and correct mistakes quickly.

Not interested in gossip: A players view “office drama” as a needless source of distraction rather than fodder for conversation.

Helps others succeed: A players are inspired, rather than threatened, by the success of their peers. They actively seek to help others become successful.

Redefining your role: How to become an A player

I believe that A players are generally B players who figured out that they alone are in charge of when they ship, what they ship, and the quality of their work.

The most important factor in becoming an A player is whether you can attach to a goal that is larger than your ego and insecurities. One that is worth risking failure for. One that is worth breaking the cycle of permission-seeking for. Preferably one that can be accomplished in a matter of a few weeks, lest you burn out before completing the goal.

With this goal burned into your brain, you’ll pull together the resources you need to accomplish it. You’ll naturally find someone to help you with gaps in your skills, because you’ll want to see this through.

And once you’ve accomplished it, you’ll never want to go back to B-player-style work again. You simply won’t be able to tolerate it. It’ll drive you crazy.

Then, the work begins again of finding the next goal that is similarly motivating.

Yes, finding that goal is easier said than done, but I’ll bet you can find it if you pay attention to what is around you.

How to lose your A players

Many organizations don’t actively identify their A players until they start to leave, and management staff, in a panic, begins some misguided effort to get the remaining A players to stay.

Steve Jobs famously said “A players like to work with A players. B players hire C players.” This, of course, comes back to the fact that B and C players aren’t confident in their abilities, and need to hire people that won’t show them up.

A players form ad-hoc alliances whose goal is to ship, while B and C players tend to form committees whose goal is to prevent things from being done wrong.

A players don’t react well to committees, forms, or bureaucratic processes that add friction to the act of building and shipping.

Each point of friction adds up until A players realize that they aren’t able to operate at their full capacity. They may even verbally warn their management (who often aren’t receptive, or make empty promises of change). And being high-value employees, they know they can succeed somewhere else that promises less friction.

It’s a lifelong process

Some of the A players I’ve met seem as if they were born that way, but for most of us, it’s a lifelong process of self-refinement. A lot of my struggle is to subjugate my ego long enough to really seek and apply feedback.

But to individuals, I can promise that the benefits of developing yourself into an A player are abundant. No one has the world in front of them quite like high-performing individuals.

And to organizations, the benefits of cultivating an environment that rewards A-player behavior are even greater. If you’ll identify and reward your A players, they will drive a culture of results and shipping that defines the best companies in the world.

Addendum:

After posting this, I realized that people may take the wrong message from all this. If you’re reading this, you’re probably an introspective person. If you’re introspective, you have a leg up on 95% of the population. You’re well on your way and very well could be an A player already. Just because there’s still room to grow doesn’t mean you aren’t amazing already.

So take any self-criticism with a grain of salt, and realize that the fact that you’re even evaluating yourself puts you in the category of people I’ve defined above as A players.

Ruby DCamp: What I learned on summer vacation

Ruby DCamp is one of only a couple of my “can’t-miss” events of the year. This was my second time participating, and both times, I’ve come home with life-changing experiences. It’s incredibly special to me, and I want to share with you some of the reasons why.

What is Ruby DCamp, and what makes it so special?

Ruby DCamp is a code retreat and unconference (which I’ll describe later), and takes place about 45 minutes out of Washington D.C., in Virginia’s Prince William Forest state park.

It’s the brainchild of Evan Light, a Maryland-based Ruby developer and self-described hippie. It’s simple in concept: a three-day event, held in the forest, for programmers of all skill levels to get together, write code, socialize, and self-organize as a community.

What makes DCamp unlike most other events is a combination of the venue, the sessions, the community, and the event’s mission.

The venue

Unlike any other conference I’m aware of, DCamp takes place at a campground, the sort of idyllic summer camp depicted in movies and TV shows from the 1980′s and 90′s.

There’s no internet: it’s BYOWifi, and cell coverage is… meh. A lot of people (like me) don’t have tethering and have to borrow someone else’s device to connect.

The cabins are subdivided into rooms, with 2-4 cots per room. So there are some limitations on privacy and personal space.

The constraints imposed by the remote location, close quarters, and lack of connectivity are actually incredibly freeing. Without all the little caves we tend to retreat into, we’re encouraged to bump into one another, strike up conversations, and let serendipity happen.

Attendees wake up early, stumble into the bathrooms (which are about what you’d expect at a campground), and are ready for breakfast around 8. The conference proper starts at 9, breaks for lunch, and wraps at 6 each day.

The Format, Day 1: Code Retreat

Day 1 is a Code Retreat, which is a well-defined formula for honing programming skills. At DCamp, you pair up, work on solving Conway’s Game of Life for 45 minutes, follow up with a retrospective, and jump back in with a new pair programmer. Meanwhile, in each iteration, Evan throws a new wrench at you by adding a constraint.

One of the constraints is called “mute evil” pairing, where no speech is allowed, the code does all the talking, and the programmers are instructed to sort of antagonize one another through the code. It was all very challenging, and at times, frustrating.

By the end of Day 1, I was completely wiped out. It’s not my favorite part of DCamp, but in the discomfort there’s a tremendous amount of learning. It’d be quite difficult to spend a full day gaining that much exposure to people of varying skill levels, styles, preferences, and tools without learning a ton.

The Format, Day 2 & 3: Unconference

On Day 2 and 3, the group gets together and pitches each other on ideas for topics for the day. Then, you write down your proposed session and duct tape it to the wall.

Each member gets 5 votes. You cast your votes by dotting the duct-taped papers, they’re tallied, and Evan compiles it into a two-track schedule.

The schedule tends to fall into two tracks: one is code-oriented, and the other tends toward the philosophical.

Each track gathers at an end of the main cabin, and you’re free to “vote with your feet” and switch between tracks, spin off a session of your own, or just duck into your cabin for a nap. Or help out in the kitchen (more on that in a bit).

There’s also a third track for new Rubyists or non-programmers, held out on the picnic tables outside. For such a small group, it’s shocking how accommodating the schedule is for varying experience levels and interests. That’s the benefit of having the attendees determine the schedule, I suppose.

As for the sessions themselves, I’ll provide a “what I learned” section toward the end.

The Community

DCamp is essentially a self-organizing pop-up community. There’s no staff to speak of. Evan handles the logistics of making it happen, but once the camp starts, all sessions, planning, cooking, cleaning, and activities are the shared responsibility of the participants.

Some of the people there are well known in the community, and some are first-time programmers. But everyone pitches in, everyone teaches, everyone learns, and everyone enjoys each other’s company.

After dinner, it’s up to participants how they spend their time. Some retreat and read books, many bring card and board games, some hack on projects, and some just converse (you may not be surprised that I tend toward the latter).

I can’t overstate the quality of humans that DCamp attracts. It’s an awe-inspiring group of people. I’m still astonished at the backgrounds, knowledge, accomplishments, and depth of character of the people there. I actually feel a bit sad knowing that I don’t get to interact with many of them at that level more than once a year.

I got to hang out, code, and talk with some personal heroes of mine. I also met people who became new personal heroes to me.

The Food

It may seem strange to spend a section on the food, but DCamp has become known for taking food seriously: There are options for everyone from vegans to paleo adherents. Rather than burgers and hot dogs (as had been the case in prior years), the menu consists of a number of from-scratch items made in the dated, somewhat dangerous, but still-functioning industrial kitchen in the main cabin. This year, the food ranged from grilled portabello to a smoked whole pig (yes, seriously).

DCamp eats are also famous for improvisation. Last year, Brad Herrup made astonishingly good bread pudding from leftover hotdog buns, and this year we had to cut ice cream into cubes with knives, as we’d failed to remember an ice cream scoop.

The food in particular is a herculean task, from purchasing, to cooking, to cleaning. The kitchen is a hive of activity literally from dawn to dusk. Everyone gets a chance to participate: I had a couple of nights of dishes, and got my share of injuries while cooking 20 lbs. of pasta.

What I learned

One of my favorite things about returning for a second year was that it has become a yearly moment to reflect. I got to see the progress that my friends had made in the intervening year, and to realize how much of my own progress I’ve made.

Most importantly, I got to ponder on what I’m passionate about and what I want to accomplish by the next time DCamp rolls around.

Several of the sessions stand out in my mind:

Sexism in Programming: Sandi Metz and several other female attendees helped steer this delicate conversation, and the way the men participated made me proud to be a Rubyist. Without resorting to becoming “word police”, we can make the Ruby community a shining star for diversity until we reach 50% parity between men and women.

Raspberry Pi: I brought my Raspberry Pi (the $25 computer) and led a session on what they might be used for and how to get them set up. Even with technical difficulties with the TV, we had it all set up and running the programming language for kids called Scratch within the half hour session. (Later, we set up Ruby and Rails on it. That did not take half an hour.) I’m still terribly excited about the educational implications of this fun, approachable, and inexpensive computing platform.

If Money Weren’t An Issue: Adam Bachman (originally a philosopher and theologian by training) led a brave, deeply resonant conversation about the things we’d do if money weren’t an issue, or if failure weren’t an option. Pausing to think and openly discuss what we really want to be doing with our lives is not something I’d expected to participate in, but I’m so glad I did.

JRuby with Hiro Asahi: I learned more about JRuby, having used it for work in the past, but I was more struck with Hiro. He’s an example of the best of Ruby’s MINASWAN culture, and I was delighted to learn from him. (MINASWAN, for the uninitiated, stands for Matz [Ruby's creator] Is Nice And So We Are Nice.)

Visualizing code: Avdi Grimm posed an open question about how programmers visualize concepts in software, and it developed into a rich conversation complete with drawings by people in the group. Sandi Metz showed how she uses Keynote to create a sort of animation to take a complex refactor and explain it to people in a simple, accessible way. I am passionate about using drawings to communicate, and this made me want to really develop those skills.

Spreading the wealth: Another Avdi-led session, he shared how he believes that every software developer can define and create jobs. We may not be a part of the “one percent”, but our responsibility is to share some of the prosperity of software development by looking at parts of our work that can and should be hired out to (real, not virtual) assistants, and start defining new roles and jobs that may not even have been invented yet.

DCamp’s mission

A lot of conferences put together a vision or mission statement. Some craft a nice explanation about how it’s the “conference for people who X”. All of these are great, but DCamp couldn’t possibly do that, because its mission and ideals largely emerge from the community that shows up to participate.

But what makes DCamp so difficult to emulate is that it is very much Evan’s baby. Its soul is found in his gifts, dreams, frailties, and flaws. It simply would not exist without the combination of his love, stubbornness, desire to include and be included, and his deeply-held idealism.

DCamp is Evan’s dream of what utopia might be like, and he cultivates it carefully. And for a few days a year, a few of us get together and sample it. And for two consecutive years, it rang my psyche like a gong.

Thanks to Evan and the attendees for another great DCamp, and I hope to see old and new friends there again next year.

Finding your “sweet spot”

“Brandon, I like you, and you’re doing well, but I’m frankly disappointed. I thought you were going to come in and really set the direction for our enterprise architecture.”

I couldn’t help but get lost in that memory as a close friend shared with me that he was feeling terribly underwater in his work. No matter what he did, he couldn’t seem to measure up to their expectations. It was like he was on a treadmill that was set just a little faster than his fastest pace.

Not long before that, I’d been hired to do a job that I honestly still do not comprehend. Something about diagrams and TOGAF and enterprises. But it sounded fun and important, and promised me an entry point into software development.

As I started on my first day, I was repeatedly told how excited everyone was that I was starting. I was flattered to see that everyone generally regarded me as the person who was there to finally make everything better.

If I’d had a little more experience, I would have recognized this as a massive red flag. Ultimately, as you may guess, those sky-high expectations amounted to a stressful, unpleasant, and yes, disappointing work experience for all involved.

So I could most certainly empathize with my friend. And I shared a simple concept that had helped me come to grips with my own situation.

The diagram

I told my friend to imagine, in one circle, all his desires and abilities. He had enormous capability in a number of areas. He’d essentially run a business by himself for years, managed projects, and led people. He’s also a solid software developer. He has deep marketing talent and a gift for communication.

Then I told him to put all the expectations of this client in a second circle. They were looking for people who could write code. Not just write it, but crank it out quickly and move on to the next thing. So of all his skills, his client only wanted one. The overlap between the two was minuscule. And he felt like he was being run into the ground.

Making up the difference

Even if you’re only using this sliver of your capabilities, you still need to meet the needs and expectations of your employer, client, or customer. So how do you compensate?

You could put in extra hours without telling anyone. You could try and work harder or faster, eschewing all the small niceties in your day that don’t constitute nose-to-the-grindstone labor. Or you could cut corners, and only do just enough to hope to fool them into thinking their expectations are met.

But it’s going to be of little use. There’s no secret extra hours, no corner-cutting, and no amount of focus that you can apply to make up the difference when expectations don’t line up with your goals and capabilities. Ultimately, you’ll either disappoint your customer/client/employer, or burn yourself out trying to keep up.

A better scenario

Have you ever felt really capable? Like a project was not just within your abilities, but right exactly up your alley?

That’s an awesome feeling, and it only happens in these high-overlap situations. When the work that you do aligns with your goals, falls inside your capabilities, and challenges you in the right ways, you’ll be able to completely delight your customer.

You must know your circle

Your side is by far the most important piece of the puzzle, and it’s astonishing how few of us really understand it.

Knowing your circle starts with asking yourself a lot of hard questions: What do I do that makes me “me”? What is it that makes me feel like a superhero? What do I want to accomplish? Who do I like working with? What do I hope to learn?

Understanding their circle

It’s possible that you have an employer or customer that’s as chaotic as a few of mine have been, and you may not even know what their expectations are. If that’s the case, you need to clarify what’s expected of you.

These expectations may seem demanding, things like “we expect you to turn product features around in less than a day”. Or they may sound noble or beneficial to you, e.g. “we see you on a fast track to management, if you’ll only do x”.

All of that is fine, if it lines up with your own circle. The danger is in adopting these expectations for yourself, migrating goals from their circle into your own.

Otherwise, you may find yourself forgetting your own goals and capabilities, and trying to live up to expectations that are not yours. This leads down a path of stress and disappointment.

OK… so what if they don’t line up?

You’ve mapped out your Venn diagram and realize that you have very little overlap between your capabilities/goals and their expectations. What now?

The most important thing is to be honest with yourself about it. But you really only have two choices: to change the situation, or try and change yourself.

Changing your situation can range from easy to very difficult. Changing yourself is essentially impossible, at least in the short term.

You know the person who was “frankly, disappointed” in me? After I’d realigned my expectations with him and that company, I was able to change my situation drastically, without quitting my job, and it turned out to be one of the highlights of my career so far.

You don’t have to quit your job or fire your customer to change your situation. You do, however, have to be direct and honest with the people whose expectations are out of alignment with your own.

And while sometimes that will mean a parting of ways, the wrong strategy would be to suffer silently for fear of losing a job or client that’s making you miserable (and that strategy almost never works anyhow).

The lesson in all this

It’s easy to get mad at yourself for falling short of expectations. But if you step back, you can skip the self-judgment and objectively look at every situation as the fit between what makes you awesome and what people expect of you.

A recurring theme in the things I’ve learned over the years is that it’s futile and agonizing to try to fit into someone else’s model of who you should be. Understand what goes in your circle, and you won’t have to force yourself to “fit” anywhere: you’ll automatically start matching yourself to clients and customers who are looking for all the ways in which you’re amazing.

Depression, digging out, and pursuing happiness

"Whatever the Weather" by monettenriquez via Flickr

First: Defining “feeling depressed” vs. “depression”

This is a sensitive topic, and for a number of reasons, I nearly didn’t publish this post. But I feel like it’s an important subject, so I’m going to proceed, albeit with a couple of caveats.

I define “feeling depressed” as having feelings of sadness or general negativity for a short time. Feeling depressed is a completely natural experience when it follows major events of stress or loss. Having depression generally means you have been experiencing these symptoms for longer than two weeks, and they’re showing no signs of improving. For this article, I’m going to hand-wave a bit and say “depression” to refer to both, short of diagnosed, clinical depression.

If you know or believe you are struggling with clinical depression, do not pass go, declare TL;DR on this post and seek out a professional (or a loved one who’s smart enough to tell you to seek out a professional).

The unspoken epidemic

Depression is a rarely-discussed topic, except among close friends, behind closed doors. Which is sad, because it seems to affect a very large cross-section of developers I’ve talked with, and being able to talk about depression is an important step in dealing with it.

Recently, I’ve made a series of life-changing decisions, the unintended consequences of which triggered a bout of depression that I’ve struggled with over the last few weeks.

And depression is a son of a bitch. It makes things that I can normally deal with easily look impossible. It robs me of the will to do things that make me happy. I feel as if I can’t talk to anyone about it: not my friends, or even my wife, as none of them deserve to be burdened with my problems.

I have felt the effects of true, physiological depression before, the kind that makes you understand why people choose to end their lives. This episode was nowhere near that in severity, but it’d been getting steadily worse for long enough to worry me (and those who care about me).

The “coping bucket”

A friend suggested this metaphor: Everyone has a “coping bucket”, filled with the all-important stuff you use to cope with difficulties. Each time you deal with something difficult, you draw from that bucket. Rest, joy, laughter, etc. help fill the bucket, bit by bit. But when it’s drained, there are no reserves to handle tough situations, and reaching the bottom can be pretty dire. The end of your reserves can feel like the end of the world.

Pessimism can lead to depression

About a year ago, a close friend recommended the book Learned Optimism by Martin Seligman. I think it’s an important book and you should immediately go buy it, but the gist is that pessimistic thoughts are a precursor to depression.

When something bad happens, pessimistic thoughts tell you:

It’s personal: It’s your fault, so take some responsibility.

It’s pervasive: It affects all areas of your life. It must indicate a deeper problem.

It’s permanent: The bad thing lasts forever. There’s nothing you can do about it.

The problem is that in much of modern society, taking credit for good things in your life is considered egotistical (when it is actually optimism) and taking “responsibility” for limitations is considered humility (when it is often pessimism).

So the person who shoulders responsibility for flaws and shrugs off praise is deeply pessimistic, and at extremely high risk for depression. For me and a lot of other developers I know, that may sound familiar.

So when things do go wrong, it’s important to take a minute to stop and look for reasons it’s not personal, pervasive, or permanent.

Examine the environment: It’s not personal

This most recent bout came immediately after I’d drastically changed my environment, and I’d pretty carefully constructed my old one to optimize for happiness. Now, I had brand-new stressors and triggers, but none of the support structure I’d previously had to cope with them.

But instead of realizing this, I immediately internalized – personalized – these feelings. I was sure that these feelings were my own fault, and this line of thinking only served to deepen my depression. But as soon as I realized that external factors were most likely wreaking havoc on my emotional state, I was able to de-personalize the way I was feeling. For me, de-personalizing is the moment I stopped spiraling down and realized there was probably a way out.

Checking environmental factors and changing them is step 1. When you first realize that you’re feeling depressed, a change in scenery is highly recommended. Go spend some time with loved ones. Visit someplace that makes you feel calm. Talk to some friends. This buys time and distance to start thinking long-term.

Changing Actions: Refilling the bucket

After reflecting a bit, I decided to look broadly at the areas of my life and break down the things that make me happy. These are not ideals or even values, they’re observations. They’re leading indicators of my personal happiness, things that tend to precede happy periods of my life.

• Going on dates with my wife
• Reading to my kiddo
• Chatting or going to lunch with my friends
• Thinking about people I’m grateful for
• Making something and sharing it
• Pair programming
• Writing about things that feel important to me
• Taking my family to sporting events
• Going for walks with someone (or by myself)
• Going to developer conferences and meetups
• Helping people understand their intrinsic capabilities
• Educating myself through books & courses
• Running outdoors
• Taking time off of work to do things with my family
• Making people laugh
• Talking with loved ones
• Fearing something and then doing it anyway

The thread running through these is that they help reset my perspective. It’s easy to become myopic when confronted with one’s daily battles. Doing the things above help me decouple my sense of self-worth from the wins and losses of daily life.

Avoiding “false positives”

There are some things that, while not necessarily bad, are easy choices that leave little room for the things in the previous list.

• Staying up late to catch up on my Instapaper or Twitter backlog
• Watching very good television (The West Wing is my current addiction)
• Staying late at work to knock out one more solution or have one last conversation
• Eating whatever I want
• Worrying about and analyzing the behavior of others
• Staying up on all the latest news
• Needing to be “the best” at everything I try
• Indulging that inertia-based feeling of “I’d rather not, at least not right now”
• Taking the “safe” route when confronted with risk

I’ll often do the things on the second list when I’m depressed. For others, their second list may include drinking or other activities that act as a temporary distraction from problems. These things seem in the moment like they’ll help you refill the bucket, but often, they actually drain it, with interest.

Reserving judgment: it’s not pervasive

But I have to be careful: beating myself up for dropping the ball and trading away so much of the important stuff is a form of “pervasive” pessimism: the idea that I’m messing up in some areas, so I must not be capable of doing anything right.

The truth is, I’m doing great at some of them, and I’m letting others slip. In order to make this non-pervasive, I had to give myself permission to fail in some areas (or even most areas) without judging myself, and just commit to making small, incremental improvements.

Digging out: it’s not permanent

I’m largely on the other side of this most recent bout. Many of the difficult situations remain, but much of my ability to deal with them has returned. It wasn’t permanent, even though it felt like it might be.

And to me, that’s the biggest problem with depression: is that it feels permanent, and it’s enormously tempting to assume that it is indeed permanent and to just give yourself over to utter despair. I describe it as feeling like I’m stuck at the bottom of a deep well, the light’s so far away you can barely see it, and there’s little hope of climbing out.

But perhaps the most important thing is to realize that this “stuck” feeling is not permanent, that it’s not as deep as you think, and the worst will pass and you’ll again have the strength to climb out.

Growing the bucket

Your actions can refill your “coping bucket”, but changing your thinking can actually grow the size of the bucket.

So to start, I’m going to add more of the things that make me happy to my schedule (and defend it vigoriously), but I’m also going to try to be aware of and re-examine pessimistic thinking.

And most importantly, I’m going to lean on friends and loved ones. It’s because of the advice of one friend in particular that I was able to see a light at the top of this particular well, and I’m enormously grateful.

Again, I need to qualify this with the fact that I am not a psychologist, and that if it’s been a few weeks or longer, you ought to seek out the help of someone who does this professionally. These are just my experiences. I’ve had luck with this strategy so far, and I will keep you posted on how it works out for me long-term.

The culture myth

Petri Dish by PNNL via Flickr

A couple of years ago, while at a bustling internet startup, our CEO bought everyone in the company a copy of Tony Hsieh’s Delivering Happiness. Although it wasn’t my favorite business book, it was nice to learn about the central role of culture at a remarkable company.

After we’d all read the book, there began in earnest an effort to create a “corporate culture” that showed how fun and unique we were, and that would attract top technical talent. Suddenly, Nerf guns and toy helicopters filled the office, but something about this effort rang hollow to me. I couldn’t put words to it, and I left for another opportunity before I gave it much of a chance one way or the other.

The very next company I worked for had a similar cultural focus, only dialed up to eleven. People whizzed about on scooters while new employees were given a tour through our deeply-held organizational values (which were literally painted all over the walls).  After a few tough months, the CEO openly wondered what had killed the culture, and vowed to “bring it back”. It was painful to watch, and made me wonder how any company can foster great culture when even this culture-obsessed workplace could go south so quickly.

I’ve since given a lot of thought to what makes up an organization’s culture, and I realized that this obsession with culture, for many organizations, is killing that same culture.

I believe that what we typically call culture is a side effect of an organization’s traits and habits. Just like a fire needs heat, fuel, and air, I believe there’s a similar “Culture Triangle”:

1. Vision
2. Trust
3. Feedback

If an organization has a strong vision, high trust in its people, and tight feedback loops, it would be very difficult for it to have a “bad culture”.

In the first organization I referred to, there was a clear vision for the company and a decent feedback loop, but very little trust in the people tasked with carrying it out. I hear they’ve subsequently improved this dramatically, and also that they’re doing quite well.

In the second company, there was never a strong vision, other than to have a great culture (which I think actually distracted from the need for a real vision). More tellingly, I watched trust evaporate as we started missing targets and the company’s leadership took more and more autonomy away from its staff, evolving into a command-and-control organization.

Why startups lose their culture

This story is so common it’s generally considered inevitable: the fun, breezy startup culture becomes more staid and bureaucratic, usually around the 15-30 employee mark.

In a one-to-ten-person startup, awesome culture is essentially automatic. Almost no startup survives its first stages without strong vision, deep interpersonal trust, and lightning-fast feedback loops. There’s simply no start without a clear purpose, there’s no room for double-checking your co-founders’ work, and no way to screw up without it being completely visible to everyone.

As an organization scales up, layers are introduced, and strange things happen. That crystal-clear vision becomes murkier when it’s up against hitting a quarterly target. Hiring trustworthy people becomes difficult enough that employees now must be “managed” by people and policies. It becomes difficult to connect top to bottom, allowing feedback loops to take months, rather than hours.

But it’s not all doom and gloom… some companies reach escape velocity with their culture intact. Famously, Netflix and Github have held themselves up as examples of scaling high-performing corporate cultures. How do they do it?

Relentlessly protecting your culture

Creating a culture is easy, because if you have a company, you already have one. Your first three or four employees basically comprise your culture, and from there, the hard part is protecting it.

Here are some of my observations of patterns in culturally successful companies:

1. Hire for culture. This means hiring people whom you plan to entrust with your vision and their execution of some part of this vision. This requires both trustworthiness and competence on their part.
2. Keep your door open. I’ve been fortunate to work in very few places with “ivory tower” management, but it’s a killer for trust and feedback. You’ll know if you’re truly communicating that you’re open to feedback, because you won’t stop getting it.
3. Have reviews, but don’t wait for them. It’s always uncomfortable to offer correction, but I’m incredibly grateful for the feedback I get on the team I’m on now, and feedback I’ve received from teams in the past has literally changed my life. Assume your team members will accept constructive feedback, because if you did #1 right, they will.
4. Keep the vision clear. A vision is not a numeric target, but a reason for people to get up and come to work in the morning. What in the world are you changing? Building? Shaping? Who benefits?

What If…

…You hire untrustworthy or not-competent people? The temptation is often to remove ownership from people, but this is the slope that leads to a trust-free workplace. A good feedback loop should take care of most kinds of mistakes. If a person isn’t fulfilling their role, you’re doing them a disservice by letting them skate along, unknowingly missing your expectations. If they’re not a good fit at all, they probably don’t want to spend their time on the wrong bus any more than you want them on it.

…Your vision changes? Your vision is your organization’s purpose in existence. No matter how many “pivots” you make, if your company’s core vision changes often, you may want to examine whether you had one to begin with. That said, if it truly does change, you need to give employees ample time and reason to buy into this new vision (and recognize that some may choose not to).

…You don’t do reviews? Reviews don’t have to be formal, but they do require some discipline, even at great companies. Programmers are fortunate to often have code reviews, where peers look over each others’ work, offering questions for thought and suggestions for improvement (much like an editor for writers). I think this culture of collaborative peer reviews would be wonderful to carry into other areas of your business as well.

To put culture first, put culture last

The thread I see with running through the most successful, high-performing companies (and I feel that the company I’m at now is one of them) is that they tend not to wring their hands over “culture” too much; they’re very busy getting amazing things done. And who wouldn’t want to get up and go to work when you’re entrusted to go get amazing, meaningful things done with other amazing people?

Sell your principles (not your values)

Money by 401K on Flickr

Not that anyone’s offering, but I want you to know that my principles are available for sale or trade, if the right offer should come along.

It’s important to note that there’s a big difference, in my mind, between principles and values. This difference is subject to no small amount of interpretation, and you may not agree with my definitions, but let’s assume the following to illustrate a point.

Can we call for a definition?

Principles are beliefs based on observation. They are learned. They direct my actions.

Values are core philosophical understandings. They are discovered. They form my identity.

How we get them

Principles are based on experience, and mine seem to evolve at an accelerating pace as I age. I adhere the best I can to the principles I have at the time, but I’ve learned not to get attached to them. Several months ago, I had strong opinions on principles of good software development, but I now find myself taking the opposite position in many areas.

And that’s better than okay, it’s great. Evidence comes across, and your precious principle starts causing you pain, and you start refining your principle. For newer software developers indoctrinated with the idea of TATFT (test all the f****** time), the principle quickly evolves into something that a person can actually live with.

Currently, painful experience has taught me that I don’t want to be caught with any significant functionality in my code that isn’t covered by tests. So I test my code. Most of the f****** time.

That’s a principle. It’s not me, it’s just something I try to do.

Values are different. I’ve discovered my values when I read, hear, or see something that hits my natural frequency. It bangs my psyche like a gong.

When I first truly heard the George Harrison song “Within You Without You”:

“With our love, with our love, we could save the world… If they only knew!”

I pulled over in my car because I couldn’t see. I’d just spontaneously started crying. I still tear up when I hear it. That hit my exact natural frequency. Love can change the world. We can change the world. With love.

That’s a value. That’s me. That’s who I strive to be.

Dying on Principle Hill

There’s a hero fantasy that many of us share about dying for our principles. To use a contrived example: “Did you hear that when Bob was asked to spend Saturday working instead of with his family, he quit? He’s so principled!”

This would be much less likely gossip: “Did you hear that when Sandy was asked to work on a Saturday, she said she would, but needed an extra day next week to spend with her family? She’s so reasonable!”

When we pick a “hill to die on”, it’s often because we’ve mixed up our principles with our values. We can attach so completely to a principle that we wrap it into our identity, which shuts down our ability to reason about that thing.

How can you tell values from principles?

Separating values from principles comes largely with experience. But I don’t think a person gets to carry around very many values. So if you need two (or more) hands to count them, that may be a sign you’re mixing up the two.

It would be difficult, and perhaps impossible, for someone else to bribe, pressure, or convince you to violate your values. Could someone else coerce you into violating it? If so, it’s probably a principle, not a value.

And if you can cite specific examples of how your outlook or your life changed as a result of a realization or discovery, you very well could be talking about a value, and you want to hold fast to those when you find them (again, they’re few and precious).

Sell ‘em, trade ‘em, just trade up

Someone wants to give you a reward (or a paycheck) to do something that contradicts your principles? Sorry to tell you, it’s not black and white. It may very well be the right thing for you, in that moment, to exchange that principle for the reward you’ll receive.

If you feel a strong sense of conflict between your principles and your work, you’re not selling the principles themselves, you’re selling the right to violate them. This cedes control of them to someone else and breeds resentment.

The good news is that as soon as you assume ownership of your principles, you have the ability to trade or sell them, rather than just selling others the right to violate them. There’s no resentment for treading upon them, and no smug satisfaction for adhering to them, because it’s not you, it’s just something you try your best to do.

I think it’s healthy to learn to happily trade in principles, as long as you’re trading up. It complicates some decision making, as you’re always considering tradeoffs, rather than setting up hard and fast rules in your life and always coloring inside the lines.

Shifting to value-based decisions

Principles, to me, are something like training wheels for decision making. Perhaps the path to enlightenment is to graduate from principles entirely and understand your own values so well that you rely solely on your values as the basis for your decisions.

The first step on this path is to understand that your principles are subject to change, and that when they start causing you pain or conflict, it may be time to consider whether that principle still holds true for that situation. Remember: the principle is not you, it’s just something you try to do.

Lastly, take some time every once in a while to meditate on your values. What hits you like a bolt of lighting? What do you want the totality of your life to amount to? Once you find these, hang on to them, they’re not for sale.

Empathy, circuits, and self-deception

Sometimes in life, with no warning and no obvious desperate need, something comes from out of nowhere and knocks you out of a complacent stupor.

The book

Last year, someone loaned me the book you see to the left. I decided it looked like a good plane read and took it with me to Ruby DCamp. It wasn’t particularly well-written, and was far from a page-turner. But every few pages, it was like banging a gong in my brain:

“Brandon. Wake the heck up. You are acting like a selfish douche.”

Basically, you need to go right now and buy it. It helped me connect the dots on much of human behavior, especially my own, and the ludicrous things we do to avoid having to change our worldview, even just a little bit.

The basic premise is: If you are treating anyone, anywhere, in any way, as if they’re an object instead of a person, you are chipping away at your own psyche by betraying what you know is right. You’ll then manufacture a story, a version of reality that protects you from dealing with this until you lose the ability to connect with others at all.

All of this caught me off guard. I began to realize that I was wantonly wrecking relationships all around me, merely to serve the need to be right and just. I cried hot tears of shame on the flight to think of the way I’d treated strangers, coworkers, even my wife.

My finely-honed skills of justification were leading me to the kind of callousness and under-the-surface anger that I can pretty much guarantee would have ended my marriage. Basically, pretty serious stuff.

There’s a prevalent metaphor in the book about people being “in the box” that I didn’t really latch on to. However, I was struck with the non-intuitive insight that anything you do to help while in this headspace isn’t really helping. It’s like trying to chart a course to the other side of the world if you believe it’s flat. You have to step into another worldview to do anything of any use.

The Circuit

So we have this big, huge problem in our lives. And no ability to solve it by any conventional means.

Guess what the secret is to stepping out of your worldview? To want it. That’s it.

If you decide to truly desire to understand how another person is feeling, you will almost immediately reverse the effects of objectifying another human, and you will begin to put yourself in their shoes.

Unlike almost anything else in life, you can wish empathy into existence.

You then begin to wish the best for this person. You may even wonder what you could do to help this person. You may even find that there is something you can do for this person.

So here’s the thought pattern I saw emerge from this line of thinking:

1. Judgement/Objectification (or any act of self-betrayal)
2. Justification (the story we tell)
3. Realization of the act of self-betrayal
4. Desire to empathize & correct the action
5. Re-Humanization of those we objectify (and apology)

That’s a circuit. The goal is to close it as quickly as possible. (In IT parlance, it’s about Mean Time To Resolution, not Mean Time Between Failures.)

Two examples

I’ll give two examples: one from the book, and one from my life.

In the book, on of the first stories is of a husband who’s trying to get some rest, with his sleeping wife beside him. Their baby begins crying, which he tries to ignore. He commits the first act of self-betrayal by not helping. “I’m sure she’ll get up.”

Then the justifications. “Why isn’t she getting up?” “Doesn’t she care that I have work in the morning?” “She obviously is lazy and doesn’t care about my needs.”

So here’s a fully-concocted story that buries anger and resentment inside a person. But if he’d stopped, he could have realized that he she was just his loving wife, that she was sleeping, and perhaps she really needed his help with the baby that evening.

In my own life, I’ve spent decades training all my powers of observation, psychology, and analysis on trying to stitch together someone’s story… so that I can judge them. I still have this nasty habit.

Last week, my wife and I were fortunate enough to travel to Hawaii, and we spent a morning on a cycling excursion with a newly married couple. The young lady had nothing good to say about her trip. She was staying in the most expensive hotel and dining at all the finest restaurants on the island, and found faults in every part of her trip. The bed was too soft to sleep in. The food was disappointing.

I used my skills to project into the future for this couple, and see much trouble for this princess and her pea. And what did I get for my efforts? I got to turn this young lady from a human into a measuring stick that found me superior in every observable way.

But I couldn’t leave it there. My brain is now too aware of the concept of self-betrayal to let me get away with it anymore. I began to realize that here was a young lady that had one chance to have a memorable honeymoon, things kept going wrong for her, and she hadn’t yet gathered the life experience to be grateful for what she had. There might have even been something kind I could have done to help make her trip memorable in a positive way. I stewed over this for a while, apologized to my wife for the negativity, and went back to having a wonderful time.

And that’s just one tiny example of many dozens of acts of self-betrayal I commit on a daily basis.

Closing the circuit faster

Trying to close the circuit can be overwhelming.

You have to forge new neurological pathways, which is always uncomfortable. It requires that you assume that you are not necessarily noble and good and just, which chops your ego into little pieces. Many of us rarely get past Justification. Getting past Realization can seem impossible.

But here’s the amazing thing: if you simply expose yourself to this concept and it rings true for you, it will begin to seep into your thinking. You will no longer be able to enjoy guilt-free judgment of other human beings.

I still have these moments of judgement and anger with my wife, but I now have the gnawing sensation at the back of my mind, the Bat-Signal that tells me I’ve committed an act of self-betrayal. That part is automatic.

Then, I try to see how long it takes me to close the circuit. It still often takes me a day or two to come around, but I’m getting faster in many cases. Eventually, I hope to open and close the circuit so quickly that the net effect is that I no longer sit in judgement over (or objectify) anyone.

What to do next

How many times do I need to tell you? Go get the book! But you can play along at home even if you haven’t read it. The next time you find yourself angry or seething at a person, try to just want to know how they’re feeling. Start telling yourself their story instead of yours, and see where that takes you.

I am a relatively new practitioner of this type of thinking, but I can tell you that it will open your heart to serving others. This will lead you to real friendships, lasting relationships, contentment, happiness, and pretty much every measure of success that will matter to you as you look back on life.

Introspection is a superpower

Note: please pardon the crudeness of these drawings. They were done on an iPad at 2 AM.

What does it mean?

You know what it is to be introspective, right? To be able to analyze your own patterns of thought? A person I admire a lot told me that in his hiring decisions, introspection was the a primary quality he looked for in candidates. I was surprised to hear that, but I think it’s the wisest job requirement I’ve ever heard.

A lot of people see this and conclude that they are largely passengers in life, blown about by the winds of circumstance:

People who see the world this way often have verbal giveaways. “She made me do it.” “He was really pushing my buttons.” “No one listens to me.”

Why give up so much control? Because it’s easy. When life is just reacting to outside forces, we are not responsible for our situation. The boss won’t implement your ideas. Your spouse isn’t supportive enough. You were passed over for a promotion. But it’s not your fault. You’re not responsible for the outcomes, things just happen.

We get the pleasure of being right, but without the burden of having to do anything other than complain when things inevitably go wrong.

Enter introspection.

People who can introspect recognize the fact that their own biases, distortions, and assumptions sit in between actions and consequences, and they have a dramatic influence over our interpretation of reality.

Five people can literally see the same thing and draw five radically different conclusions. The reason is that they each have a complex set of machinery inside their brains that literally alters their reality. How many times have you perceived a slight when there was none? How many times have you been asked “what is that supposed to mean?” when it was supposed to mean exactly what you said? Have you ever remembered something so vividly, only to find out that wasn’t how it happened at all?

Introspection is the work you put in to see your internal machinery for what it is.

What do you do with it?

Being introspective doesn’t necessarily carry any requirement that you act on it, but it makes justifying inaction very difficult.

Here’s an example. Recently, I had an altercation where I got into a tug-of-war with a coworker, and I angrily and passive-aggressively “took my ball and went home”. He was clearly in the wrong. I was right. I was justified. My position was infinitely defensible. Everyone else saw it my way. I won, case closed.

But there it was, gnawing at the back of my mind… what if I wasn’t right? What if I wanted so badly to be right that I was willing to damage relationships to win? (And make no mistake, that’s how it went down.)

Did I apologize? No. Why not? Because shut up, that’s why not. OK, I’m still a bit defensive about it. But the time I took to analyze my actions and position won’t let me get away with this behavior next time. That’s a tiny, broken piece of me that I will fix the next time I encounter a similar situation.

Maybe over time I’ll be able to deal with these situations in real time rather than damaging one relationship to save the next.

The problem is that we all build a thick, protective shell around our internal machinery throughout our lives. It keeps us from getting hurt by what others say or do, but it also inhibits the ability to take in precious lessons or advice. The great thing about having a habit of introspection is that you don’t have to do anything, this shell breaks down, becomes more permeable, and allows lessons to seep in.

Lots of small epiphanies > one big epiphany

I could tell you 4 or 5 pretty awesome stories of how introspection caused me to shift my thinking in a significant way, but that’s not actually what has had the most major impact on my personal happiness.

The biggest change has been creating the habit of cracking open this machinery to allow me to tinker a little bit, every day. Without much effort, by default I now observe my own behavior and thinking, ask why I did things a certain way, and wonder if it could have been done better.

Just like software developers get used to dealing with hard problems they don’t have answers for, introspective folks get used to challenging their own assumptions and cognitive biases and asking hard questions that may return answers they fear.

What’s the benefit?

Software developers know all about continuous improvement. That’s the whole promise of the Agile movement: small, continuous tweaks based on quick feedback to improve something until it’s shiny and wonderful.

Introspection is the path to an agile life: the ability to frequently refine and improve your interpretation of reality (and your behavior) until you are in a place where happiness is no longer dependent on external sources. And I’d contend that no one ever achieved happiness when it was dependent on external sources.

Introspection also allows you to confront and address the things you fear, to the point where you wonder why you’d ever feared those things in the first place.

Lastly, it’s a prerequisite for true empathy. Once you start asking yourself why you do things, you can’t help but wonder what you would do in someone else’s position. Empathy is a powerful ally (that’ll have to wait for another post), but I don’t believe I’ve met a person in possession of it who lacked the ability to introspect.

So the benefit is lifelong, intrinsic happiness. And mastery over fear. Also the ability to empathize. So, you know, good things.

How do you get it?

You could go become an addict and wake up in a pool of your own vomit. People often take stock of their lives and figure out where they went wrong when they hit “rock bottom”. It also carries with it some downsides… for instance, waking up in a pool of your own vomit. This also generally produces one large, temporary epiphany, rather than establishing a habit of introspection.

You could meditate. I plan to put this into practice in the future, but it’s not how I learned to introspect. I know some people who claim to meditate who aren’t particularly introspective, so it’s not a 1:1 ratio here.

You could ask others hard questions about you. I asked my wife recently if she was disappointed in me for gaining weight after having lost it, and she said “I don’t know… I guess I am.” That’s a hard truth to take in, but you can’t possibly claim to possess true introspection without being open to hard truths.

Hang out with truth-tellers. For my money, hanging out with truth-tellers has had more impact than anything else. Having close friends who are willing to call BS when I’ve deceived myself has precipitated my most painful lessons and greatest personal leaps forward over the past few years.

This is going to sound dumb, but also in this category, I’d put “listen to the Back to Work podcast with Merlin Mann and Dan Benjamin”. They are truth-tellers and you should just start at the beginning and listen to as many as you can stand, until you develop an internal Merlin Mann you can hear cajoling you into being honest with yourself.

Ask “5 whys”. This is a classic problem-solving technique. If you hit pause and analyze your reaction to something, ask why you did it, and why you did the thing that was the reason you did it, etc., you’ll often find it relatively easy to untangle the source and reasons for your own thinking and behavior. This is easy to do (but hard to remember to do) and yields lots of insight.

The temptation is to ask 1 or 2 whys and declare victory over self-ignorance. You’ll typically know when you’ve reached internal bedrock though, because it will be uncomfortable, scary, even painful.

Ask “what if I’m wrong?” When I have something negative to say about someone else and I’m feeling aware and introspective, I try to imagine the scenario that would unfold in the completely impossible event that I’m wrong. What if that guy isn’t a douchebag… what if he’s just trying to live his life like the rest of us? What if this thing that I blindly put faith and energy into is incorrect? This is the hardest to do by a long shot, so consider that the advanced course.

This stuff will change your life

I’m infinitely grateful for the friends and situations that I’ve encountered that have opened up this style of thinking to me. There aren’t many things I can share with people that I can guarantee will change their lives, but helping people trend toward greater introspection is one of them.

If you’ll put some of these into practice I can promise some new kinds of pain as you wince at yourself, but also a new or refreshed ability to take control of your own happiness, and even your life. I’m curious to hear back from you (here or on Twitter) if you have other methods of introspection, other examples, or if you find any of this to differ from your experience.

Learning to Program, Part III: Why you should learn (and why it’s easier than you think)

This is a part of a three-article series on my journey so far as a programmer:

1. How I learned to program
2. Programming lessons that changed my life
3. Why everyone should learn to program (and where to start)

I’ve previously said that the problem with attracting new programmers is not in explaining how to program, it’s in helping people understand why to program.

So why learn to program, aside from the life lessons mentioned in the last post? A lot of reasons, actually.

It really is a form of “digital literacy”. Even if you decide programming isn’t how you’ll make a living, having these skills is like knowing how your car is put together: you will often know how to fix problems yourself, but even when you have to take it to the mechanic, you’re more likely to be taken seriously.

You’ll run a better business. If you have an entrepreneurial bone in your body, learning to program is going to return rewards to you many times over when starting your own company. I’ve seen many startups fail because of poor technical leadership by founders, and many succeed due to good communication between management and engineering.

You’re uniquely set up to succeed. Whether your background is as a writer or a pizza maker, it will likely help bring a completely different perspective to programming, which benefits everyone, including you.

Don’t let your subconscious lie to you

One life-impacting lesson I’ve learned recently from Paul Graham is that we too often let our subconscious make the decision to steer away from things that seem difficult. We mentally file it under “impossible” and let our conscious mind plan our goals around the perceived roadblocks.

Let’s run through some of those:

“But doesn’t programming require a formal education?” No. Next question.

“Isn’t it hard?” Yes. But not in the way you’re thinking. It’s hard in the way that playing an instrument is hard, in that it is merely a matter of practice. In fact, learning to play a musical instrument is the most direct parallel to programming of which I’m aware.

“Isn’t it just for antisocial, nerdy guys?” Oh dear, let’s dive into that one.

First off, it’s time to let go of the programmer stereotype from the 1980s, because it’s not useful and no longer accurate. We have a whole new crop of stereotypes for you to choose from.

Most distressing is the fact that most women have had a lifetime of exposure to the idea that “programming is for boys”, and from a young age, mentally wall that area off. This costs us in software quite dearly, both in sheer numbers and in the diversity of perspective that smart women bring to the activity.

Don’t let a lifetime of people trying to intimidate you (even subconsciously) prevent you from realizing that you have all the capability they do.

Programming is a special ability, akin to a superpower. It transforms you from a consumer into a maker. But it’s not for special people.

Some programmers feel otherwise, that programming is something you need special skills for. Instead of punching them in the face, just remember that a few hundred years ago, these are the types who thought reading and writing should be reserved for clergy. Learn and make all you can, so that these code hipsters can someday complain that they were programming before it went all mainstream.

Starting on your own path

Learning to program isn’t as hard as it sounds if you’re working with people who know how to ramp up the difficulty properly (and speak English instead of jargon). The Learn to Program (Ruby) book I used is a tried-and-true introduction to programming concepts, and I recommend it highly.

Because I evangelize programming to non-programmers, I am often asked, “What language should I learn?” That actually does matter, but mostly because the quality of materials available varies greatly from language to language. This is why I’d say Ruby, Python, or Javascript are great first languages: the quality of instruction materials available for all three is quite good, and they’ll have you actually building things relatively quickly.

There are great resources for new programmers online at Codecademy (Javascript), RubyMonk, and Learn Python the Hard Way. But my personal favorite, by a wide margin, is Hackety Hack (Ruby).

Find the community

Plus, with those languages, there are communities of people who are knowledgeable and generally helpful. There’s simply no substitute for personal, interactive feedback with experienced mentors. Even as a brand-new programmer, I found the pattern of showing up to local Ruby User Groups and following the attendees on Twitter to be incredibly valuable. It helped me create a support network of people who could answer questions or buoy me up when I felt like I was underwater.

Finding a local User Group, following helpful people on Twitter, joining related IRC channels (I use the fantastic IRCCloud service for this), and generally trying to grab the attention of people who do this for a living are all good ways to help luck start to fall in your favor.

Later this year, my understanding is that Mendicant University will be holding classes for newer programmers, and that may be a great time to start. If your local programming groups don’t offer workshops for new programmers, I bet they’d be open to the suggestion.

If you’re interested in learning to program, find me on Twitter and I’ll do my best either to help you or line you up with people who can.

If you knew half of the doors it’d open for you, you’d be starting one of these books or tools tonight and beating down the door of your local programming community leaders to build an initiative for new programmers. If you give learning to code half a chance, I can promise that in some significant way, opening your mind to it will have an impact on the course of your life.

Learning to program, Pt. II: Lessons that changed my life

This is a part of a three-article series on my journey so far as a programmer:

1. How I learned to program
2. Programming lessons that changed my life
3. Why everyone should learn to program (and where to start)

In the last post, I talked about how I learned to program. This process has had a profound impact on the way I think, the way I approach problems, and my outlook on life in general. Here are just of the few of the lessons this process has taught me:

Unknowns are not bad. I used to work from a place of fear. If I didn’t know how we’d solve a problem, the risk was unacceptable and we’d abandon the effort. Programmers almost never know exactly how they’ll solve a problem, only that historically, they’ve been able to solve them. This is a much better place from which to start thinking if you want to change the world.

Breaking problems down is my job. Along with the last point, if a problem looked too complex, it was easy to get overwhelmed. But programmers know they’re the last line of defense: the enzymes whose job it is to break complexity down to manageable chunks. This is the key mindset difference that makes programmers so damn special.

Sharing is good. Previous jobs, Marketing in particular, taught me each and every idea is a trade secret and must be protected. Programming leads the way in thinking that “none of us is as smart as all of us,” which is part of why software is moving humanity forward at an astounding pace.

Black boxes are stupid and harmful. I used to think that if I didn’t understand how something worked, I probably never would. Programmers don’t allow “black boxes”: they have to tear everything apart to know how it works. It’s okay to not care how something works precisely, as long as you have a general idea of what’s going on. My friend Dave Brady calls it “Leaver’s Law”: “Anything that a system does for you, it also does to you.”

Sleep is amazing. Programming has taught me that your brain will chew on things for you and often bring you the answer after a good night’s sleep (or even a long walk). Letting your subconscious process things for you is a gift and a curse: I’ve had horrible code nightmares where I couldn’t solve a problem. But more often, I’ve awoken to find last night’s unsolveable problem quite easy to untangle.

You’re a free agent. I used to feel chained to my employer, completely subject to the ups and downs of the company. I felt if I lost my job, I might just die. Programmers tend to think in projects, and an employment contract is just that: a contract that needs to be mutually beneficial, or they’ll find somewhere better to spend their time.

Develop, then trust, your intuition. Programming is a surprisingly intuitive process. Things that just “feel wrong” or “feel right” typically are. You can then find the principles that define and back up these intuitive feelings.

People get paid to do this? If you don’t marvel at that from time to time, chances are your work isn’t aligned with your passion. Even on rough days, programmers generally have a sense of how fortunate they are.

Don’t give in to the overwhelming temptation to quit. The highs are high, but prepare for soul-crushing, ego-obliterating lows. It’s important to build a network of people who know exactly how you feel.

They’re not going to eat you. You will embarrass yourself. You will write hideous code. You will ask stupid questions. But all the embarrassment you’re conditioned to feel is unwarranted, because 99% of the time, sharing things you make with other makers is a safe thing to do.

It’s not as hard as it looks. There are a number of reasons that programming looks hard from an outsider’s perspective, but it’s only hard work (there’s a big difference). Things that appear to be a cliff to newbies actually have a gentler slope on the other side. It’s still a hike, but it’s doable.

Feeling dumb is normal. We’re trained like seals to bark the right answers back at teachers, bosses, etc., and to feel awful with anything less. Programmers get really comfy with not having any answers upfront, and finding fulfillment in the discovery process.

Your capabilities are limitless… eventually. Programmers are special because they tend to look at ignorance on a topic as a passing phase. Because they have to re-learn their own profession as it’s reinvented every few years, they know that given sufficient time and attention, you could become an expert on anything you want.

Show me the code. Years ago, I figured I had to try to play political games to get ahead. I even tried to learn to golf to get in my boss’s good graces (shudder). Not so with programming. Coders either deliver a result, or they don’t. Next to sales, it’s difficult to imagine a more results-driven culture. It’s basically impossible to BS your way through, because you either make things or you don’t.

Feedback is feedback. It’s better to move forward on the wrong information or without permission than to sit still and wait for the perfect opportunity. Being proven wrong is always an acceptable outcome, because it means you’re moving, and the “perfect opportunity” seems to prefer a moving target.

It’s about the journey. This is probably the lesson that’s had the biggest impact on my life. It’s too easy to become so focused on chasing some big reward while missing all the wonderful experiences in between. If you can’t enjoy the journey you’re taking, you probably won’t love the destination either.

Above all this, I’m generally a much happier, more patient person. I’m infinitely grateful to all the people who taught me these lessons and encouraged me to keep pressing forward.

Learning to program has changed my life in vastly more ways than listed here, and it’s why I’m so passionate about making the onramp less steep for new people. In the next post, I’ll talk about why you should learn to program and how you can get started.

Learning to Program, Part I: How I did it

This is a part of a three-article series on my journey so far as a programmer:

1. How I learned to program
2. Programming lessons that changed my life
3. Why everyone should learn to program (and where to start)

Quite often, when I tell people I left a career in marketing to teach myself to program and develop software, they react with surprise or even amazement. As much as my ego wants it to be, it’s really not all that special, and it’s something I believe anyone can do, and many should.

Here’s how I learned to program, how it changed my perspective, and how you can do the same without falling into some of the same pitfalls I did.

The spark of interest

After spending nearly 5 years learning online marketing for the startup I worked at, I had become profoundly unhappy in my job. The only path forward I saw for myself was “marketing guru” (ugh), and I was constantly depressed.

Several people, including my dad, suggested that I pick up programming, and that I might enjoy that more than my present career. I perceived it as a serious affront to my abilities as a marketer and fumed at the advice.

But eventually, I decided to take a few minutes to talk with our lead developer and brought the idea up. His response surprised me and sidestepped all my concerns: “Everyone should know how to program. It’s a part of living in modern society. It’s like knowing how to change your oil or change a tire.”

We talked late into the night, and he wanted to show me how amazing programming was. He wrote a little program in Ruby that would create different animals, give them stats, let them fight, and see who would win.

I watched the strange symbols dance around the screen and was totally fascinated and thoroughly confused.

He handed me Learn to Program by Chris Pine and suggested that I start reading it. He said that I’d know whether I had any interest within two weeks, and my response would be either “this isn’t for me,” or “people get paid to do this?”

Learning to program

I started in on the next night, and asked the second question within hours. Captivated, I spent every night for the next few weeks working through the exercises in the book.

Each day I’d run into the developers’ room to talk about concepts, check my code, or get help on the tougher exercises (looking back, a recursive algorithm for parsing an array of arrays is a bit much for beginners).

Clearly, it was a stroke of luck that I worked with wonderful, knowledgeable people who were too happy to help me along the path.

I continued this pattern of learning new concepts through several more books, the best of which was Beginning Ruby, by Peter Cooper. I then picked up Agile Web Development with Rails and started building Rails apps along with the tutorials. I was actually making stuff, and felt like I could take on the world.

Getting overwhelmed

From there, the books thing was working so well that I kept rolling with it. I picked up several advanced books that started to take me off track. Somewhere between Design Patterns in Ruby and Test-Driven Development, I started to feel like I’d gotten in over my head.

To make matters worse, I couldn’t separate what I was learning about Ruby from Rails. I didn’t understand where the language ended and the framework began. Did I have to read the whole “Programming Ruby” book? What about Rails books? What was MVC? I had to learn Javascript too? And CSS? And HTML?

I confided in my friend and admitted that I’d failed as a programmer. I couldn’t do it all at once, and there didn’t seem to be a way to break it up. He told me, “That’s enough, your problem is too many books. You need to write some code and go from there.”

My first projects

My friend was right: it was time to just start making things. I got tiny assignments from the dev team: small copy or functionality changes, or bite-size features that were low-risk if I failed.

The things I built were embarrassingly elementary, but it’s an amazing feeling to ship code, and I felt back on track.

I tried and failed at a few more side projects. I was wholly unprepared to build the square-foot-gardening app I wanted to make, having underestimated its difficulty.

It was about this time that the company started to go under and I was shown the door. I suddenly lost my support network, and it became more difficult to practice my coding skills.

Luckily, just a few months later, I discovered Ruby Mendicant University. Started by Gregory Brown, it’s a free online school for intermediate programmers with a strong focus on building stuff for real-life situations.

Going full-time

After completing the core Mendicant University course, my projects became slightly more ambitious: A video upload site that limits you to 1 minute (a terrible idea, if you’re considering it), then a lunch-voting app, ToDoGroove, and now Hashbadges, which is mostly under wraps for the time being.

Even with all that, I still had a mental block about becoming a full-time programmer. I was more comfortable hanging back a bit and helping manage programmers than trying to write code that would actually be used in the business.

Luckily, I had a friend call me out on this and tell me that it was do-or-die time. I either needed to start coding and stop making excuses, or be happy with a non-technical role. We spent the next week pair programming, and I realized that I really am capable of programming full-time.

That week, I moved my desk into the programmers’ area and decided to become a full-time developer. (Kudos to my employer for not firing me for that one.)

I’ve only been a full-time programmer for about 5 months, but it’s been the most fun and interesting few months of my career thus far.

I have no idea where the future is taking me, because I’m having so much fun with what I’m doing now. No matter what I decide to do next, the act of learning to program has taught me lessons that completely altered the course of my life.

I’ll outline those lessons more fully in the next post.

Stone soup and software projects

by Cyron via Flickr

Specifically, I’ve drawn a lot of value from the story of Stone Soup.

The story

For the unfamiliar, it’s a very old story of a tramp who travels to a town in search of some food. Hungry and destitute, he knows better than to ask the townfolk for a handout. Instead, he offers the villagers the best soup they’ve ever had, “Stone Soup.”

Having intrigued the villagers, he drops his “soup stone” in a large pot and brings it a boil. He tastes it, adding that it just needs a bit of barley and salt to be complete. Then, the story goes, he gradually asks other villagers for more ingredients to make it “just right”: chicken stock, celery, flour, and so on. Everyone shares in the soup, and the stone is extracted, ready to earn a free meal for its owner in the next town.

Starting with nothing

Most projects (especially software projects) are astonishingly like this story.

If you’re building software for a customer or group of customers, you must start with only a stone and a promise of soup to come. That’s probably a familiar feeling to many developers.

Unless you’re writing software to an exact set of specs (in which case, you’re doomed, sorry to say), your customers don’t know exactly what they want. They also don’t want to provide you with the tools, data, and requirements you literally can’t move forward without.

Making matters worse, their expectations are that you’ll magically appear with the project, after reading their minds, overcoming all obstacles, and satisfying all dependencies.

Stone soup is how you show them some of this magic.

Some see the tramp in this story as a charlatan, but I am going to use the term “instigator”: the guy or gal with the guts to set up a pot of boiling water and throw in the stone. The instigator goes out on a limb to make things happen.

Here’s how you can start making some soup:

Find your stone

You are now the keeper of the stone. You’re the instigator. Why you? Because you are probably the only person that knows there’s even supposed to be a stone.

In my experience, throwing the stone into the pot involves skipping a lengthy requirements phase and taking that risky first stab at the product.

There are arguments for building low-fi mockups and some for high-fi, functioning prototypes. As I’ve gotten better at building products, I’ve found high-fidelity prototypes to extract more valuable feedback.

I’ve also heard this called a “straw man”. The point is to start the conversation by putting something in a customer’s hands to either love or hate.

Adding ingredients

Projects often grind to a halt when people fail to deliver on their part of the bargain. This is where I’ve watched projects languish and then die.

Momentum is everything in this phase. No, you won’t get all the ingredients you think you need for your soup. But you do need ingredients of some kind or the boil dies down, interest is lost, and everyone goes home with empty stomachs.

So if one person or group isn’t delivering and is holding things up, it’s time to get creative. What can you put in that would move the conversation forward? Can you get data from a different source that would still be valuable? Can you show a reasonable facsimile of this feature using only the tools you have on hand?

This ingenuity both helps solidify the product and creates a vacuum for the actual item you need, pointing a spotlight on the reason it’s being held up.

The finished product

Actually, that’s kind of a misnomer. The product is never finished.

But after a few iterations on the original concept, you have something worth sharing, even if it’s not perfect. You may never have all the ingredients you’d planned on, but just getting the wheels unstuck generated an outcome that would never have existed otherwise.

At a micro level, the instigator never knew how the soup was going to turn out. The ingredients and tools on hand vary wildly. But at a macro level, he or she knew enough about the process to guide the participants to a shared goal: making something great.

Want to change the world? Be an instigator.

To be successful as an instigator, you must have a decent mental picture of how the soup gets made. If it’s a software project, you’d better have a working knowledge of the parts of the process, from servers, to data, to code.

Once armed with this knowledge, developing a habit of making stone soup is what sets leaders apart from those who are led. It gives you the ability to know that you’ll be able to deliver a result, even without a sure knowledge of exactly how you’ll do it.

Most people aren’t wired to want to be instigators. It’s scary and the risk of failure or embarrassment seems high. But it’s a skill that can be learned, and whether you’re a coder, a manager, or an entrepreneur, it’s required if you want to help lead successful projects and create great products.