Code Soloist #6: Do the thing

Ralph Waldo Emerson said “Do the thing, and you will have the power.”

What I believe he meant was that experience is the only true filter, for both consuming and producing value. When you actually know how to do something, which you’ve earned by throwing yourself at a problem and living with all its trade-offs, disappointments, and victories, you see similar aspiration and effort in the world with a calm, critical eye.

Once you know how, you can stop reading most technical blogs. A lot of the time, what you’re reading is process: someone is learning out loud. If the proposed solution is clever, interesting, or even “productive” in the sense that it makes something perceivably easier, it may actually provide zero net value to you. Value, in this case, is something that drives your project forward in a tangible way. If it doesn’t affect the person that’s actually going to use your creation, it’s worthless, for the time being. If you don’t have the experience, you’ll spend a lot of time implementing other people’s idea’s that have likely never paid for the time they took.

Once you know how, you won’t need to look over the fence, or over your shoulder, at other people building products with different tools. Sometimes toolchasers stick together and create movements. None of these collectives help build your application faster; before you launch, you don’t have problems specific tools can solve. Your only problem is: what’s in your head doesn’t exist yet. And it must exist.

Once you know how, you know if you love what you’re doing. You don’t love the idea of the end result, or the thrill of imagining some future process where you’re free from daily pressures. You know it’s the hardest thing you’ve ever done. Your experience reaffirms that this is your calling. Nobody else would have survived this long.

The only way to be proud of what you’ve done is to really do it. And the only way to finish is to take pride in every day you bring yourself to the problem.

Code Soloist is for single-person web development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.

Code Soloist #5: Play your game

As a single developer you need to avoid several problems that larger teams (that’s everyone else) face in order to maximize your chance of success. Narrowing your vision on an achievable business as a soloist, rather than the one you’re thinking of, will feel like someone put a brick on your brake pedal.

You know this tired line from the big blogs and books, and you’ve probably reiterated it yourself at meetups: “scaling is a problem you want to have”.

No you don’t. You’re one talented person with two hands. Scaling will crush you in an afternoon. So will too many customers, even with adequate architecture. So will hunting for funding instead of hitting the command line. So will just about anything that takes more of your attention than you have to spare.

While you’re thinking about that, it’s probably a good idea to put those big picture books in a box. I’ll never knock someone for enjoying the motivation and thrill of a great business book, they’re like candy. But unless you plan on finding a co-founder, or a small team to collaborate with—worthy goals in their own right but out of scope for this blog—they aren’t telling you too many things you can act on. They’re playing a different game.

I suggest this is your game: one thousand customers, thirty dollars a month.

With a thousand customers, chances are if you offload any CPU intensive tasks and storage to commodity services you can run your application on one server. Sure, you can spend a little extra time making sure you’re building software that is aware of the possibility of scaling services horizontally and data vertically, but you won’t have to sweat it unless and until you’re ready.

With a thousand customers, you have your work cut out for you to find these folks and convince them that you’re offering a service they need for the long haul, but it’s not an insurmountable task. With low operating costs you can take more than a year to find all of them and still make a living on your own terms. What more could you ask for at this stage?

I’d even suggest limiting your signups and total capacity to those thousand customers, should you achieve what is already a difficult goal. It’s easy to put up an apology page and ask for emails to join a queue for the next chance at being served by your application. It might even attract the exclusivity that helps you justify enlisting help and bumping up to the next bracket.

The code soloist can earn more than enough doing what they love while delighting a thousand people. You might have a different picture of what enough means to you, but certainly starting from the success of a smaller project that you can handle is a great way to build momentum for a larger effort with all of its greater rewards and risks.

Code Soloist is for single-person web development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.

Code Soloist #4: Don’t extract

You’ll likely read lots of inspiring literature on business and technology to keep you motivated and learn from the best. In Rework, Jason and David point you down the path of seeking the “extraction”, explaining that you can’t just make one thing, and often the extractions you find along the way—a book of wisdom here, an open source web framework there—can lead to profit.

This is the purest form of product development because it already exists in your own application and it’s battle-tested. Since we thrive both intellectually and emotionally, perhaps to our detriment, on solving puzzles that also solve our own problems, it’s easy to see that something you create while building your business could be useful to others and earn a profit.

