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

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.

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?

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 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.

“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.

"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.

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?

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.

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.