Usually, though, there is a continuum between the "code a well known and well understood problem quickly and maintainably" and "figure out the math/algorithms t

Usually, though, there is a continuum between the "code a well known and well understood problem quickly and maintainably" and "figure out the math/algorithms to do do it in a new way". If you can stay closer to the latter, that is a competitive edge too. (Provided you don't bungle the basic stuff in its pursuit). I remember this thread from a few days back when I asked about Mathematica: https://news.ycombinator.com/item?id=12473688 https://news.ycombinator.com/item?id=12473688 A relevant section from PG's How to make Wealth [1] essay: "Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him. What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we'd always take the harder one. Not just because it was more valuable, but because it was harder. We delighted in forcing bigger, slower competitors to follow us over difficult ground. Like guerillas, startups prefer the difficult terrain of the mountains, where the troops of the central government can't follow. I can remember times when we were just exhausted after wrestling all day with some horrible technical problem. And I'd be delighted, because something that was hard for us would be impossible for our competitors." [1] http://paulgraham.com/wealth.html http://paulgraham.com/wealth.html