The problem with focusing on extractions as a soloist is that you’ve got limited bandwidth to explore these extractions and each requires its own commitment to marketing and polish, often the most difficult part of the product development process. This kind of energy always requires your full attention, which means an extraction takes away from your overall goal, even if you believe there’s a benefit in the long term.

You could abandon your business and make the extraction your business, but chances are doing so will not only establish in yourself a precedent that it’s okay to switch from one project to the next, but the quality of the extraction will suffer when its genesis changes from solving a real problem to being the problem.

You’ll probably invent three solutions along the way that could stand on their own. Release them after your product is finished. This will keep you on track, and will even lend credibility to your future extractions since you can market them with concrete examples.

Code Soloist is for single-person web development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.

Code Soloist #3: Stop guessing

You don’t know when you’re going to be done your next project.

If I had to pick a single drawback of being a code soloist, it’s this one. You may believe initially that you have a good feel for how long these things take, but you’ll only realize much later, when your artificial deadlines slip, that you really only have feelings, not a feel.

Your feeling is that any arbitrary, non-trivial amount of time is “enough”. For example, three months. That sounds like enough time to do just about anything if you’re armed with a decent development environment and have a good handle on what you’re trying to build. But “enough” is far from an educated guess.

You’ll be better off if you free yourself from the idea that what you’re up to needs a deadline at all. If three months was all it took to build what I’m working on these days, there would be four more competitors today. Instead, the landscape hasn’t changed, because web development is hard.

No matter what the scope of your solo project, however long it takes you, is how long it will take someone else. You can’t change reality by bending it to fit how short a window you think you should be able to work. Just work, keep working, and ship as soon as you (really) can.

Code Soloist is for single-person web development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.

Code Soloist #2: Your lover has to love it

The short version: If your significant other doesn’t love your idea, you should find another one (a note to the hardcore: I’m talking about the idea).

I’m also not talking about that pre-adulthood kind of love for everything you do, but a genuine interest in what you’re proposing to offer the world. Even better would be that your other has a genuine use for the product or service when it’s completed.

Here’s why: essentially until the project is finished, this thing is taking deposits directly out of the relationship bank (unless you’re able to hit your stride in the hour or two a day that are stuffed between the cracks at dusk and dawn, in which case, I applaud you) even before any currency is spent. There’s the obvious time you’re not spending together, and the missing mad money, but then there’s the countless handfuls of inattentiveness, or the extra pile or two of laundry, that accumulate as you get consumed in the details.

Selling your idea to your other is great practice for sharpening your vision, but more importantly, a successful sale increases the chances that it will have an impact in the non-technical universe (read: most of it). This lends some much needed enthusiasm for something that will strain your relationship if it isn’t carefully managed.

Code Soloist is for single-person web development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.

Code Soloist #1: Don’t work at night

Your web business is a huge part of your life and you’ve undoubtedly set up a self-imposed deadline to get it out there. You did this because nobody else will do it for you, and you thrive under pressure. As you get into your stride and start pushing it out, you might catch yourself temporarily looking up to see the big picture. The big picture always looks impossible to achieve from where you’re sitting, so you do the math and get to thinking that more hours in is more value out, and start adding nights to your days.

It rarely works that way, definitely not often enough to make it a habit. The output you get from shorter concentrated bursts of focus when you’re fresh is far better than the sputtering phases of near-lucidity in the typical all-nighter. You might even spend a day trying to understand, or repair, what you did when your brain was mainlined with a caffeine and cortisol cocktail the night before.

Code Soloist is for single-person web development companies that are trying to start something big with their bare hands. In it, I try to impart whatever I’ve learned, for better or worse, doing the same thing badly.

A pattern of performance

I’ve noticed something I’m going to take the time to fully explore in the next while. Here it is: an “affected” developer starts at a big corporation, breaks off as a freelancer, and then finds a smaller group of like-minded individuals, great contributions and commercial success follows after.

To those still in the first intake, being a lone wolf seems like the best possible situation, but invariably, as I’ve experienced, a yearning to relate and to belong to a group takes over after awhile. You may even feel a sudden burst of nostalgia for your old environment and team, despite all of the many reasons you left that corporate culture being completely unchanged. That is a regression. Ignore it.

That there are others just like you is encouraging because it means you have a chance to find other non-conformist developers and band together to get the benefits of both worlds: sovereignty, and the whole-is-great-than-its-parts phenomenon. While most freelancers can build entire businesses from the ground up with their bare hands, finding others means they don’t have to.

