Your “high bar” is wrecking your team

Near the beginning of my technical career, I worked at a fast-growing startup. One afternoon, my CEO walked into our dev area, which is something he never did. Some people in snazzy button-downs and sport coats followed him into the room, tipping us off that this was likely a show-and tell for some fancy VC-type folks in hopes of raising our Series E (or F or P or Z, who can remember) round of financing.

“And here are our developers. Everyone on this team has at least a Bachelor’s in Computer Science from great schools.”

I tried not to let my eyes bug entirely out of their sockets at this, and continued with my work. There were a lot of degrees in that room to be sure, but unless Salt Lake Community College secretly awarded me an honorary BA in Bad Sonic Fanart, none of them were mine.

But, sitting there in my sense of inferiority and exclusion, I knew for a fact I was a valuable contributor to that team! Even as a new developer, I learned fast, collaborated, and played a big part in getting our software shipped.

So when I tried to bring other people onto the team, I felt confident the right thing was in looking for someone with those traits. So after bringing in a couple of candidates I knew would make a great contribution, I was surprised to find out that my boss passed on the candidates, calling them “journeyman developers” and “not up to our technical bar”.

The cycle repeats

That’s the first time in my career I’d heard the phrase “keeping the bar high.”

A few recruiter calls later, we’d managed to hire some “star performers” with impeccable resumes who dazzled us with whiteboard acrobatics, while actual work tended to seize in the face of office politics and interpersonal turmoil.

I was puzzled by this, until I saw this happen again at another job. And again, and again. At one job, a CEO would screen candidates’ CS degrees among schools to make sure that we didn’t let in riffraff from lower-tier Computer Science programs (worth noting: to work on a team that I ran).

This rather bizarre logic planted a question in my mind: why are so many companies in our industry fixated on setting and protecting a “high technical bar” when this makes their teams worse by all measures of output, product quality, team diversity, and turnover?

Who decides what the bar measures?

Maybe before we can answer that question, we need to ask: what does a “high technical bar” even mean? That phrase carries with it a self-important sheen of “rightness” and “intellectual rigor” even as it hides a mountain of bias.

It’s lunacy to think that a software developer could contribute along only one axis, but “the bar” is almost always set along exactly one: amount of exposure to a formal computer science education.

Almost every software developer in our industry with a CS degree will tell you they “dust it off” periodically for some classes of problem, while most of their day-to-day is work they learned on the job. But the majority of technical interviews still focus heavily on the skill of solving algorithmic problems on a whiteboard or demonstrating the ability to classify algorithms in big-O notation.

That’s why all these “mastering the tech interview” blog posts and books are filled with back-of-the-book solutions to common computer science algorithmic puzzles.

So you have a “high technical bar” that you assess via puzzles whose solutions can be memorized from a “hacking the interview” book. Cool, let me know how that works out.

Maintaining the high

Congratulations! You’ve assembled your “Avengers of code” via puzzles, brainteasers, and discussions of esoteric language features.

We are a team of the best, because we only hire the best, because we have a high technical bar. QED.

And it just so happens that this reinforces the egos of team members, executives, investors, etc. At one company the CEO used to talk about how this was “the best engineering team ever assembled”, on repeat, despite zero evidence in the form of shipping software (and significant evidence to the contrary once that software actually did start shipping). Who wants to argue with someone telling you you’re the best?

But how do you keep this rolling? How do you avoid the other shoe dropping once the team is actually expected to ship working software?

Well, that’s where the shit starts hitting the proverbial fan.

Setting the bar on your team


Even after expectations move from “we hire only the best” to “where’s my software”, you’re still left with the residual effects of this culture of bar-setting. People in these cultures tend to “set the bar” for each other and expect their team members to jump over it.

This means people on bar-setting teams are sitting with their arms folded, waiting for candidates, and ultimately their teammates, to fail their expectations. And when they inevitably do, we “flip the bozo bit” and ask why we have “B players” on our team.

It’s hard for me to imagine a less healthy environment than one where a group of people sits waiting for their teammates to fail them in some as-yet-unimagined way, but this culture is very real and very common.

Helping each other over the walls


The frustrating thing about this tendency toward setting each other up to fail via artificial bar-setting is that there are very real walls that we as members of a team need to climb over to get our products out the door and solve real-world problems.

We have deadlines to hit, bugs to fix, logs to read, 1 AM pages to answer. We have customers to serve, teammates who need our help, and yes, in some cases, investors to impress at the next board meeting.

The least productive teams I’ve seen are so focused on whether their teammates should be there in the trenches with them that they aren’t focused on the fact that they’re all on the same side of the battle. They’re so fixated on making sure every hire is a CompSci superstar that they can’t see the prismatic rainbow of skills it takes to design, ship, and support software that withstands the harsh realities of real-world use.

The most productive teams I’ve been on are the ones who are pulling each other over these walls in the battle against real-world problems. No, that doesn’t mean that you can pull 10 random software developers together and have an ideal team, but I’d rather have 10 random developers who are in it for each other than 10 superstars who will bar-set each other to a standstill.

A note on “lowering the bar”

One phrase in hiring I dislike more than a “high technical bar” is “lowering the bar”. This one is more insidious, more intellectually dishonest, and drips with even more gatekeeping bias.

It’s almost always used to avoid having a conversation about including a more diverse set of folks on a team. “We want to include more diverse folks but we don’t want to lower the bar,” means a team is considering a candidate that might bring something different to the table but that “something different” is not measurable on their yardstick of Computer-Science-derived technical merit.

I think that often, these people aren’t really worried about a “lower bar” as much as the ego-threatening possibility that their formally-trained “hard skills” could be comparable to, or *gasp*, less valuable than, informally-learned “soft skills” like mentorship, compassion, leadership, or collaboration.

I know a lot of people who have a formal CS background who deeply value the skills along these other axes, and I have never heard any of them express any concern about “lowering the bar”. Just saying.

Bar-setting is a failure of management

If you find yourself on a team of people who are setting a bar for each other rather than helping boost each other over walls, it doesn’t mean the people on the team are bad. It does, however, mean that your management is definitely failing you.

What you are likely dealing with is a team that is incentivized to tear each other down rather than deliver a result together. Your management is failing to help you find and focus on a shared purpose beyond “managing the optics” of your individual performance.

If you look around and you don’t see people who are different from you, from different backgrounds, it’s likely your interview process tends to select the same “high performer” over and over again. Your management is failing to value the variety of skills it takes for a team to create and support a product.

So what can you do?

Whether you’re a contributor or a manager, changing culture is hard. Your influence may be limited. So how can you help shift away from a culture of bar-setting?

And if these things are fundamentally out of alignment with your workplace’s values…

  • You can (hopefully) leave.
  • (And if you can’t leave, maybe you can start a support group)

Goodbye bar-setting, hello wall-boosting

On a healthy team, you won’t hear a lot about a “technical bar”, but you will see a group of people focused on a shared goal, helping each other over barriers, and getting software out the door. They’re not perfect, but they don’t need to be. They tend to focus on making their customers happy, learning from their mistakes, and helping each other get better.

I’ve worked on both kinds of teams, and I’ll bet my career on wall-boosting teams over the most talented bar setters. By starting small, you can create an example of success. With success, you just might get your team to buy in. With some results and buy-in from the team, you can teach your team’s leadership that larger-scale cultural change is possible.

Who knows, if enough of us can show off what collaborative, supportive, inclusive teams can do, maybe we can bend the arc of the industry in that direction. It’s worth a shot.


