I made it on my own.

The mere idea that any person could independently become successful – without help, good fortune, and a heaping measure of luck – is a delusion.

Even ignoring the fact that a large percentage of rich people are rich because of inheritance, most people require more than “hard work and know-how” to become successful. I daresay that Oprah isn’t simply the best talk show host ever in the whole wide world, but rather that she met the right people, made some good connections, and was given the right opportunities to be where she is today. And she’s hard-working and a decent talk show host to boot.

Don’t get me wrong, I understand why rich people want to believe that they got where they are all on their own. Wouldn’t it be nice to believe you could be dropped anywhere and the outcome would be the same – total domination?

I spoke to a delusional man tonight who believed...

We’re just trying out a few things, no need to write tests for them.

Have you ever heard some variation of this? It falls under the general category ship more faster but this one is particularly insidious.

As developers, we’re used to prototyping things or spiking on them to see if they’re feasible. But truly disciplined developers will never let these hastily-built creations go to production without going back and (ideally) re-building them TDD-style or at the very least back filling with tests.

This whole idea originates from a perversion of Eric Reis’ Lean Startup, in which he encourages startups to validate their hypotheses before heavily investing in them. There are 2 pieces that are often missed when PMs think they’re doing things “lean”:

1. Test your hypothesis prior to investing engineering time in it. This means don’t build it till you’ve (lightly) marketed it and...

companion post to “success is hard”

Allow me to regale you with a story from my own sordid past.

I was just a wee lad, and had barely gotten my Rails feet under me (though I’d already submitted a patch to Rails itself). I was ready to move on from InsiderPages, where I learned a great deal but felt I had outgrown. A recruiter sent me on my first interview somewhere surprisingly far away from SOMA.

I arrived deep in the Mission at an office, let’s call it TinyCorp. The interview process was really bad. They were unprepared, asked me questions that had nothing to do with Rails or web development, and didn’t even offer me water. They asked a computer science question that even they couldn’t answer (don’t worry, I explained it to them). When they finished interviewing me a couple hours later, they wanted to send me home with “homework.”

Worst of all, they hadn’t even told me what their...

Be sure you’re working on something that, were it to fail, you could still be proud of the work you did

It sounds obvious. It’s so obvious that you’re probably going to stop reading in a few more paragraphs, so I’ll keep this short.

Before you embark on your next uphill startup climb, take a moment and ponder the following:

Failure is most likely.

Not to be Debbie Downer, but for every (even mildly) successful startup, there are probably a hundred failed ones. So think for a moment before you start: Will I still be proud of what I did—what I tried to do—if this doesn’t make me the next gazillionaire?

If the answer isn’t a resounding YES, you should probably wait for the next “once in a lifetime opportunity” that seems to be flooding your LinkedIn Inbox.

If you’re having a hard time answering that question, it’s probably a sign that this isn’t the right opportunity for you, but...

Why you should care

Developers tend to be an opinionated bunch. After all, it’s far easier to recognize bad code than it is to write good code. I imagine this isn’t unique to writing code, but rather a shared experience in most professions. Writers will read this post and think what a fucking idiot. He didn’t even use quotes right. Or OMG what a worn out trope. Artists see sketches and criticize the shading. Designers see logos and mock the typeface.

Anyway what I’m getting at is that it’s fairly common to criticize the very codebase you’re working on. Criticism ranges from thoughtful, constructive criticism to immature whining. The scope of criticism can be a couple of lines, a class, one entire layer of the app or the whole damn codebase. I’ve worked in more than one company where developers were calling for a complete rewrite.

If you’re in any sort of leadership position, you...