I believe that software-related college degrees are mainly there to get the horrible first few tens of thousands of lines of code out of people before they go into industry.
This reminds me of Joe Kennedy (JFK's father) getting out of the 1920s stock market right before the Depression because his shoe-shine boy was giving him stock tips.
"The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble."
"Something must be done, and this is something". I don't really see the evidence that the 'odd' startups are more likely to succeed, and even if that is the true it doesn't obviously lend itself to the strategy of 'do something odd intentionally to increase your chances of success'
> I don't really see the evidence that the 'odd' startups are more likely to succeed
Successful startups are ipso facto odd. It's not unreasonable to assume that that's correlated with doing odd things.
> it doesn't obviously lend itself to the strategy of 'do something odd intentionally to increase your chances of success'
I'd say it fairly naturally suggests that in a startup you should be pursuing high-variance strategies i.e. taking risks (indeed I'd say that's already accepted wisdom for startups). Following through on your contrarian thoughts more often than you would in a more established company makes sense.
> It's not unreasonable to assume that that's correlated with doing odd things.
I don't think this logically follows: it is odd to win the lottery but being weird while scratching your ticket doesn't make you more likely to win.
But even if we accept "successful startups did something odd, and that was responsible for their success", it seems more likely that successful startups found a couple key odd things which helped them succeed, but that startups which specifically deliberately opt into doing odd things without reason are more likely to fail than average. Most odd things are odd because they are bad, at any given decision taking the odd path is more likely to lead to failure except for a few golden odd opportunities that you have to try to identify somehow.
I guess it also depends on the goal of the startup, if you're buying a unicorn lottery ticket with your streaming video startup then leaning into increasing variance might be what you want. If you accept "lifestyle startup run rate" as a success it seems more likely to succeed doing maximally boring things.
Successful startups don't necessarily have to be _operationally_ odd; they could just choose an odd domain and then operate in the most boring, corporate way imaginable. There are so many underserved markets that the larger players either don't see as worthwhile or don't see at all.
"If you do everything the way the average runner does it, you should expect average performance. The problem here is, average performance means that you won't win a race... So if you want to win a race, you'd better be doing something odd. If not, you're in trouble."
Obviously the typical way runners win races isn't by doing something "odd", it's by combining natural talent, normal advice about training, and a ton of effort, more effectively than the other runners. Why would that be less true about successful startups?
We understand how to run faster, through a combination of hard work and favorable morphology. We're don't understand what will make a startup successful. But we do know that easy and obvious ways to make money are already being done by someone else. If you want to do something new, you have to do something different.
But I also appreciate the viewpoint that you need to be strategic about what you do differently. Buying solutions to problems you aren't actually trying to solve is very reasonable.
I lost the first 5-6 years of code thanks to an IBM Deathstar[1] when I was 20.
Got really depressed by it at the time, as it included most of the projects I worked on at the time. After that I got super paranoid about having backups.
I do enjoy going back and looking at the code I still have though. Being self-taught it's mostly not terribly great, but I do have fond memories of finally cracking a certain nut or figuring out some neat trick.
Left all backups at a remote storage facility. Remote storage facility called me one day and said all of your hardware and media has been lost, except for this one [insert oldest most worthless computer of the bunch]. Cue me raging, cursing out this storage facility, threatening to never communicate with them ever again. Finally accepted the fault lied within me. Up until yesterday, I only had redundant storage but no true backups. So I purchased an LTO-5 and now I have two backup sets onsite and a third offsite at my colocation facility.
In this story the remote storage facility was my mom's house shortly before the GFC. The hardware were varying PS/2 computers from 286 to 486s with hard drives of zip files of my QBASIC, TurboPascal, Delphi, and VisualBasic code. The only hardware saved was our first computer, an 8088. All because she didn't want the clutter in the house anymore. No contact, no chance to retrieve said wares.. just poof gone. Gone were the Z80 ASM files of my rendition of PunchOut for the Ti-83+. Can't reference my old writings that I saved in various TXT files on the gazillion 3.5" floppy disks I kept in an old laundry basket. 5.25" floppies of DOS installs, random games, and an ancient version of SCO Unix. Gone.
Mine did vary quite a bit within that period, from BASIC in middle school to some funky selective availability GPS handling prod code. But it's beside the point: I'd love it as memento, no expectation really that said game of snake would end up on Steam.
There may be a security advantage to using a separate non-bypassable network appliance that puts your traffic on Tor, since then it would be much harder to break into a Tails machine and make it leak your location. However, given that it's meant to be easy to use, I think they probably picked the right balance by having the Tor redirecting occur in the same address space as the computing environment.
Aviation safety for FAA airworthiness generally follows SAE ARP4761, which requires risks of Catastrophic severity to have a quantitative failure rate of 10^-9 incidents per hour or less. The Air Force follows MIL-STD 882E, which generally requires risks of Catastrophic severity to have a quantitative failure rate of 10^-6 incidents per hour or less. In short, the military accepts more risk than commercial aviation. That being said, military aircraft usually are also rated to ARP4761 levels of safety so they can fly in US airspace.