Letter to an aspiring developer

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

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

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

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

1. Getting your foot in the door in software development

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

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

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

2. Setting long-term goals

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

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

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

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

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

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

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

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

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

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

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

4. The type of culture to select for

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

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

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

5. Building your mentorship

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

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

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

6. Practice shipping

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

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

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

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

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

7. College degrees are not for job applications

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

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

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

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

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

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

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

8. Switching jobs

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

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

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

A note on self-effacing honesty:

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

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

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

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

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

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

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

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

Closed allocation: A failed system of control

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

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

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

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

This is the curse of closed allocation.

The article: You should read it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open Allocation gives you rocketships

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.

Ali vs. Liston by Dave Rr via Flickr

Dumb stuff we say to non-programmers

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

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

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

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

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

There’s no “PTC”

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

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

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

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

Terms that shut out non-programmers

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

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

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

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

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

The danger zone: misunderstood terms

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

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

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

My favorite programming metaphors

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

  • Yak shaving
  • Cargo culting
  • Bike shedding

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

A path forward

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

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

Solution part 1: Shared definitions

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

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

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

Solution part 2: Conversational empathy

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

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?

Ruby DCamp: What I learned on summer vacation

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

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

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

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

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

The venue

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

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

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

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

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

The Format, Day 1: Code Retreat

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

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

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

The Format, Day 2 & 3: Unconference

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

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

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

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

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

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

The Community

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

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

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

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

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

The Food

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

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

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

What I learned

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

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

Several of the sessions stand out in my mind:

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

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

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

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

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

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

DCamp’s mission

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

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

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

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

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

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

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

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

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

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

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

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

Don’t let your subconscious lie to you

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

Let’s run through some of those:

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

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

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

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

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

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

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

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

Starting on your own path

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

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

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

Find the community

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Learning to Program, Part I: How I did it

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

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

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

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

The spark of interest

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

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

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

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

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

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

Learning to program

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

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

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

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

Getting overwhelmed

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

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

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

My first projects

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

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

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

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

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

Going full-time

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

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

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

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

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

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

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

Community is my lifeline

Utah Ruby Users GroupNovember 10th, 2009 marked a pretty dramatic turning point in my career. The startup I worked for was in a tailspin, and a friend who’d escaped invited me to visit his new workplace for a meeting of the Utah Ruby Users Group.

This was the first time I’d attended URUG, or anything like it, and it was scary as hell. There were smart people talking about things I didn’t understand, and a guy in a fez who seemed to be asking lots of annoying questions.

Mike Moore showed off a fascinating new technology called Ruby Version Manager by a fellow named Wayne Seguin. People talked about the dramatic changes in Rails that would soon take place due to the work of people like Yehuda Katz.

I was literally incapable of processing about 90% of the conversation in the room, and terrified someone would ask me to say something and expect me to do anything but make a fool of myself.

Even though I was so bewildered that I literally cannot remember who was at that first meeting, I’ve since learned that at several of the people were there are now some of my closest friends. Over time, I became a part of this community that literally saved my career.

Here’s why I think the URUG community’s been so important to me:

1. It’s consistent.

It’s easy to forget now that there were moments where I very nearly gave up on breaking into software development. It would have been so easy for me to go back to marketing, and I had several opportunities where I could hang up my still-new coding spurs and have a long, prosperous career with the word “product”, “process” or “manager” in the title.

But I got to associate with the people at URUG every month, and I was able to keep my eyes on the prize. It repeatedly connected me with me the kind of people I wanted to emulate, and the kind of work I wanted to do.

Just having a single night where I knew I’d be around great people was an anchor when becoming a software developer still seemed like a distant goal.

2. It’s accepting.

The guy in the fez may have been irritating, but nobody chased him off. I was irritating, I’m sure, and nobody chased me off.  It was the only time I was able to have a face-to-face discussion with experienced Rubyists, ask my stupid questions, and come back next month with more.

Never once have I seen behavior at a URUG meeting that I felt embarrassed by, nor do I hear people say negative things behind others’ backs. I’m very proud to say that the kind of people who show up to user groups seem to be the kind of people who are interested in building one another up.

3. It’s a chance to contribute.

I once wrote a blog post about why I don’t contribute to open source, and now I realize I missed the point entirely. A friend pointed me to an old talk by Chad Fowler, one of my heroes, where he mentioned that people should contribute in their own specific ways.

My problem was that I was trying to contribute to the community in exactly the same way as people who are the best coders can contribute. So contribution felt like an obligation that I was failing.

That’s why one of my favorite things about the URUG is that everyone is, at some point, asked to participate. Even as a brand-new coder, I was given a topic to research and come back to share the following month. I mangled it, I’m sure, but the group interacted with me, applauded, and I gained the confidence to do it again later.

User Groups are a wonderful way for people to ease into contributing to a community without feeling like they’re competing with ninja-coder strangers on the other side of the planet. In fact, it’s so sneaky that you may not realize that you’re contributing just by being yourself and showing up.

My opportunity to help

Last week, I was asked if I’d be willing to handle the responsibility of organizing the Utah Valley Ruby Brigade. It’s intimidating, as I haven’t done anything like this before, but I am so grateful to be getting a chance to contribute the best way I know how.

At lunch with Mike Moore this week, we briefly talked about what sort of “outreach” programs we might offer to newbies. I do teach a programming class to non-programmers and think that’s a fun and noble goal. However, the most valuable thing is what URUG already offers: consistent meetups with friendly, smart people who are actively invested in one another’s success.

I can’t begin to thank Mike Moore and Jake Mallory for their work in maintaining URUG, and hope I can put at least some of the value in that I’ve received over the last two years.

For now, the best I can hope for is to bring my newcomer’s enthusiasm, not break the things that are working, and learn the rest as I go along.

Mentorship-Driven Development

I spent a good chunk of my Sunday pair programming with a friend. It was sort of a TDD bootcamp, and I wondered what, if anything, he was getting out of it.

My guess is that he’d been mentored in the past by smart, patient people, and felt compelled to help another person along the path. Or maybe it’s just because he’s a cool guy. Either way, I’m grateful, and I can’t wait to someday be in a similar position to pay this forward.

Programming, especially in languages like Ruby and Python, is a heavily mentorship-driven activity. There are no colleges that I know of that place a focus on learning these languages. Few develop these skills in a total vacuum. (And you don’t typically want to work with those who did.)

Here are a few things I’ve learned about mentorship, especially of late:

Advice for Mentors

If you’re even marginally interested in acting as a part-time mentor, these are some fantastic behavior patterns to follow. I observed many of these while working with several people whom I see as top-class mentors:

Be patient, they learn slower than you do and will often be flat-out wrong

Ask questions you already know the answer to and let them come to a realization

Give them space to screw up. That means their hands are on the keyboard, at the whiteboard, etc.

Ask if you can be candid. Sugar-coating your feedback is a great way to make sure they don’t make progress.

Advice for Mentees

Ya’ll better recognize that you need a mentor. It’s easy to get stuck in a rut when surrounded by books and your own problem-solving skills. A few hours with someone at a higher experience level can change your entire perspective on some key concepts. Do this often enough, and you’ll grow by leaps and bounds.

You’ll probably have to build a “patchwork mentor”. You’ll likely have to stitch together a semi-cohesive mentorship out of hundreds or thousands of little interactions over the course of time.

Some people are better at mentoring than others. You will probably work with some people who simply don’t have the patience to teach you. Don’t get frustrated, they have a job to do, and you may be better off seeking help from people with a deeper well of patience, at least for now.

