Here’s an exercise you can put into place right now which will have a lasting, significant, positive effect on your life and the lives of those you work, live, collaborate, and play with. There are two versions: an easy version and a harder version. Start with the easy version unless you’re the kind of person who has to do things the hard way.

The easy version

Whenever you have a cynical thought, keep it to yourself. Never utter, write, or otherwise convey it. Put it away. Think it to yourself all day if you have to, but never express it.

The harder version

Whenever you have a cynical thought, keep it to yourself. Analyze it. Scrutinize it. Prove it to be wrong. Discover the personal fear within you from which it grew, and make a plan to address that fear fully. Be thankful to the negative emotion for giving you the opportunity to understand your own weaknesses.

Cynicism is born of laziness and fear: It’s easy to complain about something. It’s harder to fix it. It’s both scary and liberating to trust other people to try to be their best.

Update

As @dhh pointed out on Twitter after I posted this, I worded this more absolutely than intended. I meant this to be an “exercise” (see the first sentence). Skepticism is healthy. Sometimes, cynicism is the right reaction. But, I believe most of us could use a lot less of it.

There’s a person I want to work with. I can’t find this person. I’ve literally searched the world, and I can hardly find a trace.

I’m not talking about someone specific. In fact, that’s the problem. I’m talking about a set of traits and an attitude which is more scarce than I realized until recently. I know a small handful of people who fit what I’m looking for, but they’re busy and unavailable right now.

I was talking to one of these people recently about my desire to, as I put it, “hire someone like you”, and we both realized how hard it is to name really anyone else who fits the description. Given this and the fact that there are so many bad job descriptions for developers in the world, I’m writing down what I’m looking for in hopes that this person (you?) is out there:

• Everyone knows that when you take on a task whether it’s huge and scary or tiny and boring, you’re going to see it through to the best of your ability.
• It’s obvious to everyone around you that you have fun with your work and with your co-workers.
• You care about how your work and attitude affects those around you. I mean really care. If you hurt someone, it hurts you. Everything you do runs through this filter.
• You understand that communication is the biggest responsibility of your job as a developer and the one you’re least likely to get right unless you focus on it.
• You focus on shipping software that matters to your users and that matters to the company you’re building it for.
• You’ve experimented with and survived many different types of development and project methodologies, which has left you with a healthy appreciation for what works from the so-called “agile” methodologies and those that came before (and after) them.
• You have no time for ceremony. Maybe you even hate it, but “hate” is too dogmatic a term.
• You are humble enough to bend to the will of the frameworks, technologies, constraints, and people you work with when doing so won’t have a materially negative impact. In other words, you can play by someone else’s rules when that’s the easiest and/or best thing to do.
• You make pragmatic (often boring) technology choices at work and you play in your free time. You don’t build science projects just because you are smart enough to build them.
• You are confident enough that you don’t have to prove to anyone what a great developer you are, and therefore…
• You don’t mind being the one that looks bad when you deserve it. You make mistakes sometimes, because you’re human, but rather than dwell on them you choose to fix and then learn from them.
• You love to teach and learn from your co-workers.
• You are confident with a number of programming languages, operating systems, and architectures. You probably have one of each you prefer right now, but you’re neither dogmatic nor myopic in your focus on it.

From my perspective, these are the things that matter.

I don’t care if you’re the smartest person I’ve ever met. I don’t care if you know everything about the technologies I’m deploying. I don’t want a “rock star”. I definitely don’t want a ninja. I don’t care if you write books, contribute to Open Source software, or speak at conferences. I do those things, and I know how little they predict how well I do my job.

If this describes you, I definitely want to know you. If you are interested in building scalable APIs and automated infrastructures for those APIs and would like to work with me in Berlin making beautiful productivity software, I definitely want to know you. Please get in touch.

I keep learning this lesson over and over again, so I’m writing it here in an effort to never forget again. As a manager, if some task constantly stresses me out or makes me feel uneasy, it’s probably because I’m doing someone else’s job.

