> 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.
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
"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.
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.
> 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.
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
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.
I'm here to defend kale, as someone who finds most leafy vegetables unpalatable. If anything, kale provides formidable contrast and texture in fatty soups, for example, in Olive Garden's Zuppa Toscana.
Or is Kale a devops tool I haven't heard about? It was capitalized in the original post.
Quite the contrary, I rarely if ever use redux now that hooks are out. I think I was more highlighting Facebook's intent when creating them. Abramov (creator of redux) definitely seems to be distancing himself from redux as React as an ecosystem moves forward with Context and Hooks.
I've seen it said that "redux is just money laundering for global variables". Can't say that I disagree
Ah, I see what you mean. Personally I've advocated for something more similar to "React Hooks are redux for devs who know when not to use redux", which is _most_ of the time.
* There's a generation of managers that learned some dev up to Python and now make up stories to justify using Python like "we'll be able to hire a bunch of jr devs and Django will guide them". When they're really just too lazy/incompetent to learn a more modern language.
C, C++, Java, Python and Ruby are inferior to ML, Erlang, Haskell and Lisp. Nobody who has used Lisp and Java seriously believes that Java is the better tool. But the people who know both are drowned out by huge numbers of mediocre devs who think Java is all they need to know.
If you want a quick mvp maybe Ruby is a better tool than using Haskell.
Mediocre means average. If the average developer can solve the problem in java maybe your favorite language isn't needed. The fact that a language has low adoption means it is missing features or late to a crowded market.
> The fact that a language has low adoption means it is missing features or late to a crowded market.
Or it may have the wrong features. It may even have "better" features, but not the right features. (A Formula 1 race car has lots more features than my Toyota Camry. I wouldn't drive it to the office, though. Unsurprisingly, Camrys have higher market share that Formula 1 cars.)
But the F1 racer has far better top speed, better acceleration, better braking, better handling, better collision protection, better aerodynamics (and active aerodynamics), far more internal sensors, telemetry of those sensors, and is far better for impressing girls.
I love Lisp. It is superior language for real devs. But I also recognize that it will never work for newb programmers and the reality of corporate IT is that most devs are newbs or effectively newbs, not spending more time to level up as they think they know everything programming or are just not interested.
For these people, Java, is a way to get paid for writing boiler plate code without getting much done.
Java, in my mind, has a better ecosystem. It is easier to find useful tools and to integrate them into my development environment. There is a larger community of developers who are available to answer questions and there has been much more content written about how to do high quality engineering as a java dev. As a team lead, this makes my job immensely easier because I can point people towards high quality writing. Lisp, by comparison, remains completely niche.
The actual programming language is like the least interesting part of almost all development. It is but a tiny part of the whole system that lets us build and maintain software in teams. There are some people who really want to develop in a specific language. These people tend to lead with "we program in haskell" or "we program in lisp" in their recruiting emails. That's fine for some people but its not interesting to me. I care a lot more about the stuff around the programs.
This is not an original line of argument and in the absence of substance it’s especially unlikely to be more successful than decades of earlier failed iterations. Rather than calling people mediocre it would be far more productive to learn why other people have come to different conclusions about the languages you like.
Sure, but can you imagine those mediocre devs trying to make contributions to a Lisp codebase? I feel much more confident giving them a tool like Java or Go. I mean, Go is the way it is because there are other people who believe that a blunt knife is better in the hands of a clod.
> The hard part about iOS development was never Objective-C but rather the cocoa libraries it has to interact with. Swift just applied a more modern language to the same root problem. For a more modern version of this statement, see SwiftUI
Isn't the big selling point of Swift that you no longer have to worry about null exceptions? Though presumably there could have been a way to improve Objective-C without requiring a new language to add optionals.
Joe seems a little lost. Not really sure what productivity gains react/graphq has over php or ruby/rails. Must have provided one for Joe. PHP with laravel is like a rocketspace for productivity..
> "The big tech companies don’t employ so many engineers because they need them, they do it because they are afraid of being understaffed when the next big paradigm shift happens"
Nope, can't agree with this one. The reasons the big tech companies employ so many engineers is 1) Empire building by senior management to justify their next promotion and 2) said big tech companies are floundering around trying to build something that create the next big paradigm shift, 99.9% of which gets cancelled before ever seeing the light of day or flops miserably in the marketplace if it does. Been there, done that.
47 comments
[ 4.2 ms ] story [ 108 ms ] threadAbsolutely. 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.
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”.
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.
If all you need is CPU/RAM/Disk/Bandwidth, sure.
So I'll keep the cheap CPU/Ram/Disk/Bandwidth, thank you.
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.
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
Or is Kale a devops tool I haven't heard about? It was capitalized in the original post.
Some light olive oil and kosher salt, and it's honestly God's gift to man. I will defend this to death.
I can't imagine this statement coming from someone who doesn't grotesquely overuse Redux.
I've seen it said that "redux is just money laundering for global variables". Can't say that I disagree
This tool is better misses the point.
If you want a quick mvp maybe Ruby is a better tool than using Haskell.
Mediocre means average. If the average developer can solve the problem in java maybe your favorite language isn't needed. The fact that a language has low adoption means it is missing features or late to a crowded market.
Or it may have the wrong features. It may even have "better" features, but not the right features. (A Formula 1 race car has lots more features than my Toyota Camry. I wouldn't drive it to the office, though. Unsurprisingly, Camrys have higher market share that Formula 1 cars.)
Your Camry probably has: 1) cruise control; 2) electric windows; 3) windows!; 4) airbags; 5) air conditioning and heating; 6) indicators; 7) headlights; 8) sound system; 9); 10) quiet exhaust; 11) way better pollution control; 12) way better mileage; 13) seats 5......
Though ride quality would be appalling, and there's nowhere to put the girls.
I love Lisp. It is superior language for real devs. But I also recognize that it will never work for newb programmers and the reality of corporate IT is that most devs are newbs or effectively newbs, not spending more time to level up as they think they know everything programming or are just not interested.
For these people, Java, is a way to get paid for writing boiler plate code without getting much done.
The actual programming language is like the least interesting part of almost all development. It is but a tiny part of the whole system that lets us build and maintain software in teams. There are some people who really want to develop in a specific language. These people tend to lead with "we program in haskell" or "we program in lisp" in their recruiting emails. That's fine for some people but its not interesting to me. I care a lot more about the stuff around the programs.
You could have shared a bit about your background with these languages. What do you know about Erlang, ML, Haskell and Lisp?
Isn't the big selling point of Swift that you no longer have to worry about null exceptions? Though presumably there could have been a way to improve Objective-C without requiring a new language to add optionals.
This can’t be an unpopular opinion. Is there anyone disputing that usability and SEO are the main reasons for increasing site speed?
Nope, can't agree with this one. The reasons the big tech companies employ so many engineers is 1) Empire building by senior management to justify their next promotion and 2) said big tech companies are floundering around trying to build something that create the next big paradigm shift, 99.9% of which gets cancelled before ever seeing the light of day or flops miserably in the marketplace if it does. Been there, done that.