Some people are better at being mentored than others. Being mentored is a skill that requires just as much patience as mentoring. You have to work at developing your own patience.

Don’t take it personally. Being wrong is fine. You’re going to get honest feedback, which you need desperately right now. Your mentor may even get frustrated with you. Don’t use that as an excuse to quit.

You’re going to get directly conflicting advice. Just pick the advice that feels right and go with it for now.

Take the wheel. Don’t be afraid: you’re in a bumper car, not a Ferrari. Butt in and ask if you can drive.

Get some alone time. Go ahead and make a mess on your own, then set up code reviews to point out how you could have done better.

Be grateful. Humility is the only weapon you have to keep your mentors around and to actually learn from them.

Building your own mentorship:

Here are some ways you can build your “patchwork mentorship”. I can vouch for all of these, as they’ve all benefitted me:

User groups: I cannot overstate how much these have helped me. They dot the land. Attend one.

Mendicant University: Free online courses for intermediate Rubyists. It’s close to my heart.

Screencasts: I recommend Railscasts (free) and PeepCode ($)

Remote pairing: Evan Light just created a site for this.

Stack overflow: I mostly just lurk, but there are a TON of smart people waiting to help here.

Rails core code: Don’t be afraid of it. Dig in and see some well-crafted code.

Test suites: This is my preferred method of seeing how you’re expected to work with a codebase.

Code reviews: Go make a mess. Then let an experienced dev help you clean it up. This is powerful.

Open Source Software projects: A patient maintainer can make a great mentor. OpenHatch is a neat place to find one.

IRC: Hanging out in IRC chat is how a lot of experienced people stay in touch, and they can sometimes spare a minute to answer a question.

Blogs & Twitter: Reading good blogs or following smart people on Twitter is like having access to a factory that manufactures insight. I don’t have room to point out all the programmers who have influenced me through blogs & tweets, but they are numerous and I am grateful.

Books: Books are great. I’m a big fan of Pragmatic Programmers. Though, at this stage, I’ve often found it more productive to try and write code and then get feedback, versus the one-way communication a book provides.

Learning from a mentor is hard work. Piecing a mentorship together can be even harder, though it doesn’t need to be.

I hope this is somehow helpful to you if you’re looking for a signpost on the road to becoming a better developer.

Some of the best programming (or life, in fact) advice I’ve received

via Chat in the Hat/Flickr

“Your problem is not at all what you can and can’t do, but rather your expectation that things should come easy to you.”

Gregory Brown earned his spot in the Ruby Heroes roster more than a year ago, but he’s earned a central spot in my personal constellation of heroes (and friends, if I can be so bold as to claim him).

It’s been about a month since he wrote this to me, after I came into the IRC chat room, feeling like a complete fraud and failure as a programmer. Tonight, I’m rolling that sentence around in my head, and it cuts so deeply to the heart of one of my most cherished beliefs: that I am a smart, talented person who catches on to things quickly.

“You think things should be easy for a ‘real programmer’, and get frustrated when they’re hard for you.”

This belief in my inborn intelligence/talent backfires hard (and there’s a lot of science to back this up) when it comes into conflict with personal experience. When I face a problem I can’t solve alone, I’m stuck. Either I’m an idiot or the problem is so hard as to be unsolvable.

“So you work extra hard, thinking that will help you catch up.”

Historically, I’ve let my ego tell me the problem is unsolvable and I’d give up. Over the last year or two, I’ve discovered that I can throw extra effort at a problem, work day and night, and get some of the same results that more experienced people get in half the time.

But this is a hack! It’s unsustainable, and only temporarily props up my belief that I can accomplish these “out of my league” problems alone. Sooner or later, I’ve vacuumed the joy out of the problem-solving process and learn to fear and avoid it altogether. I believe this may be one of the primary sources of that complex state we call “burnout”.

“Just get the help you need from those who will spend time teaching you.”

This is the ultimate ego smasher: asking for directions. It’s so simple, so why don’t we do it more often? If you’re a programmer, you almost certainly know programmers smarter than you who know the lay of the land and would be happy to help.

Men famously hate asking for help, while most women I know find the “I must persevere alone” mentality ridiculous. This point of gender differentiation is one of the reasons I think it’s an absolute crime that we don’t have more women in programming.

“Most ‘easy’ programming things are only easy because you’ve done them 100 times and learned them years ago, not because they were easy to learn.”

Ultimately, patience with yourself is at least as much a virtue as other forms of patience. It may perhaps be the sigle most important kind. Dave Hoover, in his excellent Apprenticeship Patterns book, really tries to get you to reframe, moving the camera back so that you can take a view of your skills in terms of decades, not weeks or even years.

Lastly, it’s important to find that person or group you can turn to in the moments you feel stuck and inept. I am fortunate to have an awesome support structure through friends I’ve met in the Utah Ruby Users Group and Ruby Mendicant University.

Thanks Greg, for the advice and for giving me a place to go when I feel stuck. If you can be as patient with yourself as Greg has been with me, you’re going to turn out just fine.

Please watch this video.

Greg Brown, creator of several open-source projects and the free online Ruby Mendicant University that I participate in, put together an incredibly thoughtful video addressing my most recent post, point by point.

Thank you Greg, it’s incredibly enlightening. I still plan to collect the best of the responses to that post, but by and large, this pretty much covers it.

Why I still don’t contribute to open source

Via zen on Flickr

I am such a hypocrite. A few months ago, I posted about overcoming my fear of contributing to open source software.

Since then, I still haven’t really participated. On Twitter, I commented that OSS looks like a shark tank to newbies, and I need to back that up.

The fact is, I actively contribute in some fashion or other in several open source projects. But I still feel very much like an outsider, as my contributions aren’t typically code-related.

So why am I (and I assume, many others) still an OSS wallflower?

At the profound risk of projecting my feelings onto other people, I would like to share some objections that I feel may cause new(ish) devs to shy away from contributing to open source software.

There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”. (Though there is one for afterwards.)

It’s not obvious where to start. From what I hear, a lot of OSS contribution comes because a person needs functionality in a piece of software that isn’t there, or finds a bug. They can submit a failing test case or even a patch. In my daily use, I don’t run into many of these situations. There aren’t many devs sticking their hands out asking specifically for help on a project, and fewer still who would be willing to take a newer developer under his or her wing.

Guidelines often make a maintainer’s life easier, and mine harder. Yes, maintaining an open-source project is an arduous, thankless task. But I’ve looked at contribution rules/guidelines that turn a simple idea for a fix into a bureaucratic brick wall worthy of Microsoft. A notable contradiction to this would be Wayne Seguin’s welcoming contribution page, complete with tutorial video.

Open source is for people who are better at this than me. I realize this is probably a copout for not shipping, but I am just not comfortable that I’m at a place where I could release software that’s good enough for actual developers to use.

Trying to contribute and failing makes me feel stupid. I’ve submitted several pull requests now and had 0 accepted with no comments as to why. It’s like the universe is confirming that yes, I am an idiot, and my “help” is not helpful. What a profoundly embarrassing waste of time!

There’s no time. I have a kid, a new gig, and a mounting set of responsibilities. It takes me 3-10 times the amount of time to write code as a more experienced developer. Now, my non-code-related contributions are now eating up my former “coding time”. Yes, it’s the universal excuse, and one that I think melts away when the other excuses are removed, but it bears mentioning.

It’s pretty lonely. I think most people figure this stuff out on their own, and so maybe expecting a hand to hold is too much. But is this really some spirit walk, where no one is allowed to accompany you, lest you learn nothing?

