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.
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.
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.
“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.”
Most of the time the thinking goes: focus on one thing relentlessly to the detriment of just about everything else, and you will break through. It’s a mentality borne from the persuasive 10,000 hours observation and the emotional high of success through perseverance that has survived at least 2,345 years of theater.
One path to greatness at software development is to be good at other things, too. Just as its good practice to give another developer a problem you’ve exhausted your thinking on, to benefit from “a fresh set of eyes”, setting your mind to another exercise requiring skill and patience allows you to revisit your own work, to be your own fresh set of eyes on a problem. If you’ve ever experienced reading something you wrote long ago, and seeing it as a first time reader, you will understand how this works.
If only to achieve balance, it might be time to dust off an old hobby.
Your “other thing” is usually a hobby, but it can be related generally to your work. For example, I know a developer who is also quite talented in business development, and another who enjoys salesmanship. Both of these skills have their own disciplines, heroes, and trials that are separate from the specific skill of creating software.
Companies are desperate for talent and it shows.
More often than not, part of the spiel of any software house is their relentless quest for the best of the best. Whether they make good on their promises to seek out truly great people and make them comfortable, or continue to follow the lowest common denominator principles of hiring aside, the problem persists.
Jason Fried tells businesses to “de-commoditize” their services to stay on top; to make what they offer, in an increasingly homogenous market, impossible to replicate. By adding personality back into the formulaic.
But the axe swings both ways.
Surprisingly little about what you do is truly unique. Someone else is going to work as fast or faster than you, as good or better than you, as long or longer than you, and all for cheaper than you’re comfortable with.
And before you start leaning on your unrelenting community activities for comfort, these folks also blog and engage and contribute. These activities are no longer badges of honor, they are required, expected, and taken for granted. They’re boring.
This is the new hiring climate: Everybody’s hungry, and engagement is mainstream.
Becoming a provider of unique value is far more than sticking a “for hire” sign on your digital front lawn and declaring yourself open for business. There are hundreds of thousands of front lawns just like yours.
So what are you going to do about it? There’s no book for that. It’s probably not just being funnier, or more honest, either. It probably has something to do with mastering what you have, focusing on your weak points, and taking a strong stand on everything you care about. Probably.
The good news is, if you find your voice, it’s easy for companies that need you to find you, and you can work for them on your own terms. Because freelancing itself is borne from an inborn necessity to thrive without compromising vision or direction.
Faith Popcorn says, “Time is the new money.”
And if you’ve got the stuff, freelancing is the new employment.
Not enough people are attempting the impossible.
It’s odd to think that as a society we can barely keep up with the technological demands for the absolutely mundane, let alone the extraordinary.
We praise simplicity because we spent years polluting software with complexity. I appreciate that the effects reduce noise and make it easier to consume software, but it has created an entire Durdenesque industry devoted to the single-serving application that champions the mantra “one app, one month, one dollar”.
Eventually we will run out of ways to plugificate our socialosity interactivus, and software development will constitute drawing diagrams that lasso flavours of concerns served by other applications, with microformat glue.
Amidst this race it seems we pretend to swing for the fences but leave the bats at home. Ever closer in our pursuit to achieve digital fidelity that can’t match real interaction with other beings, I wonder if there isn’t a new market for the tastefully complex and the pursuit of the impossible.
Many developers suffer from myopia, and not just the glasses-on-your-face kind you can get a prescription for. Literally we just see what’s in front of us, usually to the detriment of everything else.
And then routine sets in. What’s in front of us is a screen and a keyboard. We forget to take breaks and we catch our rays through the window. We read “coding ninja” and “developer rockstar” in job market ads, but if we look in the mirror and if we’re honest, almost none of us look like a ninja or a rockstar.
Here’s a building block of great software you might not know about: water. Here’s another: sunlight. Another: air. Feeding the body feeds the brain that feeds the code. If you’re good now, you’ll be great later if you log less time in front of the screen and more time on your health and wellness. When you do code, put everything into those shorter sessions and break the habit of obsessing after the fact.
I think the best developers I’ve met are fit, and have something else in their lives to draw inspiration from, or exhale through. One developer I know that can code circles around me is a martial artist and digs into difficult coding problems for the sheer fun of it: I can’t link to him because he has no Internet presence whatsoever, and likes it that way.
Lately the trend has been for developers to refer to themselves as craftsfolk. “Hi, I’m a software craftsman”. This is due to a debate about software development not having a central artistic element, and that we should focus on function and form in our created works like a carpenter cares about function and form in theirs. There’s even a manifesto for it, if you’re into flag waving.
The dictionary will tell you that “craftsman” means the same thing as “artisan”, but Aristotle doesn’t agree. He places craftsfolk squarely above artisans, because an artisan will create “inspired” works without necessarily having the knowledge or experience that could produce the same work consistently.
Louis Nizer goes the other way. He coined the phrase “A man who works with his hands is a laborer; a man who works with his hands and his brain is a craftsman; but a man who works with his hands and his brain and his heart is an artist.”
I like this definition of artisan: they don’t necessarily produce as much polish as their craftsfolk contemporaries but they are not interested in correctness for its own sake. It’s easier to think of development as a craft, because we don’t tend to bliss out on a parser we just wrote.
For me an artisan has heart because they care about the effects of the work over its artifacts. They might say “I’m not in the business of coding software, I’m in the business of freeing people with technology.”
