“Some big company with big resources could implement your startup idea in one week”
How true is this statement?
One of the reasons startups win, is that big companies just want to avoid disasters. If you can figure a way to design & build beautiful software that competes with software that is designed by product managers at big companies, they’ll never be able to keep up with you. Simply because of the number of iterations per time unit. Startups can iterate much faster than teams inside most companies.
There’s more than one argument that easily invalidates the above statement, but most accurate of which is of Paul Graham’s. In his book “Hackers & Painters”, he discusses the difference between a hacker, an engineer, and a scientist.
Hackers figure out huge parts of the software AS they’re writing it. In that sense, they are makers, much like painters, or writers. Much of the ideas that end up in a writer’s piece or a painter’s painting were ideas that originally came up during the act of creating; but didn’t exist before.
So hackers learn by doing. This is not the same for scientists or engineers. Scientists & engineers start out doing work that's guaranteed to be perfect according to guidelines & detailed scoping. Eventually, they get to the point where they can produce original work. Whereas hackers, from the start, are doing original work; but it's just very bad. So hackers start original, then get good, but scientists start good, then get original.
This is the exact reason there’s just no place for hackers in companies or universities. Hackers only belong at startups. Because universities and research labs force hackers to be scientists, and companies force them to be engineers.
In a big company with a fleet of engineers, where the propagation of novel ideas up & down a hierarchy is optimally kept minimal, this “iterating while creating” approach is almost practically impossible.
A hacker’s way to create something beautiful is often to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way. This kind of work is hard to convey in a research paper, for example. But scientists & engineers they work with mathematics & research papers all the time. It's easy to drift away from building beautiful things toward building ugly things that make more suitable subjects for research papers, which is just not a hacker’s cup of tea.
If hackers identify with other makers, like writers and painters, they won't feel intimidated with these formalities. Writers and painters don't suffer from math envy. They feel as if they're doing something completely unrelated. So they just don’t care. This “don’t care” mentality is in my opinion what makes a hacker’s work identifiable.
And also, in my opinion, this is why “hacking” is “risking”.
Hackers generally don’t care about proxies for achievement represented by the software they’re writing, such as research papers or patents or competition against bigger companies. Most hackers are detached from the outcome.
BUT, if this risk turns out to be a win, the dividends from this one bet could potentially outweigh every other plan a hacker could’ve carried out during their lifetime.