So yes, OSS can feel daunting, even like a shark tank. I don’t have all the answers to these issues, but I’d like to see more maintainers seeking contributions with some specificity, and then actively responding to pull requests. A call for additional test cases. Bug fixes. And yes, documentation.

For all the openness of Github, there’s no Quora/StackExchange-type system to let you know which projects are in need that you might be a match for. Seems like that’d be a good feature.

RMU Round 2: What I learned

Note: This is the third of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course


While the previous post was about the tools I learned to use, this post is more about my successes, my failures, and the philosophical things I’ve picked up in this session.

My successes & failures:

Styled website WIN.

While I wouldn’t say I could jump in and whip up raw CSS from scratch, with the toolkits provided within Compass, Sass, and Blueprint, I can kick out a decent web stylesheet pretty quickly and without a lot of fuss. Most of the intimidation I felt about CSS was groundless, though it can still be punishing at times.

Web Fonts FAIL.

I tried several things, but couldn’t figure out how to replace my default font (Helvetica) with a font using Google Font Directory. Web fonts became a fight that I’d just have to have another day.

Overlapping styles FAIL.

One thing Compass lets you do is cleanly separate your stylesheet partials on a page-by-page basis, which seems to be how Jordan does his. I opted instead to create partials on a per-type basis (one for forms, etc.), and this bit me badly later.

I altered the styling of my form partial for an entry form, only to go back through my app just as I thought I’d finished to discover I had completely broken my file submission form.

This added lots of extra work when I felt utterly done with the project, and actually led to my epic Git FAIL.


This was the second major time I severely frustrated myself with my lack of Git knowledge. I didn’t realize git -rm actually deletes a file, rather than a reference to a file, and I did a git revert to before I’d fixed a bunch of broken stuff.

In the end, I wound up swearing at my computer a lot and ultimately re-doing a lot of work.

At my next convenience, I’m going to go through Jim Weirich’s Git Immersion, it’s an open tab in Chrome right now, waiting for me to learn how to suck less at Git.

Learning jQuery FAIL.

I had planned on learning jQuery as a part of this course, and it just didn’t happen. I watched a few screencasts and read up a bit, but didn’t find occasion to even dip my toe in the jQuery pool.

GeoKit WIN.

GeoKit is just awesome. It’s one of the nicest, simplest, and most useful web API tools I’ve used so far.

Google Maps FAIL.

I had assumed that someone would have written a nice Ruby API for Google Maps. The answer is “no, go learn Javascript and do it yourself.”

To embed a map, you have to stuff a lot of Google-specific code in your <head>, which doesn’t play nice with the concept of a layout page. It really doesn’t play nice with Haml, so it was back to ERB for me.

Even though I could look up an address and make a map display, wiring them together required a lot of work from Jordan to fix my mistakes.

On confidence:

This was a big confidence booster for me. The only thing standing between me and getting a website done is making the time to do it. If you want something, just do it.

On pacing:

The September session taught me that when you have 3 projects to accomplish, don’t wait until you’ve finished Project 2 to move on to Project 3. Start planting the seeds for all your projects early on, so that you’re not rushed to do 100% of anything in the last couple of days.

Or it *should* have taught me that. Instead, I tried to accomplish my projects serially, spending a few days on Project 1, then more than 2 weeks on Project 2, and less than 48 hours on Project 3. Needless to say, Project 3 was a bust.

On sleep:

Toward the end, I was working until at least 2 or 3 AM every day trying to get my app styled, and sleeping an average of 4 hours a night. Greg told me to ease up, that RMU isn’t meant to upset someone’s life balance. He was right that I was pushing myself too hard, as I have a tendency to fixate on a goal and not let up until I’ve finished, even when that isn’t the wisest course of action.

However, I like the idea of “excess, in moderation”. I pushed it really hard, but not so hard that I’m burned out from further work. Maybe in another 6 months or so, I’ll do another sprint where I immerse myself in learning some new thing or breaking some perceived barrier.

If I could go back and change things, I’d probably have scaled back my ambitions somewhat and pushed the average up to 5 or 6 hours a night. I think people were starting to notice that I was cranky.

“No heroes”

Greg added that RMU isn’t about elevating heroes. I hope my crazed ambition is not perceived as any kind of heroics, because RMU is a pretty personal journey for each student. There is no Honor Roll, there are no gold stars, and there’s no valedictorian. It’s not for one person to try to set a high score. I was striving for a very personal goal, to conquer my hesitance to design a website, and I feel like I (barely) achieved it.

Finally, thanks

Lastly, I want to reiterate my gratitude to Greg for running RMU and to Jordan for his inordinate amount of work in helping me achieve my goal for the session. I still have a long way to go before I’m a “real Rubyist” or a “real web developer”, but I’m much closer than when I got involved in RMU.

RMU Round 2: Process, Tools, & Techniques

Note: This is the second of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course


This post is more about the process and technical challenges I faced in creating a full layout for the first time. In my final post on the topic, I’ll share more of the general lessons from this session.

For me, the process went as follows:

1. Mockups

2. Backtrack & fix (set the stage)

3. Create assets

4. Implement styling on page-by-page basis

This, with a lot of reading and learning about tools & technologies I needed to get the job done.

The mockup stage: Balsamiq, etc.

I cannot tell you how critical this is. The mockup stage is the part where you think through all the user’s paths through a site, what they’ll expect, and what context they’ll need to get what they want. You get a sense for visual priority and information design. All before writing one line of code.

The visual context simply cannot be guessed at or thrown in during implementation. My opinion is that if you’re not doing a thorough mockup before coding, you’re probably going to screw something up pretty badly.

I’ve used a lot of different mockup tools, including sharpie/paper, Mockingbird, HotGloo, Keynote UI templates, and iMockups for iPad. Balsamiq is my personal choice. You can learn it in 20 minutes, and cloning your mockup and then exporting a bunch of tabs to .png will save you lots and lots of time. My 2nd choice would be sharpie/paper.

Once it came time to actually style the pages, designing to a mockup didn’t tie my hands at all. It actually liberated me to work within the framework to offer the best presentation possible, without worrying about fundamental questions like whether to choose a 1, 2, or 3-column layout.

It took a few hours to think through properly, but I got those hours and more back when it came time to turn those mockups into styled pages.

The “Fix the broken pieces” stage

So far in my work at the office and in RMU, one consistent theme is that the thinking you put into the mockup stage will reveal flaws in the existing plan or implementation.

In this case, there were unfinished pieces of the app; features that were clearly intended but not built out, like an Announcements feature and a Puzzle Details page. The lesson here (intended or not) was that in order to move forward, you’ve often got to move back and clean up a little bit.

Once this was done, the stage was set for some actual design.

The “create assets” stage

This one seems optional, and Photoshop skills are not necessarily required, but I was sure glad I had them. I didn’t do any high-fidelity mockups or anything, but I did create my logo & background images, and tweak icons.
I also used a nifty little site called Stripe Generator to create repeating stripes, which is usually a laborious process involving Illustrator and/or Photoshop.

Last stage: Styling

OK, enough playtime. Now it was time to jump in and get my hands dirty. And then–

Haml, WTF?

I jumped into the project and immediately came to a screeching halt. Instead of my more-familiar ERB syntax, the views were in Haml.

Immediately, I was faced with 1) converting all the views to ERB, or 2) Learning enough Haml to get by. I figured that converting the Haml to ERB would require nearly as much research as just keeping it, so I decided to stick with Haml.

