The idea that people use "the cloud" because they're lemmings is absurd, childish ranting. I'm supposed to what, go rack servers the next time I ship a webapp to qualify for this person's standard of free-thought?
You can consider supporting smaller companies that provide VPS or bare-metal servers. Whenever I explored cloud services for hosting an app for a client, I felt like the costs were excessive, the choices are bit harder if you want to support multiple locations but doable.
It would be more credible if he acknowledged and debunked some common reasons people use to justify using CSPs, but this article reads as if he's never heard or thought of anything more substantial than "everyone else is doing it."
He also seems to believe it's a trend that started in 2022 related to COVID lockdowns, but EC2/AWS had been selling like hotcakes for a decade and a half before that.
I wouldn't have been able to build the startup I did starting in 2010 without AWS. Prior to that I had experience in data-centers, and hats off to the people who commoditized them.
I don't think the author means nobody should any of those technologies. The point is many startups/companies are doing things "just because everyone else is doing it" when they could actually be better off not doing it.
This is 99% accurate, and I love that the author can put it plainly.
Note that the effect goes both ways. Companies started offering ridiculous pay package to less-than-qualified people, ... because the others were doing it.
Trend following is a real nasty human aspect, social media platforms know that too well.
It's so much easier to follow what others are doing than buck the trend and have to justify yourself at every corner decision. Remember the old saying "no one ever got fired for picking Oracle". Well today you'll hear me say "no one ever got fired for picking Salesforce".
Today's industry is plagued by a swath of people coming from all industries into the IT industry, because theirs is shrinking, and because money keeps flowing in this one; pure and simple.
No one really knows what the heck we're doing anymore, and everyone is risk adverse, flows down like the river; because it's impossible to justify yourself in large businesses for bucking the trend.
You'll do better if you can somehow buck the trend at the pivotal points, and read between the lines, but I think we're too far gone past the line of reason these days that it would make a difference.
We must be nearing (or at) the top of the "cyber security" or whatever-the-fuck you call it bubble that everyone is scrambling to jump on, get funding for, be acquired, etc. Last week my brother in law (who's 50) breathlessly told me he was starting his new career as a "cyber security analyst" and plunking down $9k for a 20-week course.
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.
I'm surrounded by "opsec experts" (or whatever their name is lately) that keep running daily checks for windows pwned machines, against our servers which are all linux.
Like 4000 tests a day, always returning green charts, looking great on weekly meetings I'm sure.
They've demanded that we drop the WAF for them (WAF still irks me, it implies you don't know what you're running, but that's another day's topic), so that they can "better test our infrastructure".
They're completely oblivious on how a buffer overflow would be executed, and I'm pretty sure they couldn't tell me what the difference is between http2 and http.
I'm really saddened by the fact that this industry just barely runs from one breach to the next, pretending everything is fine, not understanding any of it and slapping on one-click solutions and pen-testing up the wazoo.
For christ sakes I had to correct a report saying our data was stored in a "community", because it's a third party data centre they never heard of.
I'm close to encourage my children not to get into the IT industry...
I find this attitude kind of depressing. When I was in CS undergrad I thought about going into security because it seemed like this thing where you needed a bunch of systems background. To understand some exploits e.g. [0] you'd need hardware-related knowledge like branch prediction and memory hierarchy. Or something like stack smashing you'd need to know the process memory model and maybe some assembly
It seems to me like security is split into two camps: the people who are out there in the wild who find exploits and the "bootcamp" crowd
There is most definitely a split between the people that are "traditionally" trained and understand the underlying layers, vs. the bodies added to a head count, to bolster some agenda.
I for one am actually pretty glad to see the role commoditized. Software's one of few roles where you need the deep theory component (a CS degree) to practice (land a respectable gig). My impression is that this is because we, the software industry, have done a poor job separating the theory from practice.
Much as you hire an electrician, as opposed to an electrical engineer, to wire your house, or a carpenter, rather than a mechanical / structural engineer, to build your house, I do think we should be finding ways to separate "programmer" from "computer scientist". These are both completely legitimate roles, and deserve to be paid according to their value produced - they're both quite high! But the fact that I need a deep understanding of data structures, operating systems, computer architecture, or other college-level concepts to write software feels like a shortcoming. If CS researchers can set standards for software, rather than _write the software itself_, we can more easily create on ramps and shallow ends for people to use.
Low code tools and LLMs are great steps in this regard, but I feel that they're still stigmatized from the enablement perspective.
In the programming realm specifically, following a trend can be foolish and, at the same time, as a bigger community usually means better support, documentation and maintenance, clever. It is bad, but if it was better, it could be worse.
I disagree. Unfortunately there are good and rational reasons to coalesce around standards. Hate k8s all you want, but you hire a new SWE, what are the chances that they know how to work with your bespoke infra vs they used k8s before.
Now - there are decisions to be made around what is really necessary and keeping things simple is often the right choice, but being able to hire people already familiar with thing is not something one can dismiss and say "Lemmings".
Similar things things apply in social aspects. You want to work remotely? Great, me too. But it doesn't change the fact that there is a lot of people who would like to work remotely, and less corporate envs that are comfortable with it (even if for dumb reasons). Which means you'll probably have to be paid less and so and so.
You want to change it? Make your own company, 100% remote and out-compete everyone. Easier said than done, unfortunately.
"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.
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.
> 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.
"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.
It's a game of brinkmanship. My employer said RTO isn't optional but mandatory. What are they gonna do? Fire me? OK. I'll keep WFH until they do then shrug.
Sometimes you should follow the crowd. Sometimes you should forge a different path. Figuring out when to do what is both really hard and really important.
As a -general- rule the things that make you different should be different. The things that support what you do should be common.
For example- I need to commute. Our customers don't care what car i drive, so I choose something reliable (think Toyota not TVR). I need infrastructure to run on, to me it's a commodity, so I pick whatever is convenient.
Our secret sauce is productivity. So we use tools and processes optimized for that. A lot of that is in-house, very bespoke. And we use a language you never heard of because 99% of software companies don't care about productivity.
If you're an employee it makes sense to learn whatever everyone else is learning. There are lots of jobs for c# programmers. But of course the pool of c# programmers is large and ultimately you're a replaceable commodity.
Whereas when you learn a skill which is unfashionable, rare, hard to master and so on, then your employment pool becomes really small, but also really valuable.
For example, you can (and should) learn how to use Windows. But you're not gonna get hired for that (despite every company having it). But become a OpenBSD expert, and only 6 companies are in the market. But they pay a Lot for someone who can add value to them. Becoming an expert in someone's secret sauce pays well, and has great job security, at the cost of job mobility.
Most people of course want to be in the herd. It's safe. It's easy. You eat grass. It's a good life. There's no excitement, but also no way of standing out.
Some want to forge a different path. Carve out a niche. Take advantage of a gap here, an opportunity there. Go with the flow when it doesn't matter.
> Sometimes you should follow the crowd. Sometimes you should forge a different path. Figuring out when to do what is both really hard and really important.
Maybe I am just "on the cool-aide" or something, but I want to believe this is actually a communication issue.
Firstly, I have to assume that people at these senior levels operate in the best interests of the company (at least most of the time). So, feel free to tell me this is my problem :)
With that assumption called out, their action (at least statistically) is expected to have a better outcome for the company. This applies to all decision - Return to office, technology selection, etc.
So, why is this communication - well because the approach for senior leadership is typically still - "Trust us" - rather than "Here is our logic, and know there are other perspectives, but this is what we are doing and to what end". That communication can increase trust in leadership, and even build confidence when done well.
Of course, if/where my assumption is wrong, the author could we right.
As a side note - I have NOT worked for a companies with competent technical competencies in senior leadership in well over 10 years. This typically (almost always) leads to mass blind adoption of the Microsoft stack. And I generally see that pattern and will use it to help select where I go work next.
Maybe you're right. If so, I've only ever worked for companies with leadership that sucked at communicating.
I don't think it's that simple though. My personal belief is that leadership rarely has a good reason for obtuse decisions and following the leader seems more likely. Even if the first company has a good reason that makes sense for them, I'm not convinced the same (or any) reasoning applies to all the followers.
I also believe that the majority of the leadership at companies I've worked for are poor downwards communicators :)
The hiring engines are starting up again. Meta in their recent quarterly report stated they expect to grow hc significantly in coming quarters "we anticipate growth in payroll expenses..." Other companies said similar. I'm seeing recruiters trying to get in touch once more.
The fun part will be the companies that miss this current train and who lay people off in the next 6 months (that was the previous trend dummy!) only to see those people walk into new jobs while they are stuck unable to hire talent.
The author eschews "cargo culting" because it's "antequated" and "inaccurate" and then goes with lemmings!? I guess they are not aware that the lemmings thing is a myth. The actual story is pretty wild: https://www.adfg.alaska.gov/index.cfm?adfg=wildlifenews.view...
I clicked on this because I was hoping it was about the excellent computer game...
>I was going to call this post Cargo Culting but I think the term is inaccurate as much as it is antiquated.
Everybody knows that clocks must be kept ticking, but nobody understands time.
There is no agreement what time it is, what they should show.
Modern clocks go ten times faster than the clocks of the past.
The hands are just decorations, clocks work all the same without them.
>The divided day conspiracy theory claims that clocks used to be used to divife days into shorter time periods. This is supposed to be possible by merely observing a clock. There is no known phyaical mechanism how this could happen.
50 comments
[ 4.3 ms ] story [ 90.2 ms ] threadHe also seems to believe it's a trend that started in 2022 related to COVID lockdowns, but EC2/AWS had been selling like hotcakes for a decade and a half before that.
Note that the effect goes both ways. Companies started offering ridiculous pay package to less-than-qualified people, ... because the others were doing it.
Trend following is a real nasty human aspect, social media platforms know that too well.
It's so much easier to follow what others are doing than buck the trend and have to justify yourself at every corner decision. Remember the old saying "no one ever got fired for picking Oracle". Well today you'll hear me say "no one ever got fired for picking Salesforce".
Today's industry is plagued by a swath of people coming from all industries into the IT industry, because theirs is shrinking, and because money keeps flowing in this one; pure and simple.
No one really knows what the heck we're doing anymore, and everyone is risk adverse, flows down like the river; because it's impossible to justify yourself in large businesses for bucking the trend.
You'll do better if you can somehow buck the trend at the pivotal points, and read between the lines, but I think we're too far gone past the line of reason these days that it would make a difference.
Yup, I'm sure this is going to end well.
Like 4000 tests a day, always returning green charts, looking great on weekly meetings I'm sure.
They've demanded that we drop the WAF for them (WAF still irks me, it implies you don't know what you're running, but that's another day's topic), so that they can "better test our infrastructure".
They're completely oblivious on how a buffer overflow would be executed, and I'm pretty sure they couldn't tell me what the difference is between http2 and http.
I'm really saddened by the fact that this industry just barely runs from one breach to the next, pretending everything is fine, not understanding any of it and slapping on one-click solutions and pen-testing up the wazoo.
For christ sakes I had to correct a report saying our data was stored in a "community", because it's a third party data centre they never heard of.
I'm close to encourage my children not to get into the IT industry...
I find this attitude kind of depressing. When I was in CS undergrad I thought about going into security because it seemed like this thing where you needed a bunch of systems background. To understand some exploits e.g. [0] you'd need hardware-related knowledge like branch prediction and memory hierarchy. Or something like stack smashing you'd need to know the process memory model and maybe some assembly
It seems to me like security is split into two camps: the people who are out there in the wild who find exploits and the "bootcamp" crowd
[0] https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
Much as you hire an electrician, as opposed to an electrical engineer, to wire your house, or a carpenter, rather than a mechanical / structural engineer, to build your house, I do think we should be finding ways to separate "programmer" from "computer scientist". These are both completely legitimate roles, and deserve to be paid according to their value produced - they're both quite high! But the fact that I need a deep understanding of data structures, operating systems, computer architecture, or other college-level concepts to write software feels like a shortcoming. If CS researchers can set standards for software, rather than _write the software itself_, we can more easily create on ramps and shallow ends for people to use.
Low code tools and LLMs are great steps in this regard, but I feel that they're still stigmatized from the enablement perspective.
Life can be very paradoxal at times.
Now - there are decisions to be made around what is really necessary and keeping things simple is often the right choice, but being able to hire people already familiar with thing is not something one can dismiss and say "Lemmings".
Similar things things apply in social aspects. You want to work remotely? Great, me too. But it doesn't change the fact that there is a lot of people who would like to work remotely, and less corporate envs that are comfortable with it (even if for dumb reasons). Which means you'll probably have to be paid less and so and so.
You want to change it? Make your own company, 100% remote and out-compete everyone. Easier said than done, unfortunately.
http://www.paulgraham.com/avg.html
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.
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.
"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?
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.
As a -general- rule the things that make you different should be different. The things that support what you do should be common.
For example- I need to commute. Our customers don't care what car i drive, so I choose something reliable (think Toyota not TVR). I need infrastructure to run on, to me it's a commodity, so I pick whatever is convenient.
Our secret sauce is productivity. So we use tools and processes optimized for that. A lot of that is in-house, very bespoke. And we use a language you never heard of because 99% of software companies don't care about productivity.
If you're an employee it makes sense to learn whatever everyone else is learning. There are lots of jobs for c# programmers. But of course the pool of c# programmers is large and ultimately you're a replaceable commodity.
Whereas when you learn a skill which is unfashionable, rare, hard to master and so on, then your employment pool becomes really small, but also really valuable.
For example, you can (and should) learn how to use Windows. But you're not gonna get hired for that (despite every company having it). But become a OpenBSD expert, and only 6 companies are in the market. But they pay a Lot for someone who can add value to them. Becoming an expert in someone's secret sauce pays well, and has great job security, at the cost of job mobility.
Most people of course want to be in the herd. It's safe. It's easy. You eat grass. It's a good life. There's no excitement, but also no way of standing out.
Some want to forge a different path. Carve out a niche. Take advantage of a gap here, an opportunity there. Go with the flow when it doesn't matter.
Which one ?
We used to call that "management."
Firstly, I have to assume that people at these senior levels operate in the best interests of the company (at least most of the time). So, feel free to tell me this is my problem :)
With that assumption called out, their action (at least statistically) is expected to have a better outcome for the company. This applies to all decision - Return to office, technology selection, etc.
So, why is this communication - well because the approach for senior leadership is typically still - "Trust us" - rather than "Here is our logic, and know there are other perspectives, but this is what we are doing and to what end". That communication can increase trust in leadership, and even build confidence when done well.
Of course, if/where my assumption is wrong, the author could we right.
As a side note - I have NOT worked for a companies with competent technical competencies in senior leadership in well over 10 years. This typically (almost always) leads to mass blind adoption of the Microsoft stack. And I generally see that pattern and will use it to help select where I go work next.
I don't think it's that simple though. My personal belief is that leadership rarely has a good reason for obtuse decisions and following the leader seems more likely. Even if the first company has a good reason that makes sense for them, I'm not convinced the same (or any) reasoning applies to all the followers.
I also believe that the majority of the leadership at companies I've worked for are poor downwards communicators :)
The fun part will be the companies that miss this current train and who lay people off in the next 6 months (that was the previous trend dummy!) only to see those people walk into new jobs while they are stuck unable to hire talent.
I clicked on this because I was hoping it was about the excellent computer game...
Everybody knows that clocks must be kept ticking, but nobody understands time.
There is no agreement what time it is, what they should show.
Modern clocks go ten times faster than the clocks of the past.
The hands are just decorations, clocks work all the same without them.
>The divided day conspiracy theory claims that clocks used to be used to divife days into shorter time periods. This is supposed to be possible by merely observing a clock. There is no known phyaical mechanism how this could happen.