This also applies to "scaling." Scalability seems to be a major boogeyman among tech startups. The way you make something scalable is by improving the big-O of your processing algorithm, and the way you do that is not by throwing money and processing power at it (buying more servers, hiring more developers with "scaling experience," etc.), but by optimizing your application logic to do as little as possible per input.

Scaling is just a large value of n.

Not to detract from your metaphor, but I think the main problem with scaling is to make as much as possible parallel, so that you can throw more cores / servers at it. Often this is at the expense of raw big-O efficiency I guess.

I guess in terms of your business metaphor, that would be establishing 'big company' things like written processes, constrained departments, and managers who don't code, so that more people can work for the company than the founders can talk to in a week.

I'm no expert in scalable algorithms, but my rudimentary understanding is that there are a few different ways to handle a problem with n inputs when n becomes a very large number:

1. Run it on a faster processor

2. Rewrite your algorithm so that it can run in parallel and the tasks can be divided among more cores/processors/servers

3. Rewrite your algorithm so that it's non-locking and the tasks can be completed asynchronously

4. Rewrite your algorithm so that each task takes less time (fewer/faster queries, fewer array accesses, fewer object instantiations, etc).

In terms of the analogy, #1 is equivalent to working harder on the problem--just throwing more time/money/energy at it. Staying late at the office. This is the wrong approach in programming and in life, because it does not scale with the size of the problem.

#2 and #3 are basically division of labor and task delegation in order to divide the time that it takes to complete the problem. This gets the job done faster but at a cost--you're paying for more heads to work on the job.

#4 is finding a better/cheaper/faster way to do each individual task or sub-task in the problem. It's improving your big-O. Having a better big-O alone will not make #2 and #3 unnecessary, but it will exponentially increase the effect of #2 and #3. It's what business types call a "force multiplier." It's really just reducing the amount of sub-tasks an individual worker has to do in order to satisfactorily complete a task. It's achieving the same thing by doing less.

I agree. If I spend a week doing more than around 20 hours of work, then I'm usually doing something wrong. The following week, I will spend some time trying to figure out what went wrong. There's usually always a better way.

Programming is the perfect lazy-man's work. If you're really good at changing O(n^2) to O(1), then you can pretty much double the output of other teams while also reducing your work. It's pretty fun.

Also, this applies at scaling. If my business model can't afford to hire more people as the demand for the business grows, then the business model is just a bad idea.

I wonder about that kind of argument. I find it super appealing because I would love to work a lot less and yet get more done. Unfortunately I've found that if I work more, I do get more done. Granted, there's a time for stepping back and thinking about a problem rather than continuing to brute force your way through it. And you can get to a point where you spin your wheels and it's better to stop. But generally, more time spent does mean more done, no?

I find that it can be really difficult to measure productivity some times, especially when long hours are involved. If I work 2x hours and I get stuff done all throughout that time (beginning, middle, and end) then I'll tend to think all of those hours were well spent. But when I spend the time and effort to really look at productivity I find that typically spending more hours only produces the illusion of greater productivity. Often times I'll easily forget the downsides of working more hours, such as poorer quality of work, less focus and ability to concentrate, more down time between periods of work, greater likelihood of being OK with partial or inferior solutions, etc.

Over time I've come to the conclusion that except for "it's broken, and time is money" or "I've found inspiration at midnight" situations it's pretty much never a good idea to consistently work long hours on software projects. It's better to work smarter and more efficiently and to have the resources available to do big refactoring / redesign / performance improvement projects when necessary than to just work flat out and always be in an "ok, that's good enough, moving on" state of mind.

Software development is a created process, like writing fiction. Imagine a fiction writer doing a 60 hour (or hell, even a 40 hour) work week to try and get more work done. It just won't work, certainly not long term.

But you do need to put in the practice time to be able to be productive when you need to be. If your process involves a lot of procrastinating with intermittent bursts of brilliance ,you won't be able to be relied upon when things get tough. Stephen King became the writer he did because his wife would tell him to write a story, the baby needs diapers, and he did.

So before you can work smart, you have to know how to work hard. Otherwise you're just goofing off.

Yes, it is a creative process. I think that a better analogy is to a scientist though. Sometimes, scientists spend a lot of time thinking about what an experimental result means and planning out their next set of experiments. But oftentimes, they also have to crank through a bunch of experiments that they've planned. The more time they spend at that point, the further they get.