This was itself a crash course, and I came away both impressed and frustrated with aspects of Haml.

What makes Haml so great?

There are no closing tags. It has a Ruby-esque syntax, and it’s much easier to drop in native Ruby than in ERB. It uses CSS-style selectors. It’s terse, clean, and easy to read, once you’ve got the hang of it.

There apparently used to be serious performance issues, but they’ve since been ironed out, and Haml is about on par with ERB for speed in compiling to HTML.

What makes Haml frustrating?

There are no closing tags. That means that you’re in the realm of “significant whitespace” in your views. Personally, I don’t like having my views fall apart and spit an error at me because of my indentation.

Haml is optimized for cleanliness, not flexibility. Perhaps the most damning thing about Haml is that you can be almost certain that you’ll need to fall back to ERB (or have Haml interpret HTML via plain text, ugh) eventually for some edge case. If it works in HTML, it works in ERB. Not so with Haml. You’ll either wind up twisting something straightforward into knots to fit into Haml’s syntax, or fall back to ERB.

Would I use Haml again?

Basically, Haml is a lot more fun to work with than ERB, right up until it’s much, much worse. One surprising thing is that you don’t have to choose; you can use Haml most of the time and use ERB for your edge cases.

Yes, Haml did add a significant amount of time to my project. But depending on the project, it’s likely I’ll use it again in the future.

Once I got the hang of the markup, it was time to start styling my project. I wasn’t sure where to start, having never styled a page from scratch before.

But after my first go-round with CSS, I started getting really frustrated.

**Does CSS Suck?**

That’s a total troll question, so I’ll rephrase:

How did people do layout before Compass & Sass?

We had a pretty heated debate in the #rmu IRC room about whether CSS sucks. The sticking point was that an educational context basically isn’t a place to say that any given tool sucks.

But it’s a good question: Does CSS suck? Greg Brown has created a layout framework for PDFs in Prawn, which taught him that creating a flexible layout is a hard problem, and CSS has spent 10 years doing a pretty good job of solving that problem.

But Ruby developers used to having a universe of capability and spoiled on the “principle of least surprise” get a rude awakening. CSS is a crappy programming language, if that’s what you’re expecting.

With CSS, I kept having the experience of “tweak, tweak, tweak, KABOOM”. A small change may mean nothing, or that your layout collapses entirely, or your signup form is wrecked because of a seemingly unrelated change for another page.

That said, there are some frameworks that turn CSS into much more of the programming language that developers expect.

In fact, when it’s all working together well, I’d say that Haml/Sass/Compass/Blueprint combo is a pretty friendly way for developers to do design. Here are the pieces, broken down:

Sass: CSS, but like, for programmers. It adds some powerful features to CSS:

Variables (e.g. $light-gray: #f7f7f7)

Mixins (e.g. @include bordered-table)

Nesting & Inheritance (I didn’t use these much)

SCSS: It’s Sass but with CSS syntax. Basically, Sass is for people who really hate braces and semicolons, and SCSS is for people who want CSS compatibility. SCSS seems to have become the de facto standard for new Sass projects.

A very minor gripe is that because of the syntax change, a lot of the tutorials you’ll see will be hard to understand in SCSS, as Sass was the preferred syntax at the time they were written.

Compass: Compass doesn’t do a good job of delineating its role from that of Sass. The fact is, the majority of the benefits they claim come from Sass, but the additions Compass brings make it absolutely indispensable to me now:

The ability to define and mix in partials

Auto-compiling for Rails projects

A whole bunch of pre-defined (and easily configurable) mixins.

Compass gives you a nice framework to start from, and a project folder that is relatively easy to keep clean and organized (though I did manage to mess that up later).

For an example of the benefits of Compass/Sass, if I wanted a drop-shadow and border-radius on a div, first I’d import the partial:

@import "compass/css3";

Then I’d include the predefined mixins in the style for that div:

@include box-shadow;
@include border-radius(10px);

Combined with the ability to define your own mixins, this is a huge time and sanity saver.

Auto-compiling stylesheets is also awesome, because it means every time you save a change, you get real-time feedback, as if you were editing the CSS directly. It also recompiles each time the server is restarted, so every time you push an update to Heroku or it spins up your instance, it throws an error while the stylesheets compile. I’m not sure how to get around this, but it’d be irrelevant if you had a dedicated box that didn’t spin up/spin down like Heroku.

Blueprint: Blueprint exists independent from Compass, but it almost seems like they were destined to be together. It includes some decent defaults for a Grid system, forms, and typography.

960gs vs. Blueprint Grid

Basically, a grid system is a way for you to define the horizontal layout of your pages so they don’t look crappy. They pick a default column count of 24, so you can cleanly split a page into 2, 3, 4, (or 6, or 8 ) columns. It’s configurable, but the default seems like something I wouldn’t be likely to change.

Brian Hogan (PragProg author of “Web Design for Developers”) recommended I choose 960gs over Blueprint’s grid due to 960’s better documentation. However, I hadn’t realized that Compass includes mixins for Blueprint’s grid system.

So I chose Blueprint grid.

To demonstrate how awesome Compass is, I’ll go back to Compass mixins:

Let’s say I want to create a simple 2-column layout with a header, footer, main area, and sidebar. This is a pretty basic request, but handling this in CSS requires a lot of careful pixel calculation and repetitive typing.

Here’s all you’d need to do it with Compass/Blueprint:

.two-col {
#container {
@include container; }
#header, #footer {
@include column(24); }
#sidebar {
@include column(8); }
#content {
@include column(16, true); }

What amazed me is that I was able to get the project completed despite the initial uphill battle of learning these tools. I’ve only scratched the surface of all the amazing things you can do with Sass, Compass, Blueprint, and their associated mixins, but I look forward to using them more in the future.

Seriously, how cool is it to be able to take something from a thought to full visual execution?

That’s not to say the road was perfect. In my next post, I’ll talk about the rest of what I learned, including my EPIC FAILS.

Ruby Mendicant University: Round 2

or: How RMU is teaching me to stop making excuses and get stuff done.

Note: I’m going to break this into several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course

If you’ve been following this blog for a while, you’ll already know that I participated in the September session of Ruby Mendicant University’s Core Skills course.

Much like the mafia, one doesn’t graduate RMU, you just get pulled in deeper. There are course offerings for alumni that range from more advanced Object-Oriented design practices, writing skills, statistics, and more. After a few months of relaxing mixed with a little bit of mentoring and casual participation, it was time for me to dig back in for the first Web Development course.

This time Jordan Byron (@jordan_byron on Twitter) ran the course, and it was his first time teaching. Anyone who has endeavored to tutor, advise, teach, or mentor knows that this is about an order of magnitude harder than you’d expect.

It was clear that Jordan cared deeply about helping us succeed, but that didn’t change the fact that everyone involved was biting off a bit more than they could chew. But for my part, Jordan’s help meant the difference between success and failure, and I learned a great deal thanks to his oversight and involvement.

For me, I’ve been learning Ruby and web development mostly by myself in my spare time for the last couple of years, and the sudden boost you get by having guided, time-bound projects is staggering. Even having been through it twice, it’s tough to imagine learning so much in less than a month.

Where I started from:

I had zero experience with CSS or true web design before this course. While RMU students must pass a Ruby-oriented challenge to get in, setting a baseline for Gregory Brown to work from, no such bar existed for the Web Development course.

