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.
I am not aware of any studies about the difference in turnover between open- and closed-allocation shops, but Github has not lost an employee yet (although they have fired about a half dozen of their 150+). I can promise that when numbers on open allocation (non-) turnover are finally run, a bunch of MBA-types are going to start taking notice.
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.
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:
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.
This is a personal struggle for me, as I delight in finding just the right word to describe something, a habit that often irritates people with my ostentatious loquacity five-dollar-word jibber-jabberin’.
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?
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.
By this definition, B and C players are often insecure, complaining about office politics or “playing the game” against their successful peers. They hide their work, rarely shipping, in fear of criticism. They tend to wait for permission to move forward. They tend to wait for a lot of things to be in place before moving forward.
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.
You won’t have to work very hard to eliminate distractions, because the distractions that seemed so sweet and tempting before will taste bitter to you now. The desire to ask permission will be gone.
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.
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”:
Vision
Trust
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:
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.
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.
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.
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?
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:
Judgement/Objectification (or any act of self-betrayal)
Justification (the story we tell)
Realization of the act of self-betrayal
Desire to empathize & correct the action
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.
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.
Basically, introspection to me isn’t so much the act of introspecting as it is an openness to the lessons all around you, and specifically not closing off when confronted with things that are difficult to hear.
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.
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.
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.
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.
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.
Lately, I’ve discovered that processes are not the key to successful projects. But good metaphors lead you to communication shortcuts that sometimes are keys to success.
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.
This time last year, my wife and I were planning her escape.
We worked together at the same company, and she had a promising executive career track mapped out for her there. She’d been promoted several times, and would have actually been my boss (but for that bit about her being my spouse).
So when she talked about how unhappy she was, I resisted. I didn’t want to let her give up on a great career. We never loved the idea of conforming to stereotypical gender roles. And perhaps the fact that she brought in two-thirds of our income played a part.
Ultimately though, she helped me realize that putting our son in daycare and going to work was chipping away at her self-esteem and putting her into a pretty scary depression.
So, we started plotting her exit. If we could just pay off the credit cards, we could eke by on my income. It only took a few months of austerity before she was able to say goodbye to the golden handcuffs and stay home full-time.
A couple of weeks ago, while pushing Soren in the grocery cart, she ran up and down the aisles of the store to get a laugh out of our son, who invariably requests, “go faster, faster!” While speeding down the aisle and laughing herself, she nearly ran over a group of our former coworkers.
They stopped for a few minutes to exchange pleasantries, and she trotted off, a bit embarrassed for the display.
The picture in my head of that scene makes me a bit misty-eyed, remembering the depression and pain she was in while I was encouraging her to “stick it out”, contrasted with the carefree happiness of hurtling down a grocery aisle with our three-year-old.
My wife’s been a stay-at-home mom for nearly a year now, and it’s certainly been a tough adjustment. But as long as I can help it, I’ll never ask her to trade it back away. That was her dream, and she pushed herself and me until she reached it.
So now, I have to wonder: Is what I do every day the equivalent of running up and down the aisles? For sure, some days are like that. If not, what am I trading them for? How many of those days will I let pass without doing something about it?
“You have to face the fact that maybe you’re just unemployable.”
I flushed with anger. My dad knew my job was on the bubble, and it was a pretty callous and insensitive thing to say.
It wasn’t until a few years later that he explained that he meant that as a compliment. He said, “unemployable means that you stop being able to work for idiots, and you start realizing they’re all idiots.”
I still don’t know about the “unemployable” bit, but imagine the hell it would be to live as someone who fits that definition of unemployable and yet tries to fit into a mold of the model employee. I think I could live down the legacy of, “Wow, he sure was lame at working for idiots.”
I used to get frustrated with my wife for not caring enough about her work. Where was the ambition? Her coworkers and bosses recognized her potential, so why didn’t she?
It turns out that their (and my) mold for her wasn’t what came naturally to her. She wanted to be a mom, and she’s turned out to be so wonderful at it that I could burst with pride.
What about you? You’re probably awesome at a lot of things. You’re probably also lame at a bunch of other things. Those peaks and valleys make up your gifts, temperament, skills, and pretty much everything else that we cobble together to form an identity.
And it’s all too tempting to look around and see the peaks in others’ lives and fixate on the valleys in your own. How hypocritical and unfair is that?
If you’re anything like me, you too often spend your days filling in the valleys, obsessing over your weaknesses, then start piling up guilt for not having the time and energy to get it all done (which itself deserves another post).
Meanwhile, you’re sitting on a gold mine of talent. There are things you do naturally 10 times better than most of the people around you, and it’s likely that you’re downplaying those gifts to fit in a mold that was cast for someone else.
Most people I meet who feel insufficient and broken are exactly the right fit in a completely different puzzle.
The most innovative and successful people of our time have almost universally been unemployable misfits. The universe needed exactly them, and they were lucky or brave enough to discover why before they let society hammer them into the wrong holes.
Let me break it down for you:
(Stuff you’re good at) x (Time you have on earth) = Your impact
There is simply not enough time to get really great at everything, even if you did have the capacity. Which you don’t. Sorry.
I believe that if you’re not spending the majority of your days exploiting your own talents and experience, doing what comes naturally to you, you’re not having the impact you could at your work, in your life, or in the world.
This is not to say you won’t have to do hard things! But life is hard enough, you don’t have to dial the difficulty up and handicap yourself.
Stop for a moment. Think about what it is that you do really well. Do those things give you a multiplied impact where you are? If not, that may be a sign that you’re the exact right fit for something else.
Will this guarantee that you’re happy? No. But not following the simple formula pretty much guarantees you’ll be unhappy.
So go ahead, keep improving you, but exactly you is just great. You need no additional skills or experience to do amazing things. Ironically, to do so, you have to make peace with being lame at everything else.
Pop quiz: what’s your vision for your current job or project? For your career? For your life?
Don’t know? Many of us don’t. And that’s a shame.
You can knock the Color guys for having a comparatively short-sighted vision, but Nest creator Tony Fadell’s original vision was to be acquired by Apple. That seems to have worked out relatively well for all involved.
Whether they succeed or fail, they’re likely to win eventually, because they have a vision, and it’s theirs.
I spent years throwing myself wholeheartedly into helping realize “someone else’s vision”, but came up empty and disappointed. After that, I bristled at the idea of fulfilling and enriching someone else at the expense of my time and talents.
Back then, I used to sit around and wait for “leadership” to come down from the mountain with their “vision” engraved on stone tablets. But that’s a copout, and like all forms of giving away personal control and accountability, it’s likely to end in frustration and resentment.
Not long ago, I was talking with a friend who said of his boss: “I can’t wait to go make him a bunch of money.” I was surprised. Why would he want that?
When I thought about it, I imagined that it was twofold: 1) This meant my friend knew that if he could make someone else a bunch of money, he could do it for himself if he really wanted to, and 2) He got to have a clear idea of what he wanted to accomplish and how to measure his success.
After that, I started thinking about my areas of influence, the things I was good at, and the things I cared about, and picked something to try to drastically improve at my workplace. It wouldn’t be perfect, but it would be mine.
I now make a point of developing a very clear idea of what I want to accomplish and how I’ll measure it. It helps to write it down. I try to keep this vision short-term, and re-evaluate about every 90 days. I’ve also found that it’s crucially important that this vision is of your own making, and not handed to you.
Having a clear vision like that puts all of your thoughts and activities into a crucible. It’s easy to turn down distractions like needless meetings, tasks, or time-wasting when you have a strong, understandable, near-term vision for what you want to accomplish.
There’s a sort of primal, inherent fear of taking the risk in accepting that kind of responsibility. But if you really analyze it, would you trade risking greatness for a guarantee to wallow in the hell of mediocrity?
Yes, it can be scary. But if you are able to discover a vision, nail it down, focus on it, and achieve it, I promise you won’t find many things in life so energizing and rewarding. And it won’t be long before yours is the only vision you’re striving to achieve, while others line up to join you.
Think about it. Are you laboring for someone else’s vision? Have you been frustrated by it? What can you do to find your own?
His argument is that a decision without tradeoffs is not a decision. I assume the point was that without acknowledging that you’re giving something up, you’re probably deluding yourself into thinking you’re doing things “the right way” rather than “the best option given current understanding”.
I sort of have to infer that, because there’s no context or explanation. I would also assume that Seth would agree that those “decisionless decisions” are lazy and cowardly and optimized for shifting blame for failure, rather than a calculated risk with a specific reward in mind.
But I’d go a step further and say that unless you embrace the tradeoffs, you didn’t make a decision, you’re letting decisions feel like circumstances, and letting them push you around.
About a year ago, my wife and I made a commitment to getting out of credit card debt and letting her become a stay-at-home mom. She’s now been home for about 9 months, and it’s been wonderful in many ways.
But last night, I caught myself complaining about my financial situation. It’s our first holiday season on a single income, and some unexpected home repairs didn’t come at the best time.
The thing is, we knew this was coming. We knew we’d be making some sacrifices after years of high comfort and low worry. So it’s disingenuous to complain about it at all. It’s certainly not true of every couple, but in our situation, we’d much rather have a little stress about money and have the benefits of a stay-at-home parent. When I’m being mindful to embrace the tradeoffs, I’m immensely grateful that’s even an option for us.
Why embrace the tradeoffs?
It’s a formula for focus. Creating a product for a niche market imposes severe limits on mass adoption, but it lets you stop trying to be everything to everyone. For my wife and I, embracing the tradeoffs gave us the vision we needed to get out of debt.
It provides strength when you need it most. When people undertake something without predicting and embracing tradeoffs, the first serious challenges come as a shock, and this is where most people quit. Understanding and remembering what you planned to give up is often all it takes to stick through those rough patches.
It puts you in the driver’s seat. Embracing the tradeoffs means that even when everything isn’t rosy, the decision was yours, and you also have the ability to change couse if necessary. You’re not the victim of circumstances beyond your control, you’re experiencing the effects of a decision you made.
How do you know whether you’re embracing the tradeoffs?
If you’re complaining about your circumstances, I can pretty much guarantee you’re not embracing them. Any time you catch yourself complaining about a circumstance, you’re probably complaining about the effects of a decision that you made. This is, in essence, complaining that you can’t have your cake and eat it too.
If you’re choosing the lesser of two (or more) evils, it’s unlikely that you’re embracing them. This type of decision allows you to absolve yourself of the results of that choice, and lets you place the blame on the fact that your choices were limited. It’s nearly impossible to embrace the tradeoffs you make with this mindset.
If someone else is at fault, you’ve forgotten that you even made tradeoffs in the first place. This signals a serious need to dig deep and analyze the decisions you made that put someone else in charge of such a big part of your life.
This is a fundamental concept that means the difference between success and failure in business, and often between happiness and despair in life. It isn’t about taking control, it’s about taking responsibility and ownership for your decisions. Control simply tends to follow along for the ride.
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.
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.
Pop quiz: what’s your vision for your current job or project? For your career? For your life?
Sometimes Seth Godin’s posts are a
Recent Comments