I don’t mean someone’s being lazy and I’m picking up their slack. I’m talking about those nagging little annoying things you find yourself doing as infrequently as you can and do a half-assed job at every time. So you not only stress because they’re in the way of your real work but you stress because you suck at them.

Every time I allow myself to notice this feeling–every time I analyze what’s causing it, it’s because I should be delegating this work to someone else. Usually, in a mature organization, it’s even obvious who the work should go to.

The beautiful thing about being a manager of people is that your core job includes uncluttering your and everyone else’s work days by putting the work, moving tasks to a home where they can be lovingly completed.

As I mentioned recently, we’ve moved to Berlin!. We got to spend a week of down time exploring the city. We are definitely in love with Berlin so far!

I’m excited today to finally announce that I’ve joined 6Wunderkinder as CTO. In case you don’t know them by the company name, 6Wunderkinder are the creators of the extremely popular Wunderlist, which is a cross-platform, simple, and beautiful productivity application. I’m a user, and as I’ve told friends and family about my move, I’ve discovered that many of you are too.

As I’ve said previously,, I’ll miss my LivingSocial team and look forward to watching them from here in Berlin, but I’m extremely excited to get back to hands-on software development with the small, focused, team of brilliant product engineers here at 6Wunderkinder.

For those in the Berlin tech scene, if you happen to see me around at Sankt Oberholz, please do stop by and say hi :)