This put Jordan at a bit of a disadvantage compared to the other courses offered within RMU. I showed up with no existing skills, expecting to be tutored in the most basic aspects of styling web applications.

The course:

The course itself was tough. Here were the requirements, roughly, in my words:

1. Submit an existing project for peer review, and review at least 3 classmates’ projects. Keep the discussion relatively high-level, more about frameworks, challenges, etc. rather than implementation details.

2. Take an existing project from barebones functionality to a fully styled site.

3. Create a geo-oriented project using Google Maps or similar geo API.

For me, step 2 took the lion’s share of the time. As it wound up, this list was a little *too* tough, and relatively few (or perhaps none?) completed all the requirements. The session was deemed a good pilot for future sessions, and a lot was learned on all sides.

“Uh oh, I’m gonna drown.”

There wasn’t a lot of additional instruction. There was a goal, and a list of potential resources and tools (put together by Jordan and augmented by the students). Jordan’s work is also open-sourced, so it was possible to go see how he solved similar problems if you were willing to dig into the code, though I discovered this a bit too late.

I quickly realized that I was already in over my head, and this “sink or swim” course would likely see me fail unless I drastically upped my output. For a relatively experienced web developer, this would have been 5-10 hours a week.

But like the core course, I found myself far enough behind that I required about 20-25 hours a week to catch up to where I should have been in starting the course. I’ll talk about why that may not have been such a good thing in the final post.

First assignment: Peer review

The first assignment was straightforward, simple, and fun. Our job was to post some work we’d done, ask questions about it, and comment on the work and questions of our peers.

I wound up commenting on all but two of my classmates’ projects, and hoping in vain that I’d get back around to the other two. I learned a couple of things that I was immediately able to do to improve my site, and saw some cool implementations that others came up with.

I did have to run out and research a little before I felt comfortable answering a lot of the questions. All in all, the first assignment was a bit time-consuming, but not particularly difficult.

Second assignment: Style a website from scratch

I’ll cover this at length in my next post. Basically, it took all but the first few and last couple of days.

Third assignment: Geo-aware application

I basically flubbed the final assignment, having left myself with less than 48 hours to complete it. After Jordan cleaned up my messy code, I got a basic mapping tool running using GeoKit to geocode an address, and Google Maps to display it. All in all, not my finest hour, but I’ll cover a bit of what I learned in the final post.

In Part 2, I’ll go through some of the implementation details, and what I had to learn in order to take a webapp from a barebones implementation to a fully-styled, “invite your friends” site.

I’ll also ask the flame-baiting question, “Does CSS suck?”

Grabbing a shovel

“You’re obviously talented and sharp. But I have no idea how to use you”.

About the third time I heard this from different bosses, I felt like an utter failure. Why would someone as capable as I felt be so woefully misunderstood and underutilized?

As it turns out, it was 100% my fault, and the fix isn’t all that hard.

As I outlined in another post, a coworker shared the secret of his relatively stress-free work environment (the same environment that stressed me to the point of physical illness). He was a free agent. He was only there because he wanted to be. He woke up every day and made the decision to come to work because it was what he wanted to do, not what he had to do.

But I couldn’t just be a free agent. I didn’t know where to start to develop that sense.

As it turns out, a different piece of advice he gave me later was the missing piece, the building block that earns you that free agency. I was going around in circles worrying about how I, a brand-new programmer of less than 6 months, could contribute to our large and intimidating project. He told me this: “I’m looking for people who will just grab a shovel and get to work. If you can do that, great.”

On the marketing side, I’d spent so much time trying to convince people that I had good ideas that I never bothered to just get things done. It didn’t help that the department didn’t have any clue of what we should be getting done. We just knew we needed big ideas that could recoup our ever-expanding millions in losses.

But in my interactions with the development team, they weren’t interested in ideas. They were interested in execution.

This flipped my whole world upside down. Actually, it had been upside down my whole life, and this flipped it right side up. I realized that I could simply “grab a shovel” and start helping the customers by adding small improvements to the code. I would just dig in and add copy changes in one place, fix small things in another, or add features.

I had needed decent e-mail support as a member of the Marketing team for years. So I set about adding it in myself, and had it done in a matter of a couple of weeks. I asked our lead developer, “This was so easy. Why didn’t we have this sooner?”

His reply was a bit coy: “Because we didn’t have you to build it.”

That was the most liberating feeling in the world, because I was proving value to myself and to anyone who cared to pay attention.

The same fear that kept me from achieving at work now holds me back from contributing to open-source projects: I spend so much time being intimidated or hoping someone will tell me what to do that I would rather wait than start trying to contribute any way I can. I still let this happen too often, but from here, I plan to just dig in, find something to fix, and get it done.

In my new day job, I come in every day and try to grab a shovel and get to work. No one has expressed a lack of knowledge of what to “use me for”. Rather, they know that I am going to be digging, so now the only concern is to make sure that I’m doing so in the right place.

The process isn’t complex: I keep a list of the things I want to get done. I check in with my coworkers and tell them what I want to do for the day. At the end of every day, I know how I feel about what I accomplished. There’s no technique, I just know whether I feel good or bad about a day’s efforts, and so I strive to push a little harder so I can feel good at the end of every day.

I also keep my eyes peeled for places I can get things done and just go for it. I spent so much of my life waiting for permission that it’s a bit jarring to just start doing. But here’s what I learned: if you require permission for everything, I can guarantee you’re going to waste your talents and your life waiting.

So now, I try to take a risk, go out on a limb, and do something good without permission once in a while. It gets my heart racing to know there could be some negative reaction, but it seems like those are the times where I get real traction on the most important things.

If I’m hiring someone, I’d rather pick up someone holding a shovel than someone with a sign that says “I have some great ideas about digging if someone will just give me a chance.”

Stop talking about it. Grab a shovel and get to work. I promise you’ll be happier.

The 5 life-changing lessons I learned from RMU

It’s been nearly 2 weeks since I completed my Ruby Mendicant University course and joined the growing ranks of RMU alumni. I’d hoped to put together my thoughts earlier, but the exhaustion has just worn off.

Being on the extreme “novice” end of accepted students, the experience of RMU was more trying (and tiring) than perhaps some others. But experience or no, it’s pretty intense. On the other side of the crucible, I find myself with several lessons I’d managed to escape until now. I thought they’d be worth sharing.

Lesson 1: When you see opportunities, don’t forget opportunities to help.

For those who aren’t familiar, Gregory Brown is a profoundly skilled, pragmatic, and good-hearted developer who saw a big hole in the education of Ruby developers: too many reach an intermediate level and are unable to make further progress.

I must admit that the conniving marketer in me would have seen a very easy way to extract money from the wallets of these budding developers. But Greg’s instincts being more of the “change the world” variety, he saw an opportunity to experiment with the idea that open source ideas can change the face of education.

People that join RMU are taking advantage of one of the best learning opportunities available in the world of programming, and it’s completely free to participate. I hope with that opportunity comes a sense of a longing to help. You may have earned a spot in the program or alumni status, but it’s humbling to think that the community has bought your way into a first-class education.

I think Greg’s passion for contribution to a larger cause is inspiring and contagious. RMU is slated to launch over 100 open source projects in the next year, and there will be ample opportunity to contribute (financially, by volunteering, or on the projects themselves).

Lesson 2: Find an excuse to take the first bite of the apple.

I don’t know if it’s just me, but I imagine that many new programmers are intimidated by the world around them. It sometimes reminds me of what it feels like on the first day of high school. The projects are big and solve complex problems, other programmers are megageniuses, and established community members seem as if they had been assigned that status by deity. Also, some of them have moustaches.

