Agree, businesses should just provide a real number of services, that they are willing to provide. That allows customers to more effectively compare different service providers and allows providers to avoid the situation, when they have to secretly throttle certain users.
But it is so hard to explain to product people, that there is a limit how much certain services can scale and be profitably supported.
I am not a fan of mythologizing people. Most of the listed achievements are just as much the result of the circumstance and should have an asterisk. For example - Einstein was the first to introduce the theory of relativity, but his works stands on the work of others, also if he had failed others would have almost certainly come to the same conclusion. Chris Sawyer at the start of making RollerCoaster Tycoon already had 12 years of game development experience, during a time when being a solo programmer was the norm. Eric Barone was lucky enough to have a girlfriend, who worked 2 jobs to support them both.
I think you're trivializing their achievements, and they deserve to be applauded for their productivity if not for the exceptional outcomes (some of which would have probably been done by others sooner or later).
By the way, RCT was coded entirely in assembly. As if making a game worth of millions is not impressive enough.
Are you trying to imply, that every physicist working in the academic field, who is not lucky enough to stumble on the correct theory is less productive than Einstein? I thought it was common knowledge, that at least 99% of all research is failing.
RCT was coded in assembly, because Chris Sawyer had 12 years of professional experience in assembly. It seems impressive from today's perspective, because today an average developer never really touches assembly outside the single university course. One could even argue, that a more productive programmer would have already switched to C by 1995.
My goal is not to trivialize their achievements. I think if people payed more attention to these stories, then they would have a more healthy outlook on the world. Also they would understand, that working hard in your basement is only a part of the recipe.
The same could be said about a lot of things, like being able to write a functional solution to a leet code puzzle on a black board in front of an audience.
IMHO, an effective interview process should attempt to mimic the position for which a person is applying. Making a candidate jump through hoops is a bit disrespectful.
IMO the interview process should help the employer correctly identify qualified candidates. Respect for the candidates is important but some candidates should absolutely be prepared to jump through hoops.
I have been moving towards integration tests as documentation approach, because in a fast moving environment anything that is not constantly verified has a tendency to become false.
Imho, mutating the same object so many times, that a developer can't easily infer already applied changes is also a strong code smell. Fat models tend to encourage it, since all the mutation logic is available to all the services.
