Friday was my last day at LivingSocial. I’m moving on to a small team at a small startup that I hope will eventually be big. My tenure at LivingSocial was short - it would’ve certainly been longer had this opportunity not come along - but I learned a lot in the 14 months I worked there.

Sure, I learned stuff about Rails, Ruby, service-oriented architectures, asynchronous processing, and credit card payments. But that’s not what I’m talking about. Those skills are great experience and will look just fine on my resume, but I learned two things that made me a better developer:

• Deliver results, not promises
• Assume everyone knows what they’re doing

Deliver Results, not promises

At a previous job, we had a well-tuned agile process. We worked in sprints, with a backlog, stories, and regular releases. After a while, however, it felt like the team was just producing story points. Products in development were allowed to be “in progress” for weeks or months. It got to the point where progress itself was a deliverable.

The problem is that promises, plans, and progress reports aren’t valuable in and of themselves. Promises don’t solve business problems. Customers don’t purchase progress reports, and developers can’t ship code based on un-executed plans. For whatever reason, LivingSocial gets this, and gets it deeply. When Mark Zuckerburg told Facebook’s shareholders that “code wins arguments”, I believe this is what he meant.

This cultural value leads to what I believe is the true essence of the “agile” movement. Consider for a moment if all you are as a developer is what you’ve shipped¹. This is going to fundamentally change how you work. {“ You’re going to ship smaller features and you’re going to ship them more quickly. “} You’re going to deliver value to the business as quickly and frequently as possible.

Because of this, big projects - which is a project that might take more than a couple months - are unusual at LivingSocial and cause a fair amount of trepidation. In general, I believe this is a good thing. Big projects have a way of not shipping. Big projects have a way of getting bigger and more expensive.

I’m not saying that big projects are bad or that LivingSocial is incapable of taking on big projects, but we always ask ourselves if there’s a way to do a lot less a lot more quickly, and if we can start showing results sooner. This has not been a common attitude in anywhere else I’ve worked.

If your organization is truly “results-oriented”, then it means that promises, planning, and status reports are treated as fundamentally different things than shipped product. This isn’t to say that planning and progress are bad - LivingSocial certainly uses a wide variety of project management tools and techniques - but they are only valuable to the extent that they enable the delivery of results.

This attitude quickly affected everything I did, even down to the way I’d write email. I stopped immediately responding with “I’ll look into it”, or “I’m not sure”, or “That should be correct”. I started to respect the inboxes of others and responded only when I had a real result (or the name of the person who could get such a result if I could not). I stopped delivering promises and started delivering results.

Which brings us to the second thing I learned.

Assume everyone knows what they’re doing

Programmers have well-earned reputations as prima-donnas. While certainly not every programmer develops this arrogance and lack of respect for those who “can’t code”, it’s unfortunately common.

As a young developer, I was rude and disrespectful to anyone who didn’t code. I was allowed to get away with it because I did my job² well and my skills were in high demand. In my eyes, everyone was guilty until proven innocent. I even began to apply this to other developers after seeing what government contractors are allowed to get away with.

During my job prior to LivingSocial, I matured a lot in this area. I was fortunate to work with a great team of developers and with a largely effective, helpful, and talented team of sales and product people. As the company grew, however, my old attitude crept back - there were just too many people to know intimately, and I started to treat everyone new as incompetent until proven otherwise.

When I started at LivingSocial, this attitude persisted. The company is huge and, as one of only two developers working on a key piece of infrastructure, I had to interact with a wide variety of people. I knew enough to be nice and to be polite, but this was initially a mask of my lingering bad attitude.

After a while, I started to notice that the stereotypical programmer attitude was not nearly as strong at LivingSocial as anywhere else I had worked. The relationships between the developers and every other part of the company - customer service, IT, product, accounting - were far healthier than I’d ever experienced.

The result was a high functioning team that made decisions rationally, not politically. Developers were not rude nor disrespectful to their “non-techie” counterparts, and, surprise surprise, were treated with respect themselves. I don’t know how this evolved, but it seemed that everyone’s default assumption was that every member of the team was skilled, useful, and dependable - innocent until proven guilty.

As I realized this, and began to adjust my attitude, it became easier and easier to work with other people. Where in the past I would’ve dreaded having a meeting with the “idiot business guy”, I now went into these situations with an open mind, and a positive attitude - what business problem can I help solve? Turns out that people who don’t code are pretty smart and know stuff I don’t. The end result was that, in any discussion, the best idea would almost always win (and it wasn’t necessarily the developer’s :)

I have no idea how to cultivate or maintain this cultural value, but when a team of developers starts with the assumption that everyone’s working toward the same goal, and that everyone knows what they’re doing, the team functions well (and it’s a lot more pleasant to work on such a team).

Bonus third thing

In July, I wrote about the Hungry Academy graduates, who were all starting their new lives as LivingSocial developers:

The first half of this grand experiment is over and it was a rousing success. The second half - how well they succeed in the actual work environment - begins now. I’m optimistic.

It’s been about six months since I posted that and, in that time, I’ve had the pleasure of working with many of the graduates. I don’t know the ultimate cost of turning these 24 men and women into developers, but they are the most consistently skilled group of junior developers I’ve worked with. Hiring someone with little or no experience is always a crapshoot, and you hope that even 50% of your new hires will be this good. LivingSocial was able to produce twenty four of them in five months.

And they aren’t just code monkeys. Yes, they can make the computer do things, but their attitudes are amazing. They don’t seem saddled with any of the baggage that myself and my peers seemed to have at that point in our careers. It gives me hope that the “prima-donna developer” can someday be a thing of the past. Getting to experience their growth as developers is something I won’t soon forget, and likely something that very few professional programmers will get to experience.

Moving on

So that’s it. I’m moving on to work with some ex co-workers on a small team (more on that later), building a small, successful business into a larger, more successful one. My paycheck is going to depend on delivering results, and my ability to deliver those results is going to depend on good working relationships with all sorts of people working to make this business succeed. I honestly don’t know if this would be possible without my 14+ months at LivingSocial.

If you enjoyed this post or want to find out more about being result-oriented, I’ve written an entire book on the subject called “The Senior Software Engineer”. Pick up a copy - it’s only $25!