It was a fellow student, Anita Kuno, who worked with me to crack open a relatively complex project and dissect it. At first it looked impossible, and alone, I would have given up. Anita’s advice was to find something I understood and latch on. I did, and was surprised to find a piece I could get my brain around. Then, working my way outward, I figured out the purpose of the program and got to understand its architecture.

That’s the nature of programming, I think, and RMU was the first to bring that out for me. There’s no reason to be intimidated: it may take a little extra work, but it’s not hard to find a way to get your foot in the door.

Whether facing a difficult problem with a blank sheet of paper or a complex project that seems impenetrable, the big revelation for me was “OK, so I can’t solve this. So what can I solve?” After that, it’s just a matter of time and work before the solution unfolds, and it’s profoundly gratifying.

Lesson 3: A working product comes first.

I’ve heard it pontificated, but RMU drilled this into my brain: Priority 1 is to ship. Before RMU, I had 3 or 4 half-products pushed in a mutant state with no ability for people to interact with them.

During RMU I shipped 2 functioning products. They’re proto-sites with no CSS and limited capability, but I learned an incredibly valuable lesson. You should be in a big hurry to make something that sees the light of day, solves a problem, or makes someone smile.

That’s not to say that sloppy code is OK in shipping products; that’s just douchey, especially to newbies like me. But prettifying beyond the point where someone else could read, interpret, and contribute on your project seems a lot less valuable than getting another awesome feature or product shipped in that same timeframe.

Lesson 4: Do not underestimate the power of community.

RMU is not a solo gig. The people I’ve interacted with have taught me nearly as much as Greg. I believe it’s actually engineered that way.

However, I don’t think even Greg anticipated the quality or quantity of response he’d get from community members. The people that have gathered from around the world actively participate in IRC chats, cross-project contribution, impromptu projects, and even contributing to the core of RMU itself… it’s staggering to me.

It’s also been great to see the alumni stick around to help the incoming group with questions and moral support. The community is the culture and the brand of RMU. Ultimately, this community will surpass Greg as the “owner” of RMU (and he’s no stranger to this concept after running several open source projects).

The idea and pitch for RMU was strong enough to attract a passionate group of people, but it’s the people that bind to each other and to a shared goal. These are friends from all over the globe that I plan to stay in touch with indefinitely. How cool is that?

I don’t know what I’m going to do with the rest of my life, but I hope it leverages the good that a passionate, engaged group of people can do.

Lesson 5: Don’t listen to DHH.

OK, that was a blatant poke in the eye. But DHH and Jason Fried would tell you never to launch a product without a business model, and I imagine they’d tell you never to launch a community initiative without a sustainability model.

But if Greg had waited until he had a solid “business plan” behind RMU, it may never have gotten off the ground, leaving the situation in the world exactly as it is. Or it would be drastically different, scaled down, or less ambitious in its goals.

Instead, RMU has already helped dozens of developers “level up”, and created an incredibly tight and productive global community, with tremendous upward momentum.

Sometimes you just have to take a breath and jump, and figure out how to land safely on the way down.

Greg’s fearlessness in tackling the problems that RMU confronts is inspiring. By nature, I’m a cautious cat. I measure two hundred times and cut once. I would rather not participate than risk rejection or looking stupid. I was almost too afraid to become a father. Why should I be afraid of any of that? Being afraid is not how you change the world.

So I guess that’s the real lesson 5: Not just ignoring, but obliterating fear is the only way I’m going to make a dent in my life or in the world.

Thanks to Greg, Jia, Jordan, and everyone that’s contributed to RMU so far, and I hope to pitch in when and how I can.

So yeah, RMU was valuable for me. It’s indisputably valuable for the community. Hope you’ll help keep it going.

My (hard-won) list of resources for new programmers

There’s a nebulous space in courtship, where “casual” becomes “serious”, and words like “dating” give way to heavier terms like “relationship”. Remember the first time you called someone a “girlfriend” or “boyfriend”? Remember the awkwardness of saying it? It’s like trying on a shirt that doesn’t fit right.

In that same vein, I’m a Ruby programmer. That’s the first time I’ve ever said or written that. It feels just as awkward and forced as the first time my now-wife rolled her eyes at me when I tried to label her as “my girlfriend”.

So as a sort of follow-up of my last 2 posts, I want to express utmost gratitude to the people who do the hard work of remembering the inner turmoil of the newbie and creating help, handholding, and support for the profoundly intimidating process of learning to program. Some of them have been friends and colleagues, but many have helped by publicly sharing their knowledge.

It took me 18 months to assemble this list. I hope that by collecting these resources in one place, someone out there that’s struggling like I did (and still do) will have a shorter path through the inevitable tough parts of learning to program.

