Well, I guess a few that aren't covered in your post would be:

1. Being a good programmer is a lot less important than knowing what to build and how to sell it to people. Too many startups end up focusing too much on the coding side to show off on Reddit/Hacker News/whatever.

2. HTML/CSS/JavaScript being tolerant of errors is a good thing, and made them more accessible to learners. Also, a good product/system should be like that, not fail catastrophically on the slighest mishap.

3. CSS isn't poorly designed, nor too awkward to use for styling. It's just not a programming language, and works very differently.

4. Most small companies can get away with a normal shared hosting account (or a small VPS), and don't need either cloud hosting or dedicated servers.

5. Social login systems are a bad idea. You don't want your site to rely on Facebook/Google/Twitter/GitHub/whatever else

6. Similarly, you don't want other aspects of your site to rely on third party services either. Host your own comments, etc. Large companies aren't your friends.

7. 90% of web/app design is based on following trends rather than usability/what the users want.

8. Self driving cars are a bad idea, as are 'car sharing' setups. Again, you should try and keep as much control over your life as possible.

9. Technical solutions to social problems will be needed, since getting people to cooperate is like herding cats.

Almost all opinions are made from a place of ignorance because nobody's personal experience covers more than a fraction of how a tool can be used.

The result are a ton of opinions that are generally useful but specifically useless. This has a chilling effect on those who might wield a tool differently for their own specific needs.

well yeah, that's why they are called "unpopular opinions" and not "unpopular facts"

If all that stops you from trying a new tool is some crazy guy's ramblings on the internet, you probably weren't going to be effective with that tool anyway

> Cloud services (AWS/GCP/Azure) only make sense for smoothing out unusual/seasonal peaks, or support rapid growth. If you are 100% cloud based, you’re throwing away large money every month.

Absolutely. Lots of loss-making companies out there spend millions on their budget on these services only to help make their providers turn an easy profit.

This is why they continue to beg for more funding rounds in return of less control of their companies and end up still being unprofitable even in their Series X even.

Hi. I'm a novice developer. Could you give me an example of a non cloud based hosting provider please? I'm not sure I understand the point the author makes.

You lease colocated servers at more competitive rates (power and bandwidth included), or buy them and install them in leased racks, or build your own datacenters. Cloud providers charge a lot in return for not requiring this kind of commitment; they have to amortize datacenters and support staff with a lot of spare capacity.

Yes and they also let small shops actually spend their time developing software instead of managing infrastructure. I know how to and have done all of the infrastructure and managed services that we farm off to AWS.

You can get away with a lot less dedicated infrastructure staff if you use your cloud provider as more than just a glorified overpriced colo and actually take advantage of their managed services.

Just to keep comments from going off the rails and everyone says it’s a mistake not to have dedicated “infrastructure people”. I’m a software engineer still by choice, but I have turned down a few offers as an “AWS Architect”.

My thought on that is your rough revenue over infrastructure + development + maintenance cost is what matters. There is google/facecrack in one corner of that problem space and a chain smoking accountant with a ledger in another corner. You are likely not in either of those places.

"Being successful in software is rarely about being able to write clever solutions. It almost always comes down to being able to consistently grind on problems that are repetitive enough to be boring, but unique enough that there isn’t opportunity for abstraction." Care to expand on this, specifically the 'unique enough that there isn’t opportunity for abstraction' part?

I think it's trying to convey that if you can create an abstraction for it you can factorise it and you solve the problem only once, it's not something that you will have to work on again and again. The only stuff we work on is the irreductible, sufficiently new that we can't apply older solutions right away.

Guaranteed to be unpopular: Text-based serialization formats (e.g. XML, JSON) are utterly wasteful of bandwidth, processing power, and memory when used for services with a high request volume and should be dropped in favor of binary protocols.

So many reasons I don't like this, but you raise a fair point

> Cloud services (AWS/GCP/Azure) only make sense for smoothing out unusual/seasonal peaks, or support rapid growth. If you are 100% cloud based, you’re throwing away large money every month.

If all you need is CPU/RAM/Disk/Bandwidth, sure.

My need of AWS/GCP/Azure magical pixie dust is low.

So I'll keep the cheap CPU/Ram/Disk/Bandwidth, thank you.

so, like, 99% of what people are using them for?

I’m curious what you meant by “can’t be trusted to use redux.” What did you mean there?

Redux is simple in concept, but surprisingly confusing for a lot of people. My strong belief is that the Facebook/React team came up with hooks as a more gentle approach to state management so that Redux wasn't the high barrier to entry for React apps