We look forward to the next part in the series!
Running a Software Business on 5 Hours A Week
31–40 of 79 posts
Re: Running a Software Business on 5 Hours A Week
#32As someone who struggles to come up with 'lifestyle business' ideas, his advice on just talking to people was like a punch in the gut. So obvious it hurts, yet I ignore it and spend time 'thinking.'
So, how would you describe your experience with part-time development ? I'm wondering if working 20+ hours a week on top of a regular 9-5 is enough.
I agree. See relevant blog entry - http://blog.gridspy.co.nz/2010/02/part-time-entrepreneur.htm...
Re: Running a Software Business on 5 Hours A Week
#33Have you thought about writing an ebook like Getting Real?
http://news.ycombinator.com/item?id=1186157
Yes, but he's already written large parts of the book on his blog. He could outsource an editor or even ghost/cowriter to assemble it. Could be a possible project for after he quits the day job, but there are probably others that would pay better.
Re: Running a Software Business on 5 Hours A Week
#34Using Slashdot terminology - Interesting, but not Insightful.
Patrick is trying to derive generic advice by formalizing his personal experiences. While it is useful to know what worked in his case, it is still just one project, an isolated experience.
I've been in a similar situation myself. I have sold a startup that settled me and my family for life, and things unfolded pretty much as I expected them to from the start to the acquisition. But the more I think about the whole experience now the more I am becoming convinced that there was a great deal of chance involved. And over the years I started describing my startup less in terms of how things should be done and more how they worked for me.
In other words, once you are lucky, twice - you are good. Once you are "twice", then it will be Insightful. Until then it's just Interesting. Feel free to disagree ;)
Re: Running a Software Business on 5 Hours A Week
#35Using Slashdot terminology - Interesting, but not Insightful. Patrick is trying to derive generic advice by formalizing his personal experiences. While it is useful to know what worked in his case, it is still just one project, an isolated experience. I've been in a similar situation myself. I have sold a startup that settled me and my family for life, and things unfolded pretty much as I expected them to from the st…
Candidly I think you have mis-assessed.
o Code is 10% of the business
o Wall Clock Time vs. Calendar Time
o Avoid Events, Plan for Processes
Re: Running a Software Business on 5 Hours A Week
#36In our periodic bouts of crunch time, such as the last three months, I end up sleeping at a hotel next to the office (about 25 times this calendar year). Oh man. Maybe it's just me being an ignorant American, but doing that for anything but a company you founded is just crazy. I can't believe that's the norm in Japan.
It Japan, as far as I know, it's not "periodic bouts of crunch time" that brings salarymen to small hotels instead of home, but "nightly bouts of alcohol".
Re: Running a Software Business on 5 Hours A Week
#37Using Slashdot terminology - Interesting, but not Insightful. Patrick is trying to derive generic advice by formalizing his personal experiences. While it is useful to know what worked in his case, it is still just one project, an isolated experience. I've been in a similar situation myself. I have sold a startup that settled me and my family for life, and things unfolded pretty much as I expected them to from the st…
We tend to have quite a problem with survivorship bias[1] on HN. We like to look at the cases where things went well and we assume that is because they did something right that the others did not, and since the founder believe this, he will list the things he intentionally did that he thinks helped. In reality, it may have been something he was taking for granted, or it may have been that he happened to miss some common pitfalls. From one data point it is impossible to know if those are the factors that pushed him over the edge or not.
Of course, one data point like this is useful if we look at all the other stories we get here on a daily basis.
Re: Running a Software Business on 5 Hours A Week
#38Works for me too. I often spend less than 5 hours a week working, and I have a 6 figure income. My web applications compete directly with Google and Microsoft, among others, so the "no competition" argument is out.
I generally buckle down for a few weeks of hard coding (meaning 4 hours a day for 3 or 4 days a week), once or twice a year, and the rest of the year I'm just doing customer service, system administration stuff, and limited marketing. Just maintaining the architecture for the sites is the biggest time sink -- one of the webapps has two different kinds of database servers (MongoDB in the front, MySQL in the back), web servers, worker servers doing incremental processing/rollups... and I keep things PCIDSS compliant which means self-audits, lots of security patching, etc.
Running affiliate programs for my products and encouraging customers to use them to refer others has been extremely important. Affiliates do all the PPC marketing, article marketing, social bookmarking FOR me, with their affiliate links.
Just goes to show there are a hundred ways to run a successful business. The venture backed 60-hour-week startup isn't the only option.
Re: Running a Software Business on 5 Hours A Week
#39(Aside: I know many Americans consider the last option shockingly irresponsible. My ability to prevail over my employer — a major multinational — in a lawsuit is effectively nil. A contract is just a formalization of a promise. In Japan, the ongoing relationship with my bosses is the part of the agreement that provides security, not the piece of paper.) This is one of the more important bits of advice I've seen Patri…
This is a large part of why I advocate waiting to incorporate until you can do it right. The instacorp LLC won't really protect you when you need it most.
Re: Running a Software Business on 5 Hours A Week
#40I acknowledge the fact that a product is more likely to be successful if it is made simpler. And I face the difficulty of trying to create a complex product every day. Hence his advice: "Are you considering starting up a business because you wish to work on wonderfully interesting technical problems all of the time? Stop now — Google is hiring, go get a job with them. 90% of the results of your business, and somewher…
I thought that was the best line in the piece, because it's so true. Probably 90% of the engineers at Google are there because they want to work on wonderfully interesting technical problems all the time, and don't want to deal with all the other bullshit that comes from running a company. And I suspect that a major part of the reason my startup failed was because I wanted to work on wonderfully interesting technical problems yet also wanted to get rich. There're a limited number of problems that people will pay you to solve, and most of them are boring.
As for who is eligible to build a complex product? Nobody. If you set out to build a complex system from the start, it invariably won't work at the end. Remember Gall's Law:
http://en.wikipedia.org/wiki/Galls_law
Before you cite counterexamples like Linux or Google, it's worth considering what they looked like when they started. Linux started as a terminal emulator that would spit back "ababa" when you turned on the computer. Google's early webserver was a dozen or so source files that looked vaguely like Tornado, except that instead of having all those webframeworkey goodness like regexp-based dispatch rules and templates, it would just issue "prints" on the file descriptor for the user's connection.
If you want to write a database from scratch, you should start with some sort of basic persistent key/value store. Then give your values a column-like substructure. Then figure out how to index it. Then figure out how to index it based on multiple columns. Then figure out how to handle joins and sorts. Then slap an SQL parser on top of it, and you'll have something similar to MySQL c. late 1990s. Then endure all the laughs as people say you're not a "real" database, and put in 10 years of incremental improvements while you add transactions, and better SQL compliance, and query optimizers, and wire protocols, and replication, and clustering, and all that stuff.