As a very green Ruby developer (dabbling with C# and Python), this list is going to be pretty heavily biased. If you want to see anything added, hit me up in the comments or on Twitter and I’ll try to keep the list updated.

Zero Experience

To people with no programming experience, it looks like a black box, and the number of people that holds true for saddens me. Anyone who wants to someday run a business should understand the basic precepts of programming, just like anyone planning to drive across the country should know how the basic components of a car work together.

Learn to Program by Chris Pine: When my friend Jarom showed me this book, it was the start of a new, happier course in my life. I can say without hyperbole: everyone should read this book. You’ll know after a couple of weeks of reading and coding whether it tickles your fancy. The book is free online, but buy a copy. I’ve given two away to people who are happier because of it.

Learn Python the Hard Way: Zed Shaw (@zedshaw) is a controversial figure, because like me, he’s got a big mouth, and his intentions are often misinterpreted (sometimes, I think that’s his actual intention). But there’s no question that he’s given and given to the programming community, and really understands and cares about new programmers.

Python for Non-Programmers: It’s a bit of a cheat to post a list inside a list, but like Ruby, Python is a great language for new programmers, and this is a great place to get started.

Ruby in 20 Minutes: It’s not the best tutorial out there, but it is lovely to look at and should give you a hands-on feel of what it’s like to write code in Ruby.

Humble Little Ruby Book: Jeremy McAnally, who is a dog that wears glasses, wrote a delightful book for Ruby beginners. It’s a great supplement to Chris Pine’s book, and chock full of quirky personality.


I still count myself among the newbies, but that protective cocoon won’t hold me much longer. This is the time when you can write and read straightforward, simple code, and ask questions like “what the heck is a lambda?”

Ruby Koans: The brilliant, incomparable Jim Weirich came up with a way to train semi-new developers on the joys of Test-Driven-Development. The Koans comprise an incredibly clever, fun interactive programming puzzle. I failed to complete the last full exercise, so I need to go back and try again soon.

Ruby Inside: Peter Cooper’s blog is the definitive Ruby news source, and I’ve discovered many, many helpful tips and articles. Plus, Peter is an amazingly cool guy who wrote the book…

Beginning Ruby: From Novice to Professional: This is the book that helped me take the step beyond Ruby’s scripting capabilities. Peter Cooper’s writing style is delightful, and the book came highly recommended, with good reason.

Roadmap for Learning Rails: If nothing else, Wyatt Greene’s Techiferous blog reveals how deep the rabbit hole goes when learning Rails. Most people learn Ruby to get into Rails, and this is a good plan to get your first project built if that’s your goal.

Railscasts: Ryan Bates is the Karl Malone of the screencast world: he just delivers. There are few meaningful subjects he hasn’t yet covered. He’s no-nonsense, giving you just the short-and-sweet facts, then moving on.

Teach me to code: Charles Max Wood is an up-and-comer, with well-done screencasts (as well as podcasts and interviews) for coders of all skill levels. It’s nice to get a different viewpoint, and he tends to inject more depth and personality into the topic at hand than Railscasts.

Pragmatic Programmers: What can be said about PragProg? It’s the best independent tech publishing house on the planet. You can very, very rarely go wrong picking up any book out of their library.

Rails Dispatch: Engine Yard has spun up a great Rails blog with posts and screencasts by Rails luminaries like Yehuda Katz. It’s not always newbie-friendly, but the screencasts are worth a watch.

But who can I ask for help?

The programming world is full of people who, while busy, are happy to help new programmers. Here are a few places to find them:

Google: Google is the king of the hill, and answers about 80% of my questions. Please, don’t bug people with questions that a quick Google search would have turned up. More importantly, don’t be embarrassed to ask questions that Google doesn’t answer for you. Where do you think Google got those answers in the first place? Your question could help future newbies get out of the same jam!

Stack Overflow: Don’t get sucked into the BS “communities” that charge to answer questions. Look for solid, community-driven Q&A sites to get your programming questions answered.

User Groups: Aside from Google, joining a local User Group is the most valuable thing you can do. They’re filled with people who have struggled just like you. Even if you work with other developers, it’s extremely helpful to get outside of your own circle once a month. And someday, you’ll be able to contribute back to the group.

Hackfests: I went to a Hackfest and felt so out of place that I snuck out the back. Don’t do this! Say you’re new and ask if you can pair with someone (likely, this will just be watching them code). Better yet, bring a dinky, sad project of your own and don’t be embarrassed to ask questions about why it’s not working!

Conferences: If you fall in love with programming, be prepared to attend 3 or more conferences a year, and not corporate-driven booth-babe-fests like CES or Macworld. Conferences run by and for the community are so packed with insight, I’m still absorbing lessons from one that I went to 6 months ago.

Mailing Lists: Historically, mailing lists are a nightmarish, labyrinthine mess. But then Google came along and helped them regain sanity. For most projects, you’ll find answers (eventually) in Google Groups.

Freenode IRC: Sooner or later, every programmer has to become familiar with the “crazy old grandpa” of the Internet: IRC. It’s dated, painful to set up and use, and oozing with geek credibility. Hackers love it because it can’t be regulated, controlled, or put out of business, and it’s a key form of communication for many open-source projects. Have a question you want answered? Get to know Freenode.

Rails Mentors: RailsBridge has created a place to learn and eventually, to teach. Pick a topic and find a mentor who will help you, at no cost.

Twitter: I’ve curated what I think is the world’s best list of Twitterers. Rather than list them here, just follow everyone I do and gradually unfollow the people that annoy you. You’ll connect with some astonishingly bright, talented, and helpful people.

Ruby Mendicant University: Lastly, Gregory Brown’s RMU has been like strapping a rocket engine to my learning process. The community has been unlike anything I’ve ever seen. I cannot thank Greg enough for dedicating time to educating people through the hardest phases of learning to program. Please support this endeavor when he’s accepting donations again.

If I’ve missed anything, and I assuredly have, leave a comment below or hit me up on Twitter (I’m @tehviking).

Why it sucks to be a new programmer (and how you can fix it)


About 18 months ago, I had a life-altering conversation with someone who showed me the magic-wand-like powers of Object-Oriented-Programming, and it didn’t take very long for me to fall madly in love with writing code and making things. It was like writing, but then making the words literally dance.

Since then, it’s often been a bit of an uphill battle, requiring all my fortitude to stay on the learner’s path instead of retreating into places where I can feel competent again.

While I now feel like I’ve made it across the most difficult chasm, I think we leave a lot of people behind somewhere along the way, or intimidate them out of starting at all.

I believe this is a cultural problem that is going to start repairing itself as programming becomes more mainstream, but there are things you and I can do right now to help.

From a newbie’s perspective, here are 3 reasons why programming culture is frightening, and some ways to make the culture more welcoming:

1. No one seems to be able to remember the embarrassment of being a newcomer.

It’s not that experienced coders don’t care, it’s that most people either live and breathe code, or they have zero interest in it. I think most programmers and non-programmers assume that if someone has an interest in coding, they started in junior high, and were fully onboarded by a CS program in college.

That’s no longer true, and it shouldn’t be a surprise that many are now cross-training from backgrounds of all kinds, especially those that have a lot of contact with programmers like designers, writers, and entrepreneurs.

Sadly, it’s still somewhat rare for someone to start learning to code out of the blue. So those of us that are new are far enough between that it can be easy to feel like the dumb kid in class, and that it’s best to keep quiet lest we be found out.

When I have asked questions, I’ve often immediately regretted it, feeling like an idiot. I ask the wrong question or in the wrong way, and the experience is deeply embarrassing.

I believe if every experienced programmer dedicated one blog post a month to a “newbie question”, or one evening to seek out someone new and answer their questions, we’d have a profoundly different culture.

Most importantly, when stupid questions are asked, be patient and perhaps share that you were once where they are now. Help them undertand that there really isn’t anything to be embarrassed about, and if asking the wrong question exposes some underlying misunderstanding, take the time to correct it.

2. Newbies can’t understand a word you’re saying.

Programming, more so than almost any other profession, is almost completely opaque to outsiders, due to a high level of insider jargon, even for people who work with computers. A year and a half on, I often run across conversations that make my head spin.

Generally, programmers are looking for something interesting. And many, in looking for new tools, technologies, or boundaries to push, don’t realize how intimidating it is for new programmers to see or hear these conversations whizzing by six or seven levels above them.

I’m convinced that this fortress of jargon is one of the reasons there are few women in programming. It’s great for guys: you suffer the paddlings of stupidity for a while, and then make it into the fraternity of coders.

But this “red rover” mentality doesn’t jibe with the mental models of most women I know, and it requires a very special kind of adventurer to be willing to defy this tradition, like the girls on my high school wrestling team.

This is a tricky one, because speaking in programmer’s jargon is a huge timesaver. But every once in a while, remember that many people don’t know what you’re talking about, and take a moment to explain, include a footnote, or even link to a Wikipedia article about one of the arcane things you’re discussing.

3. The truth is out there (somewhere), but so are a lot of other things.

One of the most frustrating things as a newbie is that it takes an incredibly long time to find answers to simple questions. I wind up using a hodgepodge of various methods found via Google to solve almost every problem.

Often, I’ll get so stuck that I get profoundly discouraged, feeling as if I’ll never catch up and acquire the knowledge to be decent at this. If only there were someone to ask!

Nine times out of ten, I’ll eventually stumble on the correct answer and the victory is that much sweeter. But most of my struggles are small enough to an experienced developer that having someone to ask questions would have accelerated my learning dramatically.

Ultimately, “shut up and code” is a great (and sometimes the only) way to brute-force through problems. But for many, having someone (preferably multiple someones) around to ask can make the difference between giving up and seeing it through.

Be that someone. Be the one to welcome new programmers (and entice non-programmers) to the joys of coding. Join a local Users Group. Jump into online discussions. Put a note on your website that you’re happy to take questions, even if you can’t answer them all.

You’ll enrich the lives of others, because programming, as you know, is an incredibly rewarding creative pursuit, and having more people at the party is good for everyone.

Who knows… maybe that new developer will wander into Hollywood and help make a movie that doesn’t portray programming in a completely ridiculous fashion. And in the end, isn’t that all programmers are asking for?