I have a gut feeling that there’s scads of hard data to back up the success of this pattern, and that there’s a way to define, reproduce, and distribute it to others who are looking for more success / time / joy / etc. whether they’re freelancers or employees.

I don’t think the “boutique consulting firm” is much of a departure from square one, though, so I wonder if there’s a better way to ensure a standard of living for the whole team that still provides plenty of time to change the world.

Developers and Sartre

Sartre said “hell is other people”. He didn’t say it to cast himself as the depressed, hapless thinker, he was observing the threatening process every person experiences when they encounter another person. The gist of it, is that while you are able to experience yourself as an autonomous individual, to be absorbed in the self and forgetting the body, you are forced by the laws of nature to experience others as objects, external to you, and ultimately, a threat to you and your desire to self-actualize or acquire finite material worth. In addition, seeing others, in their bodies, is a painful reminder to the self that it is also a body, and subject to death. 

Using Sartre’s observation like an equation, it seems to me that the more a person has the capacity to become absorbed in the self, the less they enjoy others, because the transition from pure thought to an inconvenient truth (that you are a meatbag) is more jarring. Perhaps this is why developers who are generally more interested or passionate in their work than others are seen as having fewer social skills.

Discipline

“Do what you know you should.”

The hardest part of discipline sounds like the easiest.

If you did what you knew you should, you’d be ten years younger metabolically, you could count all eight of your abdominal muscles by sight, and you’d be much further along most of your personal endeavours.

Things get interesting when we attempt to live in to the self that knows what should be done. The realities of following this principle bring you directly into the den of your psyche, where hunger, fatigue, comfort, emotions, and every incongruent patchwork personality you’ve ever sewn for yourself will have your willpower for breakfast.

You’ll know when you’re practicing true discipline because it won’t get easier the second time around. Whether it’s sufficient reward or repetition that causes the switch, if it’s easy, it’s a habit, not discipline. You’ll be fortunate if you can automate a handful of your “shoulds”, but strictly speaking they are “shoulds” for a reason: you don’t want to do them when you’re not feeling like the peak version of you that issued demands of itself. Discipline is hard, and it stays hard. Just like programming.

Not all encounters with discipline revolve around the kitchen or the gym. They’re everywhere, and for the chair surfing developers among us, they’re plentiful. Sometimes your battles come from a seemingly ideal situation.

Here’s an example. I’ve worked hard to sharpen my skills and improve my business senses to the point where I’ve been able to leave the cubicle and pursue a career on my own terms. A short time ago this was my mothership. But after a long, drawn out while I realized I was actually losing a battle with discipline every day and it was taking its toll.

Even though I freelance, my clients are on the other side of the continent, and I could work from home, complete with varying shades of “business casual” ranging from housecoat to worse, I now share an office with two other software companies. This means I have to get up when you do and take the bus to work rather than sleep in, and I pay for office rent. 

I do this because I’m a terrible remote worker in many respects, though I get my work done, I do it to the soundtrack of the rest of my life falling apart around me; I forget to eat, I forget to unplug, and non-programming but equally important tasks pile up. The discipline problem here is helped by honest recognition: because I know that I overdrive myself and do not thrive outside of structure, I have to set the structure myself, even though it’s cheaper and more convenient to maintain the status quo.

Self-recognition is a powerful tool. Rather than go head to head with a bad habit, you can run around it and avoid it all together. This is running from a fight, no doubt, but picking your battles is a smart play.

“Do what you know you should.”

Lessons from sickness

I spent the last few days laid up due to a surprise overhand left from a quick decision to grab takeout for dinner.

During that time I exercised a well-known and respected ritual, that, had I been sick due to alcohol indulgence and not food poisoning, you might recognize by its conclusion “… I’ll never drink again.”

Beyond the empty promises made in the face of discomfort, I did get a chance to experience something rare and advantaegous: honing.

When you’re sick, discomfort forces you to address only what’s important, while your animal instincts amplify the negative experience; you won’t go near the cause of your illness in the near term, if ever, depending on how many good experiences you’ve logged previously.

If the resolve to remove obstacles in your way is strongest when you’re uncomfortable, then use times of sickness to make decisions that clear those obstacles for you, if they only hurt a little when you’re feeling well.