Thanks to Lynn Wallenstein, I have a new web site design. If you see problems with the layout, it’s almost definitely because I screwed something up after Lynn gave me the code. Sorry, Lynn. :(

I have also used this as a chance to move from my own server (which I’ve been screwing with for over a decade) to Octopress hosted on Github Pages. I’m glad to be done with that phase of my life.

Anyway, with Octopress I feel like I’m stepping back to the simple, productive environment I had ten years ago with Rublog.

It’s hard to believe it’s been almost two years since InfoEther was acquired by LivingSocial. Since then, we’ve built the strongest development team I’ve ever known. We’ve set records for e-commerce transaction volume. We’ve grown at an incredible pace, both as a business and as technology team. We’ve shipped a lot of software, and made millions of people’s lives more interesting in the process.  I’ve had the privilege to work with some of the most admired engineers in on industry. I’m proud of the team Aaron Batalion (from whom I’ve learned a ton about running a consumer internet product) had assembled before InfoEther arrived and of the team that ultimately grew from that foundation.

As I mentioned when I announced our Hungry Academy program, for me personally the experience at LivingSocial has been intense. As I said in that post, “These last 8 months at LivingSocial have been the best 4 years of my career.” That holds true today.

Playing the role of Senior Vice President of Technology and serving on the senior executive team at LivingSocial has been a rewarding learning experience.  I’m humbled by the talent and experience of every member of that team, and since my first day have been awed by Tim O’Shaughnessy’s business sense and natural leadership ability.  I look back on my career, and a handful of teachers and mentors stand out that have had a significant impact on me. Tim is now in that very short list.

All the while, though, I’ve known that I would eventually go back to a more hands-on role, personally building products and solving technical problems. I am, after all, a Passionate Programmer.

Kelly and I have also had  a goal to (before we get too old to fully enjoy it) live overseas again.  Our time in India, was a huge influence on both of us, both personally and professionally, and we’ve long since hoped to gain a similar experience in a different part of the world, specifically Europe.

So that’s what we’re going to do.  I’m taking a role as CTO of a technology startup in one of our favorite cities: Berlin.  I’ll be working hands-on to develop cross-platform software with a small, talented team of engineers, designers, and product managers. I’ll be transitioning from my role at LivingSocial for the remainder of January and will be relocated to Berlin and starting the new job in mid February.

As excited as I am to move to the next adventure, it’s always sad leaving a great company like LivingSocial.  I’ve made some friendships that will last forever, and I’ll miss the team immensely. I know, however, that they’re in good hands and that 2013 is going to be a fantastic year for the business. 

Early last year, I posted about how we’ve unfortunately turned the word “legacy” into a bad word in the software industry.

At Nordic Ruby and again at Aloha Ruby Conf this year I turned this idea into an exploratory presentation. I think it turned out pretty well and is an important topic. Watch it and let me know what you think!

When you create art, the purpose is self-expression.

When you create software, the purpose is rarely self-expression.

When you create software, someone somewhere wants it to perform a set of functions and has a stake in how well those functions are implemented. The definition of “well” is up to the stakeholder.

When you create art, you want it to be beautiful, or beautifully ugly, or ornate, or plain. You, the creator, are the stakeholder. You may hope that others find it beautiful, but if they don’t, it’s art—who’s to say what’s good and bad?

When you attempt to judge the quality of a commodity good solely in terms of its aesthetic appeal, you ignore the objective evaluation of how well that product meets the needs of its stakeholders.

When you attempt to judge the quality of a piece of art solely on some objective measure, you miss the point of the object as an expression of art.

Craft falls somewhere between commodity and art. Craft items have both subjective, aesthetic appeal and objective function.

This is a beautiful Christian Dior dress:

Beautiful but largely impractical. Try to wear this on the subway or even in your car. Try to fit it through a standard door. It’s a beautiful piece of art, but it fails as a useful article of clothing for most people.

This is a Paul Smith suit. It’s practical, extremely well made, creatively designed, and probably very expensive:

This is a pair of pants on sale at Wal-Mart:

Beautiful? I don’t know many people who would call this beautiful. Completely unremarkable.

And so it goes…from art to craft to commodity.

Now consider yourself as the customer here. My guess is that most of my readers, even with an appreciation of the quality of the Paul Smith suit, would be much more comfortable in the Wal-Mart pants.

When we create an item for another person, we have to consider whether that person is looking for art, craft, or commodity. We may wish to always be creating art. Or craft. But sometimes our customers want commodity. Not only is commodity cheaper but it’s what they prefer.

Where have I been lately? Good question. When asked over these past months, I jokingly say something like, “These last 8 months at LivingSocial have been the best 4 years of my career.”

But I don’t just mean I’ve been busy. I’ve been focused on building the best software development team I can to do what I think is some important and industry-changing work in the world of local commerce.

And when I joke about these 8 months being the best 4 years of my career, what I really mean is that I feel like I’ve learned 4 years worth of lessons and gained 4 years worth of experience. What we’re doing isn’t easy. It’s the kind of work I’ve always sought out.

I am a self-taught software developer. To date, my formal education consists of two 3-day training classes on specific programming languages (Java many years ago and Erlang in 2008). During my first work experiences in IT, I remember the shock of discovering that a Masters degree in software development doesn’t necessarily translate to knowing how to effectively use a computer. I was a saxophonist and system administrator and would regularly teach the computer scientists I worked with about things I would have assumed they learned in college.

As I headed further into the workforce I noticed another odd thing: people with tens of years of experience as software developers weren’t necessarily very good at it. My assumptions were based on what I had previously learned as a jazz musician. Jazz musicians polish and hone their skills throughout their careers. The longer a jazz musician has been playing, the more likely he or she is to be an excellent jazz musician.

Programmers, though. As far as I could tell the average programmer spent his day complaining about his co-workers and waiting for 5pm.

So what’s the disconnect? Some of it, of course, is just the people. Some programmers are passionate and some aren’t. Those that aren’t, aren’t going to be radically successful. Assuming this is the case in all fields, what’s really frustrating to me is that I continue to run into passionate developers who just don’t know the right stuff.

When I started out in this field, I was lucky enough to stumble onto a mentor. That too was probably informed by my experience as an aspiring jazz musician. Jazz musicians take the idea of musical lineage seriously and look for someone from whom to receive direction on how to parse the potentially overwhelming task of going from novice to master jazz improviser. My mentor in the software field did the same. He told me: first learn these three things. He picked topics that were diverse but complementary. He picked skills that set a foundation on which it was easy to build the next set. Most new developers don’t get so lucky.

And It’s not just technology skills. The developers I work with are entrepreneurs at heart. We aren’t sitting around polishing our tools and conducting thought experiments. We’re delivering stuff that matters and we hate working on projects that drag on or don’t deliver value. Becoming a great developer involves not just learning the ins and outs of software development but understanding how businesses work and exactly how software systems fit into that picture. It’s about delivering value quickly and iteratively. Great developers understand what Kent Beck and the rest of the authors of the agile manifesto were getting at a decade ago. And what people like Eric Ries are teaching today.

I’ve often thought “just give me 3 months with a smart person and I can have them running circles around the average developer.” Have you thought that too? I know a lot of my colleagues have.

It’s time to rethink how we educate software developers. Computers used to be huge scary machines in big white rooms that very few people touched. Today you probably have at least one computer ON YOUR BODY most of the time. They’re ubiquitous and friendly and just NOT that hard to work with. The technology landscape has changed. The system of educating developers should change along with it.

My colleagues are clearly thinking along the same lines. I’ve seen speakers such as Joe O’Brien talking about it this year. And we see programs popping up all over. Software Craftsman Ken Auer is launching the Craftsmanship Academy to teach apprentices the art and craft of software development in an intense hands-on residency-oriented program. Code Academy is a part-time 12 week course to accelerate the path to web development or design.

Today we’re launching a new program at LivingSocial called Hungry Academy. Hungry Academy is a five month intense entrepreneurial immersion that will take raw, hungry talented programmers (and aspiring programmers!) and develop them into ultra-productive software engineers. Those that make it through to the end will be offered a position on our development team and paired with a mentor from LivingSocial’s growing list of some of the industry’s most talented software engineers. Best of all, we will pay you to attend. Your job for five months is to take your craft and career to the next level.

This isn’t going to be easy. Some people will get in but won’t make it to the end. Those that do will spend five months gaining the best 4 years of experience of their careers.

Ever since reading David Heinemeir Hansson’s post Enterprise Is the New Legacy over five years ago, I’ve been chewing on something. The gist of the post was that “enterprise” is and should be a bad word, just like “legacy”.

But why is “legacy” a bad word to begin with? The word makes most software developers and IT people ill.

In other fields and in life in general, the word “legacy” isn’t thusly encumbered. It refers to an inheritance left to those behind you. Your life’s work. Your essential story.

In software, that story is assumed to be a tragedy.

But even in the case of software, “legacy” is an indication of success. Sure, old software was written with old technology. And most software (or indeed most things created by humans) has its share of warts and dark corners. But the fact that we refer to a piece of software as “legacy” indicates that it was successful enough to have been deployed and to have been used for enough good that it is now something we’re “left with” and that we must either maintain or replace.

That isn’t so bad, is it? In an industry where more software projects fail or are ‘challenged’ than succeed, getting to legacy status is cause for celebration!

Here’s a sad idea: as developers, even when we do succeed, we tend to create things that are abandoned at great cost only a few years after we pour our hearts and souls into them. As rough as your last project might have been and as hard as the deadlines were, chances are your project will be disparaged and terminated within 10 years of its birth.

So, what do we developers leave as a legacy? In most cases, we don’t leave much of anything.

At a previous job, a mission-critical core system ran on an ancient, customized mainframe with a custom TCP/IP stack and a custom relational database system. At the time, the system was over 25 years old. It performed well. It survived Y2K. It was well understood. It reliably ran our (big) business.

That was ten years ago. I’d be willing to bet it’s still running. If not the whole system, at least a subset.

That would make it 35.

Sure, it had its ugly parts. And most of us were terrified of it. But, hey! Still running and doing its business after 35 years. I hope I ever create something that successful.

How would I create something that had that kind of longevity? How different would my designs be if I believed I was creating software to last 40 years?

It’s daunting, isn’t it? My knee-jerk reaction might be to do a Big Design Up Front. But how could I possibly design an entire system with 40 years of future knowledge in mind? I couldn’t. Even predicting next year is hard.

So maybe I’d need to design something that was ultimately flexible. A framework of frameworks where everything is pluggable.

Any software developer who lived through parts of the 90s knows these systems buckle under their own weight.

I don’t know how to design a system that could live a long and healthy life. I don’t know because I haven’t done it yet. Have you?

Note: This wasn’t a rhetorical question.