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.
There is a time to create and there is a time to share. You can’t do both at the same time, and you can’t do one exclusively. If all you did was create, nobody would know, and nothing would change as a result of all your effort. If all you did was share, you’d quickly run out of things worth sharing and people would notice. There are lots of folks in both camps. It’s easy to spot an overcommitted sharer who has forgotten how to shut up and innovate. It’s harder to spot an overtaxed creator who has never stopped working on something you’ve never heard of.
Schedule your creation and sharing periods like anything else in life. One must always precede the other. When you’re creating, shutup, when you’re sharing, close your IDE. Make sure you do both.
One of the more shared moments in recent memory, in our little world, started from this simple statement:
“I made something. http://howfuckedismydatabase.com”.
Notice how easy it is to share something when it really exists. Now try doing the same thing like this:
“I’m going to make something. http://howfuckedismydatabase.com”
Imagine the page is “under construction”. Feel the difference?
It’s not like social platforms changed the laws of nature. That suddenly it’s no longer true that the best things get noticed. That you have to have something to sell something. You might not like the fact that during your creation phase, you’ll lose “followers”, or “hits”, or whatever you’re tracking. That you won’t be in the conversation and possibly not first of mind. But there is an effortlessness that comes from having something real to share, and you won’t have to try so hard to get those things you’re after when you do.
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 need to draw a line in the sand and stand behind it. There’s a sort of cap on the amount of inspiration, planning, and daydreaming you can do before you inevitably must take a stand on what you intend to create. After you reach this enthusiasm ceiling, you can only do one of two things. I have met a lot of people who are simply addicted to the potential of building a business and so they spend all of their time going to technology conferences and mixers and pitching their “amazing technology”. But you’ll see the same folks next year giving the same pitch, because this is where they live, in the possibilities. Possibilities are exciting; transitioning your great ideas into your second job is not. But this step is the most important. This step Hugh MacLeod would call “Do I make this damn thing exist, or not?”
Notice how it’s not “I should make this thing because I’ll get rich”, or “I probably better do this because I’ve already told everyone I’m doing it”, but “I will make this damn thing exist”. That’s taking a stand. It’s closing the browser tab on this blog and doing some real work, even if you don’t get paid for it, expecting that you never get paid for it, but not caring because you have to live in the world where the thing you’re imagining right now is real. Not a lot of ideas can survive that kind of commitment, and the kind of ideas that do, have a better chance at making it than the greedy pitches you hear at those networking events.
I’d argue that you have more opportunities and advantages today than at any other time and most other careers. You can literally build a business with your bare hands and reach customers worldwide for peanuts. And nobody else but you can do this. Sure, a marketing guy can buy outsourcing to put a sales page together but that’s going to break down real fast when things get complex.
I also don’t see things changing any time soon. Demand for technology goes up, user comfort with web-based applications and eCommerce go up, software complexity goes up, and every time someone thinks they can commoditize what you do, to make some magic piece of software that does all of the work for them, so they just have to slide a bunch of boxes around and they’re suddenly software engineers, it fails. Miserably. Because you can’t fix complexity with simplicity, you can have complex or you can have simple but not both.
You can go simple and draw a line in the sand, or you can get complex and try really hard to live in the possibilities, to have the possibilities be enough, and ultimately create nothing.
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.
A few years ago a good friend of mine used a quote from a stupid movie to change how I thought about hard work.
It was from Road Trip: “It’s supposed to be a challenge, that’s why they call it a shortcut. If it was easy it would just be the way.”
If it was really possible to join some paid subscription site, or read this or that book, or outsource everything to foreign countries, and then you would launch your business faster, it would just be the way.
But it’s not.
The way is a seemingly endless ritual of focusing on a single point of failure, correcting it, and moving on to the next point.
The way is an inexhaustible supply of “todo” lists, built on a web site or scratched in pencil on a growing pile of crumpled printer painter next to your keyboard.
The way is having days when you throw up your hands and announce that you’re out of the software business forever, only to come back the next day renewed.
Every amazing and miserable moment is part of the process. Rather than waste time looking for a happy path approach to avoiding hard work, take the shortcut instead. The shortcut to launching is just the way; no wasted time, just hard work, fully embraced.
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.
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 idea 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 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.
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 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’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 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 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 software 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 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.
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 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.
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 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.
