I read the post of a young man, much like myself, who is lamenting his addiction to idea creation, to finding more satisfaction living in the possibilities of new projects than in the reality of building them. He has a lot of domain names, because he believes the thrill of it is in the beginning.
That fact that we don’t hear more stories like these is only because few people have the courage to stand out in this way, especially when we commonly hold on to beliefs that we aren’t good enough, such as we are.
First, a swift jolt of deprogramming, to lift us out of this state of mind. Read “We Are The 99% Of Startups”. Read “Fuck Glory - Startups are One Long Con”. Try to laugh, just a little bit, at all this pageantry over flipping bits around.
The thrill of it, truly, is in the completing. Because coming from a place of completion, we get to do all the things we’re afraid we should be doing, but aren’t. Because anything other than completing, whatever we do to try to replace that place of true privilege (like conferences, schmoozing, new web sites, marketing spends, et al.), is just stealing from our own future.
Channeling Anne Lamott, programming is just one damn line of code after another.
So, Sean, you are the intervention. Not this made up version of you that has to have certain things about your art be true, to be happy. The you right now. So pick one of your ideas out of a hat, and work on it, not in a frenzied pace where you stare at the clock like you’re missing the party. Just work on it, slowly, until it’s done. Then do the next one.
Code Soloist is for single-person software 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.
Imagine you are standing on one side of a football field. You start running towards the other end, and depending on how many times you’ve done this before, you feel pain, or fatigue, or burning in your lungs. Or perhaps just the sheer pleasure of feeling warm wind in your face. When you reach the other side, you are finished.
Now, run the same field, but this time, be an ant. Run over the mountainous pebbles, through the oceanic puddles, frantically over this giant world. It seems like the earth could swallow you up at any moment. But it doesn’t, and you wouldn’t notice if it could, because you’re an ant. Your gaze never leaves the ground, you’re just looking at one thing after another as your legs push you toward the end. But you don’t have a temporal lobe, so you wouldn’t know the end when you got there.
The distance between good and great software is always the same. It’s the same football field. What’s different is how big you feel, and what you’re paying attention to along the way.
Code Soloist is for single-person software 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.
There are some in our world whose work is truly inspired. When they launch a new project nonchalantly from their pixel-perfect blog, communities form up around the intellectual scraps.
This is the domain of the Gentleman Coder, a term I stole from a colleague, while I was trying to convince him that it’s not a great idea to take a few days off a project that’s meant to provide him a living, to pursue a smaller, impressive, but wholly unprofitable idea he had in tandem, no doubt during a period of mental exhaustion. These ideas are the kind that usually appear when we’re spending our time in the details of an idea already explored, already mined for excitement, going through the motions until it is manifest. The fact that you still have these ideas is healthy.
A Gentleman Coder is anyone who creates software for enjoyment, simply because they can. They have already secured enough revenue to live well, and are now curiously, happily exploring the love of their craft without financial or time constraints.
It’s good to have heroes to look into, but following along is problematic if you look up to them. It’s healthy to have role models, but by following heroes who have already taken their chips off the table, it’s easy to mentally skip over the part that defined them. It’s the same part that stares you in the face now, when time is at a premium, and your idea has made the transition from excitement to work. As a builder, you will gravitate many multiples of times to interesting problems that you can solve elegantly while moving towards your goals. The trick is to avoid them.
The point is that all success looks effortless after the fact. Taking time away from your hard work to pursue an intellectually exciting side project can seem cathartic, almost as if you are walking in the footsteps of giants, creating useful, beautiful open source software for the masses, but it’s really stealing from your own future; the future where you’ve put the time in, and can now emulate the folks who have reached the rare position that they can code purely for enjoyment and intellectual pursuit.
At least know the difference. If you would rather keep your side projects for mental stimulation and relaxation, without attaching commercial aspirations and the resulting stress, then you are setting yourself up for achieving the kind of happiness that can live with a day job, and seeks to avoid gambling free time for a potential future where there’s more of it. Kudos.
If you’re seeking freedom from a corporate lifestyle, changing the world in your own small way with software, or acquiring islands, understand that when you see thoughtful, unrushed work, it is the culmination of either a career-sized helping of perseverance that preceded it, or a mindframe that runs perpendicular to your own. When you can recognize The Gentleman Coder in both of its forms, and your desire to pretend now what you may earn later, you may not be tempted to live in your future, choosing instead to do the thing in front of you.
Code Soloist is for single-person software 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.
This one is short. Stop spending so much money chasing your tail, or a dream. If you’re anything like me, you have these sudden, pivotal shifts in inspiration that convince you that this is the idea, and this is the [consultant / designer / component / service] that’s going to make all the difference.
It isn’t. It’s not. The idea you were already working on was plenty good enough for now. You create a non-virtuous circle of resource waste when you put your money down on a new idea. First, your mental machinery has to justify the purchase, so whatever you might have been working on beforehand will temporarily take a back seat while your brain injects itself with reassurance that the purchase was sound, in the form of false enthusiasm. When the inspiration for your “next big thing” wanes, your brain will then counter the original rush with guilt about betraying what you already planned.
The things I’ve worked hardest on, and am proudest of, have all come from the least of my investments. I don’t think that’s hard to wrap your head around. An idea, like people, can be born with “a silver spoon in its mouth”.
The trick is to always know that the new thing is suspect. The new thing can’t prove itself with the false priority of purchased time and attention. If the new thing wants to stick around and replace the old thing, it better be able to do it without spending a dime. That should be the litmus test. Otherwise, it’s just your engineer’s spirit, not a legitimate alternative. It should be respected, thanked, and shown the door.
Code Soloist is for single-person software 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.
We’re often told to fixate on the end result, so that we produce the effort required right now to achieve it. “Keep your eyes on the prize” makes tigers of us all. But the problem with this approach is that we don’t recognize that without already possessing a concrete plan, and the necessary motivation, the strategy fails. In fact, “keep your eyes on the prize” is essentially a nonsense phrase, because you can only use it effectively when you don’t actually need the advice it contains.
We don’t see it that way, most of the time. Consider the overweight person who keeps their eyes peeled on the body they don’t have today. Possessing no plan other than fervent hoping, keeping their eyes on the prize only increases the anxiety of having to live in a present moment, with their present stature.
And that’s exactly how we approach the side project that is meant to set us free, however we define freedom. Just think about what it will be like when you launch, when first sales come through, when you resign from your day job. Don’t actually have a plan to achieve it, just spend the time, eventually it will happen if you’re smart, determined, and lucky enough. We mistake “I’m going to work on this every night and weekend” with “I have a plan”.
Instead, I suggest you take your eyes off the prize, and focus on the process. I keep returning to the idea that simplicity isn’t about removal, it’s about automation. A true plan involves setting your days up so that it’s impossible to fail. So that you are the kind of person that will bring your project home, not just the kind of person who will work on it. There’s very little in common between working on something, and actually finishing it. About the easiest thing I can think of is working on something forever. I know because I’ve done it.
If you’re confused at this point about the difference between a true process and plan, and expending effort, you can start with the smallest process: flossing. Flossing is a great example because it’s one of the things in life that you’re told you’re supposed to do, that you don’t see immediate benefits from doing, and in fact you will notice no positive results from doing it at all, if you’re doing it right.
You’re only flossing to avoid some vague but painful possibility at some far future date. The reason most people don’t floss is that most people do not possess the vital skill of developing a process (daily flossing) that guarantees a desirable outcome (not losing your teeth) even when there is no immediate or even mid-term tangible benefit.
The distinction is this: the “prize” of good oral health is so far away from grinding it out each evening in the mirror that it’s not worth focusing on. The only thing that matters is the process, the automatic habit, that you’ve set up to guarantee that you’ll achieve the result.
You win when you can identify the daily processes that, when repeated, will get you the prize, and then work to make those automatic. The rest is details. You can start by flossing.
Code Soloist is for single-person software 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.
You really can, and do, get bored of your own ideas. Even your best ones. Many times the sheer act of expending effort on a great idea is enough to kill it. It’s okay. But you need to hack the mental system in any way you can, or you’re going to walk off the set of one of your projects, even if it’s a good part of the way there (80% done, 20% complete). I’ve already done this. I’ll have lots to write about that later.
Be interested to begin with
I was fortunate to have the chance to meet and speak with Ruben Gamez, creator of Bidsketch, quite accidentally while attending Superconf. Ruben is a true code soloist, having built a profitable, useful, and thoughtful service as a solo developer. Before Ruben found the persinpiration (inspiration to perspire) to launch Bidsketch, he built a testing management tool, reached 75% completion, and then dropped it in the can because his mind was bleeding from boredom; during the discomfort, he planted a seed for an idea he could stay interested in, and brought it home.
Inject help when it hurts
Don’t think for a second that being a code soloist means you do everything, all the time. Well timed help can dig you out of a hole you’d otherwise spend long enough in to question why you started in the first place. If you’re still feeling the love but you’re buried under the details of finishing, hire out. This isn’t cheating, chefs don’t wash their own dishes.
Allow for a wandering mind
You need to scratch your mental itch. I used to think this was a bad idea, that a wandering mind was symptomatic of an inborn inability to ship product. But that’s not true. It comes from loving the energy of the start, a technologist’s “runners high”, a cocktail of oxygen, anxiety, and hope. Use that feeling as a litmus test for the project you’re running with. If you don’t feel it on a weekly basis, you’re probably setting course for a creative burnout.
Code Soloist is for single-person software 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.
Here are two concepts that have risen, seemingly in opposition, in the last two years in product-focused business engineering, specifically for soloists of all trades:
1. Do what’s in your DNA and avoid everything else. Follow your passion.
This is most definitely the mantra in Gary Vaynerchuk’s first book “Crush It!”, and his many talks leading up to that release. The thinking is, passion sustains the motivation to relentlessly pursue building a self-central brand that eventually leads to profit, maybe. If it doesn’t, maybe you aren’t passionate enough or maybe you’re not truly listening to your DNA (which I’m taking to mean your specific skillset within a narrow band of digital media, which boils down to whether you develop content for video, audio, or written channels).
2. Do what will bring a profit. Don’t follow your passion.
Most eloquently captured by Amy Hoy’s latest product development blog “Unicorn Free”, this strategy means to circumvent the passion argument to avoid burn out and to help you navigate the many unpleasant aspects of turning something you love into a business. You start by mentally picturing a passion you have as a real business, amplifying the discomfort of the downsides until the only things left are the specific interactions in the business that you would still enjoy. You weigh your unhappiness dealing with the balance of this fictional business against its true potential of making money.
While these ideas are useful as lenses, both require you to trade on happiness. There’s money, and there’s happiness, and you have to either cling to money and accept misery, or cling to a false form of happiness that promises money, and if the money doesn’t follow, will make you miserable.
Better might be to take happiness off the table completely. If you don’t play that card, you can’t lose it to luck, timing, or poor judgement. Happiness is too important to risk simply for the chance that your financial success might produce more of it. Misery has never guaranteed success, and never will. You don’t win by sacrificing more, or being more uncomfortable than your competition.
How do you get to keep your happiness while still progressing towards some tangible result that has commercial viability? Go slower. Build what makes you happy, without thinking about the financial implications. Really. If you get lost in the possibility of profit then you’re doing the wrong project.
A big part of this is doing the work you need to, to understand that somewhere along the line you decided to use money as a proxy for your happiness, and placed all of it on the other side of having a lot of money.
Happiness doesn’t guarantee success any more than misery does, but at least you can fail with your happiness intact. And like any delicious paradox, truly inspired creation sticks out on the shelf.
Code Soloist is for single-person software 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.
You think you can build an ambitious startup* by yourself. The truth is, you can build any number of them that you feel are 80% complete. Turns out, 80% of the business is in the other 20% you can’t do well, or fast, or cheaply. Pareto’s a bitch. You’re better off in terms of expectations if you flip Pareto’s principle around: when you’re 80% done, you’re 20% of the way there.
You think you have both the time, and money, to ship a finished product before that deadline you’re thinking of. This is because the conventional wisdom says that the cost of building a startup in the current technology climate borders on free, with time being the only capital needed. This is relativity, and it doesn’t apply to you, assuming you don’t have a significant source of funds. An engineer-founded startup today still requires cash, in the form of servers and graphic design. The former is cheap enough if you’ve got a full time gig, and the latter varies. But code soloists likely don’t consider the five to ten thousand dollar investment in decent design as ‘bordering on free’, or, they lie to themselves and say that design is a secondary concern. There’s only one of you**, and you need to pay for outside help.
You think that business book you’re reading is a great book for you, and not just for startup teams with funding and the luxury of unlimited focus. Be wary of the insights from teams. While there’s lot of positivity and energy to unearth in business book classics and new work from your favorite web-slinging duo, you’ll be better off reading these books like you would read a self-improvement manual, with an eye to the future and a casual air. Beyond the criticism that these books largely contain what you already know from experience and social osmosis, as a single developer team, the actionable parts rarely transfer well to your specific goals.
You think you should start with a minimum viable product. The truth is, you need to start, and stop, with a minimum viable business. The product should be small enough that the minimum version of it is all there is. Kent Beck said recently, “Don’t try to do big things. Do little things that can grow into big things”. Taking this mentality at face value, you unconsciously expand your idea out beyond your capacity, and the justification is, you only have to work on one small piece at a time. But that’s revolution, not evolution. The difference is, revolution is never finished, evolution can be what it is for as long as it’s convenient. If you’re racking up experience building whole products, however small they are, the opportunities for these products to evolve after the fact are endless, but if all you’ve got after months of effort are sign posts pointing to some vague concept of a larger product, you’re spinning the wheels. Don’t build small pieces of a possibly big thing, build a lot of small things that stay small. Evolve the winners.
You think there’s no money in a crowded marketplace***. You’ve got more than enough literature to prove that app stores in any flavor don’t bring big profits for nearly everyone who invests in building software for them. Turns out, the world is a lot bigger than an app store, and the same business principles apply in both places. Doing business is hard in any forum. Would you rather try to get the attention of a smaller pool of potential customers with a proven record of purchasing software on your platform, or nearly 7 billion without?
* I consider ‘startup’ here as a term for ‘new business’, but I’d argue that a new business built by one person isn’t really a ‘startup’ at all, and throwing the word around limits you to thinking about your new business as something that needs to grow fast, or be big, to live up to its name. Really, ‘startup’ should be reserved for companies with a board and funding. If you have neither, you’re probably a ‘new business’, which doesn’t limit your thinking at all, or heap false expectations on your plans.
** Contrary to physics, a founder that is simultaneously a developer and a designer, and skilled in both disciplines, is really two people. You can distinguish them from others by the large, conical horn growing from their foreheads.
*** Hat tip to Adam McNamara of Select Start Studios for the conversation that led to this idea.
Code Soloist is for single-person software 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.
When people say in order to be successful you should simplify your life, it doesn’t mean you should remove things from it. It actually means you should cement things, and make them automatic.
For example, simplifying your life doesn’t mean cutting out that 9am run you’ve been meaning to have, but never acted on. It means forming a habit where you no longer have to think and worry and conjure up bad feelings about that run. That run isn’t an option.
When you have no options, you’ve done the hard work of simplifying. It’s easy to relate a lack of options or features to simplicity, it’s all the rage in web application development today. But it goes deeper.
Apply this thinking to your product; by committing to one unit of work, one feature per day, no matter how small, you’ve simplified, in that clutter-free, pseudo-zen way. More importantly, you’ve actually cemented the success of your product, because just from the simple fact that producing small but meaningful work is now automatic, there’s no possible way you won’t complete it.
Code Soloist is for single-person software 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.
Because we play in a digital world, developers tend to have an over-inflated sense of spoon bendability: we believe that because we build inside this world, it means we’re creating it, when in reality our creations are still bound by most of the same laws as our bodies are.
When we create, we must obey the constraints of time and money, or more generally, our own energy. You cannot fight against principles and win. When I told you to play your game, I meant it. I didn’t mean you could nod in agreement while continuing to conjure up your epic idea that is too much for one person to realize.
The Work Energy Principle states that “the work of a force is equal to the change in energy that it produces in the object on which it acts”. You, the force, have a finite energy, and your job is to compell your project to produce its own energy, or success; to the degree that you succeed, that is how work progresses.
As a code soloist, there is no way that you can circumvent the laws of mechanics and use a spark to power a collider. Thanks to the principle of momentum, you will never get off the ground. It is not a simple matter of time and effort: this thing you are creating, digitally speaking, has real mass.
What you can rally against is process. Your own process. How much you produce and when you produce it. How much you waste. You can treat a fight against process as a creative experiment. You can treat it like a game, and it’s a game you can win. But the second you start wishing your beach ball was a boulder, you’re going to drop it.
Code Soloist is for single-person software 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.
