Tech companies are irrational pop cultures(softwarecrisis.dev)
softwarecrisis.dev
Tech companies are irrational pop cultures
https://softwarecrisis.dev/letters/tech-is-a-pop-culture/
188 comments
A large part of the value is not the software, but the knowledge built around the software, and that knowledge must be known and understood by someone (the developers). This includes everything from domain knowledge, the history of why things are the way they are, what failed and what succeeded, the technical idiosyncrasies, etc. The software is in a sense secondary, certainly secondary to business goals as its entire purpose is to serve business goals. Software is a means and an instrument, not an end.
But perverse incentives make churn attractive. Switching jobs is often the best way to raise your income, for example.
But perverse incentives make churn attractive. Switching jobs is often the best way to raise your income, for example.
Now we have to take this argument and explain it to people wanting to get rid of developers and use low code or chat gpt.
Who will operate the low code and chat gpt though ? It's not clear to me at all that the humans can be totally skipped in the near future. Maybe reduce their headcount but even that one is debatable (if devs become more productive they will get more tasks, create more companies etc).
I just tell them to go right ahead.
Churn is worse now that we have split everything into microservices that often use their own libraries, frameworks and languages.
That adds a lot of overhead when employees inherit a pet project
That adds a lot of overhead when employees inherit a pet project
I feel like microservices are specifically chosen because they work best with lots of churn. You can throw away the code. You only need to learn only the code in your service. It is an architecture (often) chose not for it's technical merits but rather how it works in high-churn environments.
The same exact results can be yielded by OOP interfaces and implementations, so I unfortunately don't feel this is a valid argument for microservices.
The point for "microservices" to me is to separate the components of an integrated system to achieve scaling factors independent of other related but not directly coupled parts of the system.
Most systems in my experience don't really benefit from separation of the entire application domain into a set of independent systems. Most use cases don't benefit from decoupling a request/response in a series of asynchronous calls across 20 different APIs.
So, most systems can and should be implemented as a simple abstracted interface inside a single application stack. But then, no one ever gets promoted/hired/funded to build the most optimal solution.
Most systems in my experience don't really benefit from separation of the entire application domain into a set of independent systems. Most use cases don't benefit from decoupling a request/response in a series of asynchronous calls across 20 different APIs.
So, most systems can and should be implemented as a simple abstracted interface inside a single application stack. But then, no one ever gets promoted/hired/funded to build the most optimal solution.
> The same exact results can be yielded by OOP interfaces and implementations, so I unfortunately don't feel this is a valid argument for microservices.
I'm not sure about this, there's so much going on in most software, a lot of the ruin comes from the dependencies around your code, like libraries and frameworks. Let's take web development as an example.
Suppose you need to query the database in some legacy project - well, it doesn't have a framework that supports proper logging of each query/parameter for debugging, it doesn't have any codegen capabilities, it has a wonky connection pool implementation. And yet, if you want to work within the same codebase, you have to use it. What could take a bit of codegen and an hour of work now can take close to a day, all because you're pigeonholed into using what's already there for "consistency".
Suppose instead you now want to have a task queue. Well, instead of RabbitMQ or something of the like being used, instead you have to work with what's present - a bunch of pre-existing abstractions and a DB centric implementation (with arguably poor documentation) that the business requirements have largely outgrown, so now you'll need to hack around the existing code, hope that you break nothing there, all while attempting to create something passable (which may or may not be viable with this approach, depending on the use case).
And doing logging? Well, maybe the team didn't do structured logging or log shipping, so you have to be very frugal with the logs, or spend time setting up Logrotate or an alternative for that monolithic app, just so you can turn on some additional logging and make sure that the eventual rollout actually works.
Well, what about the actual database or maybe tests? Be prepared that the test framework will be somewhat out of date, some of the test utilities won't quite fit what you'll try to do and perhaps your current ORM and DB choices won't really work well with the idea of letting integration tests test actual DB statements and migrations against a DB instance that would be setup for the tests and torn down automatically afterwards (say, a PostgreSQL/MariaDB container somewhere, as opposed to MS SQL or Oracle), so you won't be able to test every schema migration that easily.
You might even run into a situation where you need to run a relatively recent runtime (say JDK 11) but the project is stuck on an older release (JDK 8), whereas migrating everything isn't going to be done for now. So you can't do what you need now, because the libraries don't support your runtime. Worse yet if the monolithic project has dozens of business use cases, whereas the bit of code that's preventing the migration is needed for just one or two of them.
I won't even get into instrumentation and scaling parts of the total solution up or down, or things like configuration, since that'd make this needlessly long.
I think that microservices indeed are a good choice for mitigating some of these issues, by untying your hands - the impact of issues is lessened, to a per-service basis. An individual service might therefore rot and this rot could be addressed separately, without slowing everything else down. Even to the point where the old implementation can be thrown out and rewritten, if that's ever needed.
However, microservices come at a possibly huge operational and complexity cost otherwise, to the point where they might either make the project late, hard to work with, or unfeasible altogether. And it's hard to know which approach will be the best for any given situation. Starting out with monoliths makes sense, because most smaller projects will never need to be split up, but when you need to do that, you will really need to. Modular monoliths (e.g. feature flags for enabled/disabled bits of functionality) can be an intermediate step.
In an ideal world, programming language module systems would be enough. We don't live in a perfect world.
I'm not sure about this, there's so much going on in most software, a lot of the ruin comes from the dependencies around your code, like libraries and frameworks. Let's take web development as an example.
Suppose you need to query the database in some legacy project - well, it doesn't have a framework that supports proper logging of each query/parameter for debugging, it doesn't have any codegen capabilities, it has a wonky connection pool implementation. And yet, if you want to work within the same codebase, you have to use it. What could take a bit of codegen and an hour of work now can take close to a day, all because you're pigeonholed into using what's already there for "consistency".
Suppose instead you now want to have a task queue. Well, instead of RabbitMQ or something of the like being used, instead you have to work with what's present - a bunch of pre-existing abstractions and a DB centric implementation (with arguably poor documentation) that the business requirements have largely outgrown, so now you'll need to hack around the existing code, hope that you break nothing there, all while attempting to create something passable (which may or may not be viable with this approach, depending on the use case).
And doing logging? Well, maybe the team didn't do structured logging or log shipping, so you have to be very frugal with the logs, or spend time setting up Logrotate or an alternative for that monolithic app, just so you can turn on some additional logging and make sure that the eventual rollout actually works.
Well, what about the actual database or maybe tests? Be prepared that the test framework will be somewhat out of date, some of the test utilities won't quite fit what you'll try to do and perhaps your current ORM and DB choices won't really work well with the idea of letting integration tests test actual DB statements and migrations against a DB instance that would be setup for the tests and torn down automatically afterwards (say, a PostgreSQL/MariaDB container somewhere, as opposed to MS SQL or Oracle), so you won't be able to test every schema migration that easily.
You might even run into a situation where you need to run a relatively recent runtime (say JDK 11) but the project is stuck on an older release (JDK 8), whereas migrating everything isn't going to be done for now. So you can't do what you need now, because the libraries don't support your runtime. Worse yet if the monolithic project has dozens of business use cases, whereas the bit of code that's preventing the migration is needed for just one or two of them.
I won't even get into instrumentation and scaling parts of the total solution up or down, or things like configuration, since that'd make this needlessly long.
I think that microservices indeed are a good choice for mitigating some of these issues, by untying your hands - the impact of issues is lessened, to a per-service basis. An individual service might therefore rot and this rot could be addressed separately, without slowing everything else down. Even to the point where the old implementation can be thrown out and rewritten, if that's ever needed.
However, microservices come at a possibly huge operational and complexity cost otherwise, to the point where they might either make the project late, hard to work with, or unfeasible altogether. And it's hard to know which approach will be the best for any given situation. Starting out with monoliths makes sense, because most smaller projects will never need to be split up, but when you need to do that, you will really need to. Modular monoliths (e.g. feature flags for enabled/disabled bits of functionality) can be an intermediate step.
In an ideal world, programming language module systems would be enough. We don't live in a perfect world.
Really true, ownership is a huge part of microservices. I have been on teams that have adopted orphaned services, then been called into meetings to advise on use of a service I am barely aware of.
It is a really easy way to make your employees overwhelmed, but you can always hire someone else to take ownership once they quit.
It is a really easy way to make your employees overwhelmed, but you can always hire someone else to take ownership once they quit.
One idea of Micro services is that you can rewrite the entire service. There are more combinations of libraries, frameworks and languages then there are programmers. Most programmers however has a favourite stack that they are 10x more productive in.
Unpredictable churn from layoffs is probably bad, but I view churn in general as an almost necessary thing for software dev. Every great thing I've done on a SWE team has been something the previous person in my position wouldn't do, and every bad thing I've done was redone by someone after me. The truly well-designed and maintainable systems survive multiple owners, so there's a trend towards better. And it's a bad sign for a system to rely on someone.
That's a great essay, thank you. I have been thinking this exact same thing for over a year now, it's nice to see it written out so clearly.
He paraphrases a classic paper by Peter Naur which is worth reading in its entirety.
on the other hand, there's a strong incentive for group-organizations, specially profit-driven and "the show MUST go on" kinds of organizations to never depend on a single (or a small sub-group) of people to keep things going; lest somebody important gets hit by the proverbial bus.
IMO, this is also part of the challenges that come with dealing in software (understood as some sort of novel "substance"); in great part we (as a culture/civilization) haven't figured out how to deal with software (and in general, with digital artifacts) in the best way.
IMO, this is also part of the challenges that come with dealing in software (understood as some sort of novel "substance"); in great part we (as a culture/civilization) haven't figured out how to deal with software (and in general, with digital artifacts) in the best way.
Preventing people from being productive by fear of the bus factor, is like throwing them yourself under the bus.
Well, it's how business works. Maximal productivity of individual developers is not necessarily as valuable to the business as consistent forward progress that's resilient to risks, especially human risks like cranky developers quitting.
As much as Office Space is supposed to be a pastiche of corporate toxicity, Initech was perhaps more honest than most real-world companies. They had banners everywhere reading "Is it good for the COMPANY?" In the real world the same principle applies but you have to keep it in mind yourself. Any time corporate makes a decision which you think of as foolish because it hampers or disadvantages the line workers, ask yourself... Is it good for the COMPANY?
As much as Office Space is supposed to be a pastiche of corporate toxicity, Initech was perhaps more honest than most real-world companies. They had banners everywhere reading "Is it good for the COMPANY?" In the real world the same principle applies but you have to keep it in mind yourself. Any time corporate makes a decision which you think of as foolish because it hampers or disadvantages the line workers, ask yourself... Is it good for the COMPANY?
is this on the wrong article... if so please delete
The quote I quoted is quoted at the end of the very short OP, I took it from there.
> The symptoms of pop culture: A “disdain for history”. Pop cultures believe history doesn’t have anything to teach them.
This almost completely falls to pieces in the framing ... how does one explain the pop culture of 80s nostalgia that is prevalent in a lot of media? An 80's casio watch is, in some circles, the pinacle of timepiece fashion. Of course there are times where pop culture is a rejection of the prior art, but also there are times when current pop culture icons show deference to the past and their influences.
This almost completely falls to pieces in the framing ... how does one explain the pop culture of 80s nostalgia that is prevalent in a lot of media? An 80's casio watch is, in some circles, the pinacle of timepiece fashion. Of course there are times where pop culture is a rejection of the prior art, but also there are times when current pop culture icons show deference to the past and their influences.
Casio watches are not 'cool' because they are useful and cheap as they always were - they are fetishized as a 'fashion'.
If we were all just 'wearing them because they made sense' then yes, but they are specifically objectified as thing of adornment. It's mostly not about the past.
That guy who is still wearing the Casio because he always 'just did' - that's not pop culture.
There's nothing wrong with pop culture and it has many positive attributes, change is needed. It'd be boring without change. That said it can obviously be carried away.
Pruning is also healthy for the org in many ways, especially if it allows for adaptation and change. It obviously has some negative externalizations for individuals which is not nice.
If we were all just 'wearing them because they made sense' then yes, but they are specifically objectified as thing of adornment. It's mostly not about the past.
That guy who is still wearing the Casio because he always 'just did' - that's not pop culture.
There's nothing wrong with pop culture and it has many positive attributes, change is needed. It'd be boring without change. That said it can obviously be carried away.
Pruning is also healthy for the org in many ways, especially if it allows for adaptation and change. It obviously has some negative externalizations for individuals which is not nice.
The persistent retro mimicry across decades is just an exercise in stereotyping, not born out of any appreciation for history. A Casio in the 80s was cutting edge consumer tech in a sense. A Casio watch today has a totally different vibe.
Beside the mimicry there's also a lack of "cultural tension" (as in physical force). A simple thing in the 80s was a magical item from a lot of new ideas and new efforts. Today there's such a gluttony of capabilities that you're drowning and can't feel anything. It's like x-ray.. new improvements happen so fast, they go through you.. with either extremely high emotional response (iphone waiting lines) or very mild one (renew your flagship from 2 years ago). Same goes for music IMO.. people are looking at the past because today's culture is lacking. Some of it is from my generation nostalgia, but a lot of it isn't, I was very surprised to see new filters to imitate VHS tapes or CRT screens being used in new youtube videos, even though everything sold is about 4K, 120fps and whatever.
There's also an anthropological aspect about this.. watching 70s videos, with lots of glare, or halos, probably limitations of optics/film .. but giving some pretty aesthetics. Having more physically correct capture of an event doesn't improve that aspect. People are romantics.
There's also an anthropological aspect about this.. watching 70s videos, with lots of glare, or halos, probably limitations of optics/film .. but giving some pretty aesthetics. Having more physically correct capture of an event doesn't improve that aspect. People are romantics.
It's like Synthwave, which was never a thing in the 80s.
It's a modern reinvention of how people assume the 80s felt, filtered through a gauzy haze of nostalgia for an imaginary pop culture that never existed in that form.
Which is similar to computing and other tech nostalgia. An Amiga was out there on the edge in the 80s, now it's a source of fond reminiscence. Likewise 1980s music equipment, especially synthesizers.
The modern anti-pop-culture equivalent would be asking what's out on the edge today. And there isn't much, because the vibe of computing - actually the vibe of everything - has changed from excited exploration and boundary breaking with constant invention and surprises, to backward-looking and derivative commoditised corporate consumption and collectorism, and the generation of content and items for same.
The most innovative thing at the moment - AI - is an evolving set of automated systems for summarising what has already been generated, rather than for generating something completely new from out of left field.
It's a modern reinvention of how people assume the 80s felt, filtered through a gauzy haze of nostalgia for an imaginary pop culture that never existed in that form.
Which is similar to computing and other tech nostalgia. An Amiga was out there on the edge in the 80s, now it's a source of fond reminiscence. Likewise 1980s music equipment, especially synthesizers.
The modern anti-pop-culture equivalent would be asking what's out on the edge today. And there isn't much, because the vibe of computing - actually the vibe of everything - has changed from excited exploration and boundary breaking with constant invention and surprises, to backward-looking and derivative commoditised corporate consumption and collectorism, and the generation of content and items for same.
The most innovative thing at the moment - AI - is an evolving set of automated systems for summarising what has already been generated, rather than for generating something completely new from out of left field.
> It's like Synthwave, which was never a thing in the 80s.
> It's a modern reinvention of how people assume the 80s felt, filtered through a gauzy haze of nostalgia for an imaginary pop culture that never existed in that form.
Not really. I write Synthwave music, and I was alive in the 80s and writing similar music back then. I have a deep respect for the bands that pioneered the way via New Wave and Industrial music at the time. I really enjoyed at the time and still enjoy things like the incidental music in Miami Vice, for example. (And Jan Hammer, who wrote much of it, has an interesting history going back to Mahavishnu Orchestra, for example.)
It sounds like your own experience is different than that, but don't assume everyone who's into something are into it for naive reasons.
> It's a modern reinvention of how people assume the 80s felt, filtered through a gauzy haze of nostalgia for an imaginary pop culture that never existed in that form.
Not really. I write Synthwave music, and I was alive in the 80s and writing similar music back then. I have a deep respect for the bands that pioneered the way via New Wave and Industrial music at the time. I really enjoyed at the time and still enjoy things like the incidental music in Miami Vice, for example. (And Jan Hammer, who wrote much of it, has an interesting history going back to Mahavishnu Orchestra, for example.)
It sounds like your own experience is different than that, but don't assume everyone who's into something are into it for naive reasons.
The Amiga is such a perfect example. I grew up in the 80s in a software engineering household and all my parents friends were likewise engineers in the computer industry. So I grew up and ended up in the industry too.
I was around lots and lots of different computers that were not common in the 80s due to being a "tailgate" kid into facilities. And yet I've still never seen an Amiga in person I think, and I have never had a "IRL" friend who ever had one either.
And yet you'd think from nostalgia that we all had them in the 80s.
I was around lots and lots of different computers that were not common in the 80s due to being a "tailgate" kid into facilities. And yet I've still never seen an Amiga in person I think, and I have never had a "IRL" friend who ever had one either.
And yet you'd think from nostalgia that we all had them in the 80s.
(in the style of manya, Seinfeld's elderly relation): I had an Amiga!
Copy the image of versus incorporate the essence of.
We wear a Casio because it looks retro, but we check our phones for the time. We have a cassette player in our house, but we use a Bluetooth cassette to play MP3s on it. We put a 3D-printed Sony Walkman phone case around our iPhones instead of digging out the real thing and enjoying the original media with all its perks and problems.
I would use tea as an example. We can drink a modern aluminum can of iced tea that contains 50 ingredients, none of which is tea, or we can take it slow and do a complete traditional tea ritual. One is loosely inspired by the past, the other is immersing yourself in tradition.
The floppy disk save icon comes to mind.
We wear a Casio because it looks retro, but we check our phones for the time. We have a cassette player in our house, but we use a Bluetooth cassette to play MP3s on it. We put a 3D-printed Sony Walkman phone case around our iPhones instead of digging out the real thing and enjoying the original media with all its perks and problems.
I would use tea as an example. We can drink a modern aluminum can of iced tea that contains 50 ingredients, none of which is tea, or we can take it slow and do a complete traditional tea ritual. One is loosely inspired by the past, the other is immersing yourself in tradition.
The floppy disk save icon comes to mind.
Curious what icon you would replace it with
Nostalgia is not always negative, and I didn't mean to imply that it needs to be replaced. Everyone knows that the icon stands for "Save" even if they don't know where it came from.
In a recent tweet from Japan, younger people wonder why the "Save" button in Excel is a vending machine with a drink in the tray. Another popular tweet shows a child wondering why their parents 3D printed a save button. In both cases, they understood the icon stood for save without knowing what it was.
As for your question, I would either use a circle with an arrow in it or an open box with an arrow in it. Perhaps a cloud with an arrow if it's saving to the cloud. Another alternative is a bookmark style icon (but then you need to ask: will the future generations experience physical books at all?)
However, I'm not a UI/UX expert, and this might clash with the Download button, so you'd have to ask whether or not the distinction is important in your own application. Keeping the convention of a mysterious floppy disk might still be the right choice.
In a recent tweet from Japan, younger people wonder why the "Save" button in Excel is a vending machine with a drink in the tray. Another popular tweet shows a child wondering why their parents 3D printed a save button. In both cases, they understood the icon stood for save without knowing what it was.
As for your question, I would either use a circle with an arrow in it or an open box with an arrow in it. Perhaps a cloud with an arrow if it's saving to the cloud. Another alternative is a bookmark style icon (but then you need to ask: will the future generations experience physical books at all?)
However, I'm not a UI/UX expert, and this might clash with the Download button, so you'd have to ask whether or not the distinction is important in your own application. Keeping the convention of a mysterious floppy disk might still be the right choice.
Superficial imitation is not the same thing as deep understanding. Nostalgia for the past isn't the same as respect for the lessons that it can teach us. A real understanding of history is one that can teach you something important about the present.
>how does one explain the pop culture of 80s nostalgia
The fact that people who were teens in this era are a desirable market segment with a lot of purchasing power, and nostalgia works. If it were anything about the actual historical value, then the 80s references would last. But they won't.
Before the 80s nostalgia it was "That 70s Show."
Prior to that, it was "The Wonder Years" (set in the late 1960s/early 70s)
And before that, it was "Happy Days" (50s/early 60s).
It's all a cash grab, plucking on the heart strings of the people who were at the apex of their earning power.
The fact that people who were teens in this era are a desirable market segment with a lot of purchasing power, and nostalgia works. If it were anything about the actual historical value, then the 80s references would last. But they won't.
Before the 80s nostalgia it was "That 70s Show."
Prior to that, it was "The Wonder Years" (set in the late 1960s/early 70s)
And before that, it was "Happy Days" (50s/early 60s).
It's all a cash grab, plucking on the heart strings of the people who were at the apex of their earning power.
Calling 40 years ago “history” is actually “disdain for history”.
History is not what you can find at an older cousin's place. History is what someone had to make an effort to save for you, and you cannot experience it any more.
History is not what you can find at an older cousin's place. History is what someone had to make an effort to save for you, and you cannot experience it any more.
When I was in 8th grade in 2007 our history book ended with a chapter on 9/11. History is the past and even history forums tend to say anything more than a generation ago is history.
There is a lot that occurred 40 years ago that can no longer be experienced, or even known by anyone today. Wouldn't refusing to call it history be disdain for history?
The whole 'history repeats itself' really rang true to me when I was reading on the birth of the roman empire, about when the republic fell (not the last decade, the full history) and I realized much of what we see happening in American politics is not new. The big outrageous personalities, the moral pleas, the manipulation of public opinion, the principled vs the pragmatic. All of that resonates across the centuries.
But, alas, as they say... those who don't know history are condemned to repeat, while those who know are condemned to watch other repeating it.
But, alas, as they say... those who don't know history are condemned to repeat, while those who know are condemned to watch other repeating it.
Some writing on why the US and Rome are completely different:
https://old.reddit.com/r/AskHistorians/comments/19mi71/how_v...
https://old.reddit.com/r/AskHistorians/comments/1ir3jm/in_wh...
https://old.reddit.com/r/AskHistorians/comments/19mi71/how_v...
https://old.reddit.com/r/AskHistorians/comments/1ir3jm/in_wh...
The fact that they are completely different contexts, yet we can see patterns in behavior repeating themselves, is what makes this interesting.
Not really. As said in those posts, just because there are superficial ostensible patterns does not mean that they are useful, or even real.
These posts are disabusing people of the notion that The American Empire shall follow because omens were foreseen. I am obviously not saying that. I took care to single out the personality traits and behaviors I was comparing. It's an aesthetic exercise and not at all similar to prognosticating modern politics bases on ancient history.
What are you trying to accomplish?
What are you trying to accomplish?
The sad story of the Gracchi brothers is often considered a turning point in the republic because it "normalized" violence as a political tool. What followed were proscriptions, the Catilinarian conspiracy, civil wars.
I don't think we're there yet, but the last several years have made me a little more nervous. Are we close to groups of people resorting to political assassinations and if so, will it become normalized?
I actually think more about what Donald Kagan said about tyrannies (a tyrant is just someone who seizes power extra-constitutionally): they generally don't last more than three generations. That led me to compare with democracies, and I can't think of many much older than a couple centuries (though I'm claiming no erudition here).
I don't think we're there yet, but the last several years have made me a little more nervous. Are we close to groups of people resorting to political assassinations and if so, will it become normalized?
I actually think more about what Donald Kagan said about tyrannies (a tyrant is just someone who seizes power extra-constitutionally): they generally don't last more than three generations. That led me to compare with democracies, and I can't think of many much older than a couple centuries (though I'm claiming no erudition here).
I'm wary of 'turning points' analysis in history. Roman society was exceedingly violent by modern standards. For a long while that violence could be channeled towards conquest. The power military leaders derived from this process and the diminishing returns after most prosperous neighboring polities had been absorbed contributed to erode the internal social order of the Republic. But those are centuries long processes, and it didn't 'turn' on this or that remarkable event we have records of.
We shouldn't prognosticate American politics based on the History of Ancient Rome, that is folly. One thing is to observe parallels and patterns in behavior. But entirely different systems and contexts cannot be used to analyze one another by cherry picking.
We shouldn't prognosticate American politics based on the History of Ancient Rome, that is folly. One thing is to observe parallels and patterns in behavior. But entirely different systems and contexts cannot be used to analyze one another by cherry picking.
My main purpose was to point out that even with a facile comparison, we are missing a very salient element (normalization of violence as a political tool).
For the rest, I really should have just said "signal event". I wasn't suggesting anything along the lines of "but for that event things would have gone the other way". Here, I merely meant a threshold was passed.
Personally, I'm more interested in cultural comparisons, mainly because they were so different from us in many ways. And, if I may add to your concern about cherry-picking, we should also have a great deal of humility about how much we really know. What's the metaphor? The ancient world is Versailles, and everything we know about it is what we can see through the keyhole on the front door.
For the rest, I really should have just said "signal event". I wasn't suggesting anything along the lines of "but for that event things would have gone the other way". Here, I merely meant a threshold was passed.
Personally, I'm more interested in cultural comparisons, mainly because they were so different from us in many ways. And, if I may add to your concern about cherry-picking, we should also have a great deal of humility about how much we really know. What's the metaphor? The ancient world is Versailles, and everything we know about it is what we can see through the keyhole on the front door.
I question the implication of this common assertion - how does knowing history change the repetitive nature and outcomes of human systems?
I recently had a conversation with an archeologist. She said that she regularly gets calls from the local government because they're out digging up some ground and have found items that are around 50 years old. Apparently that's the legal cutoff, and they're required to get it checked out by an archeologist if they think it's that age or older. So yeah, history is definitely in that range.
Here is a perfectly preserved sony walkman from 1987 - maximum effort and all.
https://collections.vam.ac.uk/item/O315300/walkman-personal-...
https://collections.vam.ac.uk/item/O315300/walkman-personal-...
History is simply what we chose to remember and how we remember it. There's no minimum length it needs to be in the past. A "historical moment" can happen in the present.
I think it's better to treat the author's definition as separate from the traditional understanding of pop culture. It seems like they really want to talk about an idea they have and are assigning a new definition to an old term.
I'm old enough to have seen this as a fashion trend unto itself.
If you go back and watch TV shows from the 80s, you'll see a lot of 50s nostalgia.
In the 90s, it was the 60s that was being fetishized. They even brought back Woodstock, twice. I was in high school in the 90s and "hippie fashion" was very popular. Tie dyed shirts came back etc.
In the 2000s the 70s were in. We had TV shows like That 70s Show etc.
Then it was the 80s, and now 90s nostalgia is starting to come in.
It's the cycle of aging. All the kids and teenagers from those decades are now middle aged and they want to consume nostalgia. If they had kids in their 20s, then those kids are now teenagers and young adults and are becoming curious about their parents lived experiences and all the things that they just missed out on (during the 00s I was very interested in the 70s since that decade happened right before I was born).
But this is a specific exception, not the rule. Middle aged consumers are not the trend-setting hipsters who create new fashion trends (the stuff that they will fetishize when they are middle age).
What's really ironic, though, is that in tech there really isn't much that is new. Even AI/ML was being researched as far back as the 1940s, we had working proof of concepts in the 80s. We knew how to do this stuff ages ago, and had practical applications. We just needed the hardware and data accessibility to catch up so that we have the storage and computing to actually train these things. Every advancement over the last 20 years has been small incremental refinements. The big stuff is not new.
But the industry still fetishizes it like it's new.
"Cloud" is just resource sharing. We're back to mainframes, complete with the vendor lock-in caused by proprietary APIs. And yet it is branded, marketed and fetishized as if it's "new."
OOP is soooo passe. We tried that in the 90s and 00s and there were ... gasp... problems! People wrote buggy and difficult to maintain code. Enter Functional Programming and now this is the way that we do things. It's impossible to write bad code in this paradigm ... right?!
Relational databases are slow and complicated and require DBAs to maintain. In comes NoSQL and key/value doc-stores ... now THIS is the way we do things. You can't develop a bad product using a doc store database ... right?!
Restful APIs require strong collaboration between backend and frontend developers and simple, single-purpose contracts aren't very flexible. In comes GraphQL now ALL web apps need to use it because you can't develop a difficult to maintain application using GraphQL .. .right!?
This is the point of the article and after 25 years in the industry I have a hard time finding the lie.
If you go back and watch TV shows from the 80s, you'll see a lot of 50s nostalgia.
In the 90s, it was the 60s that was being fetishized. They even brought back Woodstock, twice. I was in high school in the 90s and "hippie fashion" was very popular. Tie dyed shirts came back etc.
In the 2000s the 70s were in. We had TV shows like That 70s Show etc.
Then it was the 80s, and now 90s nostalgia is starting to come in.
It's the cycle of aging. All the kids and teenagers from those decades are now middle aged and they want to consume nostalgia. If they had kids in their 20s, then those kids are now teenagers and young adults and are becoming curious about their parents lived experiences and all the things that they just missed out on (during the 00s I was very interested in the 70s since that decade happened right before I was born).
But this is a specific exception, not the rule. Middle aged consumers are not the trend-setting hipsters who create new fashion trends (the stuff that they will fetishize when they are middle age).
What's really ironic, though, is that in tech there really isn't much that is new. Even AI/ML was being researched as far back as the 1940s, we had working proof of concepts in the 80s. We knew how to do this stuff ages ago, and had practical applications. We just needed the hardware and data accessibility to catch up so that we have the storage and computing to actually train these things. Every advancement over the last 20 years has been small incremental refinements. The big stuff is not new.
But the industry still fetishizes it like it's new.
"Cloud" is just resource sharing. We're back to mainframes, complete with the vendor lock-in caused by proprietary APIs. And yet it is branded, marketed and fetishized as if it's "new."
OOP is soooo passe. We tried that in the 90s and 00s and there were ... gasp... problems! People wrote buggy and difficult to maintain code. Enter Functional Programming and now this is the way that we do things. It's impossible to write bad code in this paradigm ... right?!
Relational databases are slow and complicated and require DBAs to maintain. In comes NoSQL and key/value doc-stores ... now THIS is the way we do things. You can't develop a bad product using a doc store database ... right?!
Restful APIs require strong collaboration between backend and frontend developers and simple, single-purpose contracts aren't very flexible. In comes GraphQL now ALL web apps need to use it because you can't develop a difficult to maintain application using GraphQL .. .right!?
This is the point of the article and after 25 years in the industry I have a hard time finding the lie.
That's retro fashion.
I doubt that most wearers think the Casio is the superior watch compared to nowadays smartwatches
I doubt that most wearers think the Casio is the superior watch compared to nowadays smartwatches
It has a better battery, the little solar panel thing means I dont need to put it on a magnet every night. It keeps the time just as well. The metal band is the same one that a premium smart watch comes with, and it also comes with an smart advanced "notifications off" setting - such that it is litterally impossible to get an errant notificaion in the middle of an important meeting.
Usually, pop culture means for young people. 80s nostalgia is for people born in the 70s.
I mean Taylor Swift had an album that was titled 1989 (the year she was born), and you can pretty much draw a straight line from Toni Basil's rendition of "Oh Mickey" to "Shake It Off". I think her audience tends to be fairly young, and they ate it up.
Taylor Swift reused an all-around decent sounding genre that wasn't overdone in the 2010s, with some changes for modern times. It's not the nostalgia that sells it. The majority of actual 1980s pop music would probably rarely be replayed today, just some hits survive.
You might find the biggest divide asking gen Z vs millennials what they think about the movie reboots. A few of those are done well and have their own merits, but most rely totally on the nostalgia factor.
You might find the biggest divide asking gen Z vs millennials what they think about the movie reboots. A few of those are done well and have their own merits, but most rely totally on the nostalgia factor.
Not necessarily. There are movements for 90s nostalgia from people who did not exist in the 90s. It's a sort of fake or retrograde nostalgia, possibly from seeing their parents.
Respecting the aesthetics of history is not the same thing as having respect for history
I think some programmers need to hear the advice "don't assume that newer is necessarily better", and others need to hear "don't dismiss new things as being created by a cascade of attention-deficit teenagers".
Maybe the author of this article is meeting more of the first kind, but it's dangerous to issue advice that amounts to "wherever you are on this balance, move further East".
Maybe the author of this article is meeting more of the first kind, but it's dangerous to issue advice that amounts to "wherever you are on this balance, move further East".
This article has a broad title but focuses on layoffs. I've seen the theory thrown around that it's a form of big tech collusion: They can't collude openly, but if one huge player makes a move like layoffs, it sends a signal to the others. Pandemic and work-from-home gave employees a lot more bargaining power, with the ability to get competing job offers without leaving their desks, so companies want to take that back.
I don't see enough evidence to call it, but I wouldn't put it past them, given how several big players including AAPL and GOOG were caught and fined for making no-cold-call agreements several years ago. And it does seem like the tech scene has been less competitive lately on the consumer side.
I don't see enough evidence to call it, but I wouldn't put it past them, given how several big players including AAPL and GOOG were caught and fined for making no-cold-call agreements several years ago. And it does seem like the tech scene has been less competitive lately on the consumer side.
This article echoes a few of my most unpopular opinions.
* The current generation could not invent the internet. They don't have the attention span or the culture for it.
* People who spurn well thought out technologies like SQL or relational databases, are doomed to re-invent them, badly.
* The current generation could not invent the internet. They don't have the attention span or the culture for it.
* People who spurn well thought out technologies like SQL or relational databases, are doomed to re-invent them, badly.
Please don't forget that every accusation lobbied at the next generation is an implicit admission that the previous generation created an unsuitable environment for raising children. Or that those people were failures as parents individually.
Or you could just not make broad generalizations about different generations. Which is preferable.
Or you could just not make broad generalizations about different generations. Which is preferable.
I think you're making a good point in general, but in this case I think we arguably did create an unsuitable environment for raising children, first with television and then the Internet itself.
I don't blame anyone, every step down this path has seemed like a good idea at the time, eh?
I don't blame anyone, every step down this path has seemed like a good idea at the time, eh?
> The current generation could not invent the internet. They don't have the attention span or the culture for it.
You vastly underestimate how much thought went into the internet. Look at:
- TCP delayed acks + Nagle’s algorithm
- IPv4 address size (Vincent said 32-bits was roughly as likely as 24 or 48).
- the 7 layer OSI
- class-based (A, B, C, …) routing
- most of the options in IPv4 headers
The Internet was as much hacks and a playground as other layers of the stack are today. The good stuff is still in use but there is a vast graveyard of bad ideas that didn’t pan out because they were security nightmares, couldn’t scale, etc.
The same applies to core protocols like BGP. BGP hijacking is still possible today.
You vastly underestimate how much thought went into the internet. Look at:
- TCP delayed acks + Nagle’s algorithm
- IPv4 address size (Vincent said 32-bits was roughly as likely as 24 or 48).
- the 7 layer OSI
- class-based (A, B, C, …) routing
- most of the options in IPv4 headers
The Internet was as much hacks and a playground as other layers of the stack are today. The good stuff is still in use but there is a vast graveyard of bad ideas that didn’t pan out because they were security nightmares, couldn’t scale, etc.
The same applies to core protocols like BGP. BGP hijacking is still possible today.
> > Old thing was hard, too hard for this generation
> You're vastly underestimating how hard the old thing was
Sounds like you're agreeing with him, if anything. Where is gerbilly's 'underestimation'?
> You're vastly underestimating how hard the old thing was
Sounds like you're agreeing with him, if anything. Where is gerbilly's 'underestimation'?
It took me a moment to get it too. I think they’re saying that the internet wasn’t a waterfall-style design. It wasn’t a one-off big thing, it was a huge collection of small projects where most of them have since died because the trade-offs didn’t work. Agile is way more work than waterfall.
Surely it takes quite a bit of perseverance to try all the things that don't work until you find the things that do work. The false starts and dead ends all count towards the process.
> BGP hijacking is still possible today.
.. in the same sense as http hijacking is possible today, i.e. without httpS. For BGP we have RPKI ROA for a quite a while, and ASPA is coming.
.. in the same sense as http hijacking is possible today, i.e. without httpS. For BGP we have RPKI ROA for a quite a while, and ASPA is coming.
RPKI ROA is trivially by-passable with a path modification attack. It only helps stopping hijackings of really well connected networks. And sadly it’s still not required.
> and ASPA is coming
Yeah, but it’s not here and requires verification at each AS append, which means we’re a good 5 years before it’s really enforceable on arbitrary prefixes across transit networks.
> and ASPA is coming
Yeah, but it’s not here and requires verification at each AS append, which means we’re a good 5 years before it’s really enforceable on arbitrary prefixes across transit networks.
Absolutely agree. And let me add:
* 99.99% of modern software startups could be built, maintained, and scaled in production by a single dedicated programmer and served on a single machine. Yes, even with tens of millions of users.
* Most tech companies hire for the prestige and to not feel lonely, not because they need to hire. (And to have pretty young interns walking around the office).
* YCombinator has deviated far from the original vision of Paul Graham and his essays. Nowadays all of the startups coming out of YC batches are just trash, and the YC panel has suffered "death by committee", i.e. bland risk-averse pop conformism riding the trends with no deep understanding of anything.
* 99.99% of modern software startups could be built, maintained, and scaled in production by a single dedicated programmer and served on a single machine. Yes, even with tens of millions of users.
* Most tech companies hire for the prestige and to not feel lonely, not because they need to hire. (And to have pretty young interns walking around the office).
* YCombinator has deviated far from the original vision of Paul Graham and his essays. Nowadays all of the startups coming out of YC batches are just trash, and the YC panel has suffered "death by committee", i.e. bland risk-averse pop conformism riding the trends with no deep understanding of anything.
> served on a single machine. Yes, even with tens of millions of users
i don't understand how this would work
i don't understand how this would work
There used to be FTP services in the 90s that served millions of users from a single machine. (Sorry can't find the reference right now).
Even production Twitter in 2023 is estimated to be able to fit on a very beefy machine: https://thume.ca/2023/01/02/one-machine-twitter/
Of course we would use a CDN in 2023, which is cheating, but from a business point of view it is juse one machine you manage.
Even production Twitter in 2023 is estimated to be able to fit on a very beefy machine: https://thume.ca/2023/01/02/one-machine-twitter/
Of course we would use a CDN in 2023, which is cheating, but from a business point of view it is juse one machine you manage.
Not sure about that, there are always smart people abound. The guy who made SerenityOS, the CommaAI founder, etc.
This simply reads to me like a "kids these days" type of old-man argument, which has, as we know, existed since time immemorial.
This simply reads to me like a "kids these days" type of old-man argument, which has, as we know, existed since time immemorial.
> This simply reads to me like a "kids these days" type of old-man argument, which has, as we know, existed since time immemorial.
And this counterargument has existed since time immemorial + 1. It proves nothing.
And this counterargument has existed since time immemorial + 1. It proves nothing.
It also disproves nothing, ie your argument bears no weight either. At least I have shown some examples where smart people of this generation are building complex things that, were they born 50 years ago, would likely have been able to build the Internet too.
Ok, I never said there weren't smart people still around.
But I stand behind what I claim. A large collaborative, and disinterested project like DARPANET could not get off the ground today.
Are you seriously arguing that the generation who used pocket protectors and HP calculators didn't have an advantage in concentration over the one who's been shown to distractedly check their phones every 15sec in case a cat might be doing something interesting?
But really the argument behind your argument seems to be that there is a monotone increasing function to 'progress'. I'm arguing that it's not and that sometimes we regress.
We can't even agree on what is real anymore, isn't that a serious disadvantage?
But I stand behind what I claim. A large collaborative, and disinterested project like DARPANET could not get off the ground today.
Are you seriously arguing that the generation who used pocket protectors and HP calculators didn't have an advantage in concentration over the one who's been shown to distractedly check their phones every 15sec in case a cat might be doing something interesting?
But really the argument behind your argument seems to be that there is a monotone increasing function to 'progress'. I'm arguing that it's not and that sometimes we regress.
We can't even agree on what is real anymore, isn't that a serious disadvantage?
> But really the argument behind your argument seems to be that there is a monotone increasing function to 'progress'. I'm arguing that it's not and that sometimes we regress.
Where did I ever say that? Your claim was about the Internet, not "progress" in general.
> Are you seriously arguing that the generation who used pocket protectors and HP calculators didn't have an advantage in concentration over the one who's been shown to distractedly check their phones every 15sec in case a cat might be doing something interesting?
Yes, because again you're generalizing to an entire population based on a stereotype. Do you think everyone back 50 years ago was similarly concentrating? No, because certain people can simply concentrate more than others, and those are the people building the Internet back then, and those are the same kinds of people who can build an Internet today. 99% of people were not doing so, we are talking about the differences of 0.0...1% of the population who built the Internet, so let's compare the same amount of people today too.
Where did I ever say that? Your claim was about the Internet, not "progress" in general.
> Are you seriously arguing that the generation who used pocket protectors and HP calculators didn't have an advantage in concentration over the one who's been shown to distractedly check their phones every 15sec in case a cat might be doing something interesting?
Yes, because again you're generalizing to an entire population based on a stereotype. Do you think everyone back 50 years ago was similarly concentrating? No, because certain people can simply concentrate more than others, and those are the people building the Internet back then, and those are the same kinds of people who can build an Internet today. 99% of people were not doing so, we are talking about the differences of 0.0...1% of the population who built the Internet, so let's compare the same amount of people today too.
Think of all the coworkers you've ever had and see if you can imagine them writing RFCs and debating back and forth and revising them?
I have worked at a lot of companies and I find the kind of people who can or are willing and able to do that is decreasing. It's nearly zero today.
If the Internet was invented today, it would work only for the happy path and fail with a million different error modes, each handled differently depending on the specific implementation.
And you know what? People would accept it's unreliability probably, the way we accepted the 'all computers crash' from the DOS era till about NT 40. Everybody knew that computers just crash like that. :shrug:
Today ChatGPT makes up facts and gets things wrong. But it's OK cos it's newer than Google, or printed books.
I have worked at a lot of companies and I find the kind of people who can or are willing and able to do that is decreasing. It's nearly zero today.
If the Internet was invented today, it would work only for the happy path and fail with a million different error modes, each handled differently depending on the specific implementation.
And you know what? People would accept it's unreliability probably, the way we accepted the 'all computers crash' from the DOS era till about NT 40. Everybody knew that computers just crash like that. :shrug:
Today ChatGPT makes up facts and gets things wrong. But it's OK cos it's newer than Google, or printed books.
I sometimes participate in the Rust RFCs, so yes, I can imagine them writing RFCs and debating back and forth, which they do daily.
Again you're focusing on coworkers and teams here and there at various companies, not in the best of the best who are the ones who built the internet and who would build it today. They are not average developers like one might normally work with, as I said, they are 0.0...1%.
Again you're focusing on coworkers and teams here and there at various companies, not in the best of the best who are the ones who built the internet and who would build it today. They are not average developers like one might normally work with, as I said, they are 0.0...1%.
> If the Internet was invented today, it would work only for the happy path and fail with a million different error modes, each handled differently depending on the specific implementation.
This is exactly how the internet works today and you just don’t see it. Try using source routing in your IP packets and see how far it gets. BGP implementations had to carry a “work with Cisco’s bug” flag for decades. Send some >1500 MTU packets across the world with varying paths and see how fragmentation and assembly is inconsistent across operators and implementations.
RFCs are loaded with errata, they skimp on critical details, and have bullshit “design by committee” features that never panned out. They aren’t special.
This is exactly how the internet works today and you just don’t see it. Try using source routing in your IP packets and see how far it gets. BGP implementations had to carry a “work with Cisco’s bug” flag for decades. Send some >1500 MTU packets across the world with varying paths and see how fragmentation and assembly is inconsistent across operators and implementations.
RFCs are loaded with errata, they skimp on critical details, and have bullshit “design by committee” features that never panned out. They aren’t special.
I think times are also just different now. Now a lot of the talent just gets vacuumed up by the Big Tech companies where they can be a cog in some wheel.
You seem to be ascribing some moral failure to the younger generations whereas there are also factors at play that go beyond individuals. It might be more sensible to say that the internet could not be invented in the current economic/social climate.
You seem to be ascribing some moral failure to the younger generations whereas there are also factors at play that go beyond individuals. It might be more sensible to say that the internet could not be invented in the current economic/social climate.
DARPANET was no more complex than large multi organizational projects like LLVM or Linux.
It wasn’t a giant coordinated thing that needed decades of patience. It was the epitome of an iterative project that involved stitching university systems together as the opportunity arose.
It wasn’t a giant coordinated thing that needed decades of patience. It was the epitome of an iterative project that involved stitching university systems together as the opportunity arose.
LLVM and Linux are done by 20 something? Just curious. I also think one issue with these comparisons is the breadth of tech stacks. It was easier to kick-start a JavaScript framework when Backbone JS came to be. But now given the competition, you need to have 8+ years of experience to contribute anything meaningful. This locks most of the young people from doing such stuff, even if they can have deep Buddhist focus.
> They don't have the attention span or the culture for it.
Meanwhile $GENERATION is inventing general AI. Your so-called unpopular opinion is basically "old man yells at younger people", but with even less foundation.
Meanwhile $GENERATION is inventing general AI. Your so-called unpopular opinion is basically "old man yells at younger people", but with even less foundation.
Yeah sure. ChatGPT confabulates constantly and has no understanding of what it's saying. I think it fails the 'I' part of 'AI.'
I've had it confidently invent URLs when challenged to show the sources for an obviously false claim. It invented a URL which has never existed.
I mean it's impressive, but it has a long way to go to become intelligent.
I've had it confidently invent URLs when challenged to show the sources for an obviously false claim. It invented a URL which has never existed.
I mean it's impressive, but it has a long way to go to become intelligent.
You're using ChatGPT as a strawman.
You claimed the younger generation doesn't have the attention span to invent the internet. Someone else mentioned the clear and ongoing progress in machine learning, which involves many things not named ChatGPT, and has become one of the biggest economic engines of the world.
You're just making an inane generalization. You will rightly be criticized for this.
And you're completely missing out on the inevitable fact that those zoomers could teach you a lot of things you don't know too.
You claimed the younger generation doesn't have the attention span to invent the internet. Someone else mentioned the clear and ongoing progress in machine learning, which involves many things not named ChatGPT, and has become one of the biggest economic engines of the world.
You're just making an inane generalization. You will rightly be criticized for this.
And you're completely missing out on the inevitable fact that those zoomers could teach you a lot of things you don't know too.
AI is Artificial Ignorance.
People saying AGI is right around the corner are just as wrong as people saying full self driving was right around the corner 5 years ago.
Not saying current generative ai will not have a huge impact. It will.
Not saying current generative ai will not have a huge impact. It will.
> Meanwhile $GENERATION is inventing general AI
They're not inventing anything, they're just taking the concept of machine learning that has been around for ages and throwing more data and hardware at it. Underneath it all, it's still just an algorithm that finds and repeats patterns and nothing more, the patterns are just getting more complex. It's not in any way comparable to the invention of the internet in terms of innovation.
They're not inventing anything, they're just taking the concept of machine learning that has been around for ages and throwing more data and hardware at it. Underneath it all, it's still just an algorithm that finds and repeats patterns and nothing more, the patterns are just getting more complex. It's not in any way comparable to the invention of the internet in terms of innovation.
To be fair: current generation does not exist in a time where inventing the Internet is necessary. And there probably are some big ideas out there incubating in obscurity that will only show themselves to be important much later.
Do we lack the vision for such big projects? Absolutely. Is it only the current generation's fault? Absolutely not. This is very widespread.
> They don't have the attention span or the culture for it.
I'd argue there is almost _no_ technical culture whatsoever. It is basically "trending on HN" and comment section discourse. This is a massive problem and contributes to the shoddy state of a lot of software nowadays.
Do we lack the vision for such big projects? Absolutely. Is it only the current generation's fault? Absolutely not. This is very widespread.
> They don't have the attention span or the culture for it.
I'd argue there is almost _no_ technical culture whatsoever. It is basically "trending on HN" and comment section discourse. This is a massive problem and contributes to the shoddy state of a lot of software nowadays.
[deleted]
I've seen the second thing happen department-wide where I work, three times now, with databases in particular.
It's a shame that this has negative connotations. There is a case that this is essential.
It seems like we are overcoming an AI winter, using the same technologies that was deemed infeasible 20 years ago.
When I did competitive programming 20 years ago. I would somewhat jokingly say that I would want to write and AI to solve all the problems. Our mentor laughed it of clearly not considering it even feasible – today ChatGPT would like outperform a highschool competitive programming competition.
We probably needed to look away from that generations presumptions in order to leap frog on some of these technologies.
It seems like we are overcoming an AI winter, using the same technologies that was deemed infeasible 20 years ago.
When I did competitive programming 20 years ago. I would somewhat jokingly say that I would want to write and AI to solve all the problems. Our mentor laughed it of clearly not considering it even feasible – today ChatGPT would like outperform a highschool competitive programming competition.
We probably needed to look away from that generations presumptions in order to leap frog on some of these technologies.
A contrary anectdotal exemple. We use MongoDB where I work and the only justification is it was the new fad at the time. Now it bites us because we use it as a relational DB. PostgreSQL would’ve been much more suitable in our case but it wasn’t in vogue.
Is there any regret in technology selection more widespread and common than having picked MongoDB during its bizarre new hotness phase? That phase where SQL database administrators where crying, thinking they'd lose their jobs tomorrow and many people claimed SQL was now absolutely deprecated.
In my experience the sql guys were laughing because they knew mongo was a fad and not an actual replacement.
I think using language-provided async calls everywhere will be the next mistake. Instead of callback hell, you get callback hell along with weird async race conditions and a contagion of async functions.
I find async calls totally sensible in a lot of web frontends and backends. The alternative is explicit threading models, which are overly pedantic in a wide variety of use cases.
In the last 20 or so years I can't think of one. I've migrated 4 different companies off of Mongo to Postgres and it's a huge project each time.
Probably nearly a full code rewrite, right? My job the past 4 years has essentially been to clean up from bad DB decisions.
The fact that MongoDB hype could reach the level it did is an indictment of tech culture.
Why was people's excitement allowed to trump data integrity? Are there not enough adults in the room to stop this from happening again?
Why was people's excitement allowed to trump data integrity? Are there not enough adults in the room to stop this from happening again?
This was probably the worst. Fads in business logic code or even APIs don't have anywhere near the lasting impact of a fad in screwing up the least easily replaceable part of your system, the DB.
This seems to be a failure outside of fads. This is application of an unviable technology.
Filesystems has been available for much longer than MongoDB. Using that as a database and having requirements changed to a relational database would be the same without anything about the filesystem being a fad.
Filesystems has been available for much longer than MongoDB. Using that as a database and having requirements changed to a relational database would be the same without anything about the filesystem being a fad.
GP's core argument is that a passing fad led to a poor technology decision.
I see it all the time as well, the MongoDB example is far from the only case. This industry fetishes anything that's new and if it turns out to be a bad idea you can always get another job with a shiny new technology on your resume.
I see it all the time as well, the MongoDB example is far from the only case. This industry fetishes anything that's new and if it turns out to be a bad idea you can always get another job with a shiny new technology on your resume.
Yet for some reason I never hear about people complaining that some idiot chose a file system to be the database for their application . I do hear quite often, disdain for the choice of MongoDB.
> I do hear quite often, disdain for the choice of MongoDB.
I guess a lot of people have been bitten really painfully by MongoDB misbehaving int the past.
At the same time people generally understand that for most use-cases the fs isn't a good database and if they use it anyway they put the blame on themself as they did knew better.
Through I mean I have seen projects use the filesystem as a database successfully. Mainly in context of some initially ad-hoc versions of special purpose tooling written in bash or similar which worked surprisingly well for initial usage and long term anyway had to be rewritten (then normally not using bash and often using sqlite in rare cases postgres).
I guess a lot of people have been bitten really painfully by MongoDB misbehaving int the past.
At the same time people generally understand that for most use-cases the fs isn't a good database and if they use it anyway they put the blame on themself as they did knew better.
Through I mean I have seen projects use the filesystem as a database successfully. Mainly in context of some initially ad-hoc versions of special purpose tooling written in bash or similar which worked surprisingly well for initial usage and long term anyway had to be rewritten (then normally not using bash and often using sqlite in rare cases postgres).
That's on you, it happens quite often :)
I think most people know that filesystems make for poor databases.
However, most people don't seem to realize that Excel spreadsheets are rather poor databases... they're the _real_ issue.
However, most people don't seem to realize that Excel spreadsheets are rather poor databases... they're the _real_ issue.
There are lots of situations where filesystems are good databases. The problem is that relational databases are flexible in ways that filesystems are not, so when your requirements change, a relational database is likely to be able to support the change whereas the filesystem may not.
Excel spreadsheets are terrible as databases and are also terrible as a file format for sending database records.
Excel spreadsheets are terrible as databases and are also terrible as a file format for sending database records.
Filesystems already fail at step#1 of a database, which is concurrent read / concurrent writes.
Its pretty obscure and arcane for the rules of read/write ordering on Linux/Windows systems and filesystems. You've got FILE* fwrites interacting with mmap regions, and locks don't exactly do what you think in Linux.
In both Linux / Windows, you end up needing to create a Filesystem mutex of some kind (Linux flock, Windows Mutex). Then, and only then, is it really safe to read or write to a file.
Its pretty obscure and arcane for the rules of read/write ordering on Linux/Windows systems and filesystems. You've got FILE* fwrites interacting with mmap regions, and locks don't exactly do what you think in Linux.
In both Linux / Windows, you end up needing to create a Filesystem mutex of some kind (Linux flock, Windows Mutex). Then, and only then, is it really safe to read or write to a file.
That complexity only exists if you create it. The regular read and write calls are serialized by the operating system.
I'm sure you're familiar with the ATM example?
Lets say Bob's money in an ATM is being held in your "database" (be it a file, or SQL database, or whatever).
Thread#1: Depositing money --------------
Lets say Bob started with X-dollars. What is Bob's value of his account after Thread#1 and Thread#2 run concurrently?
More than likely, Bob's account is either X, X-100, or X+100. But under the worst case scenario, a full corruption of Bob's account value could happen. If Bob's account straddles across a filesystem boundary, like across 4096 hard drive cluster or something, then the "writefile" itself could be corrupted and interleaved between the two threads.
Lets say Bob's money in an ATM is being held in your "database" (be it a file, or SQL database, or whatever).
Thread#1: Depositing money --------------
int bob_balance = readfile();
bob_balance += 100; // Add 100 to Bob's account.
writefile(bob_balance);
int bob_balance = readfile();
bob_balance -= 100; // Add 100 to Bob's account.
writefile(bob_balance);
Lets say Bob started with X-dollars. What is Bob's value of his account after Thread#1 and Thread#2 run concurrently?
More than likely, Bob's account is either X, X-100, or X+100. But under the worst case scenario, a full corruption of Bob's account value could happen. If Bob's account straddles across a filesystem boundary, like across 4096 hard drive cluster or something, then the "writefile" itself could be corrupted and interleaved between the two threads.
Well the irony of this example is that Postgres and MySQL struggle with it too because they use row-level locking by default, not serializable (full ACID). You'd be ok if you repeatedly updated a balance row as a way to lock things, but if you relied on summing withdrawal/deposit rows to determine balances as you would in a fully normalized schema, you'd get a race condition allowing Bob to overdraw. You can put the transaction in serializable mode, but it becomes very slow and non-scalable. So you have to work around this with a little denormalization or separate pending/active balances.
But yes it'd be awful doing this with files.
But yes it'd be awful doing this with files.
They don’t “struggle” with it at all. You presented two approaches that work fine (a balance row or serialized transactions). It can also be done with monotonic “account transaction” counters with unique constraints to prevent the concurrent inserts of withdrawals.
It’s trivially solvable and it never results in complete DB corruption by getting the ordering wrong.
It’s trivially solvable and it never results in complete DB corruption by getting the ordering wrong.
Most of Linux's userspace uses files as databases. There are a lot of cases where you won't ever have two of the same process running at once. One example is those that bind a specific port.
People are talking about MongoDB, PostgreSQL, MySQL and the like in this thread of discussion. And suddenly you're talking about local userspace programs on Linux?
There's a web-bias in the discussion. Database here is innately concurrent, such as when you and I submit a comment to this webpage (Hacker News), the ordering of our submissions are ill specified and effectively random.
A proper database organizes the data (ex: PostgreSQL) so that its in a form that's well defined.
This is true for even the smallest of web servers. Concurrency and concurrent access is fundamental to web applications today. I know PHP has access to raw files if you ever wanted them, but its definitely a dangerous proposition to be doing raw file access on web apps. There's just too much risk of data corruption.
There's a web-bias in the discussion. Database here is innately concurrent, such as when you and I submit a comment to this webpage (Hacker News), the ordering of our submissions are ill specified and effectively random.
A proper database organizes the data (ex: PostgreSQL) so that its in a form that's well defined.
This is true for even the smallest of web servers. Concurrency and concurrent access is fundamental to web applications today. I know PHP has access to raw files if you ever wanted them, but its definitely a dangerous proposition to be doing raw file access on web apps. There's just too much risk of data corruption.
Through there are use cases (e.g. some ad-hoc special purpose corner case tooling) which:
- do not need or do concurrent anything
- do not need any form of transactions
- do only need some simple key value(blob) store
- are as ad-hoc scripts written in e.g. bash, making it just easier to access the file system for this
Sure most use cases do not fit this and should not use the file system.
- do not need or do concurrent anything
- do not need any form of transactions
- do only need some simple key value(blob) store
- are as ad-hoc scripts written in e.g. bash, making it just easier to access the file system for this
Sure most use cases do not fit this and should not use the file system.
What in the world are you doing where you need everything you described? Writing a custom cache for a FS?
Just a webserver. If two threads write to a file at the same time, you start getting wonky issues.
You know, like if you and I make a comment at the same time here on Hacker News, the server's hard drive has to serialize the data so that all the other readers can handle it.
You know, like if you and I make a comment at the same time here on Hacker News, the server's hard drive has to serialize the data so that all the other readers can handle it.
I was thinking more about what mmap has to do with anything. Anyway it depends on the API you use. libc read/write are thread safe for instance. Obviously you still have to synchronize the higher level concept of writes if you are not writing an object all at once, but this is rather trivial to do.
NoSQL fad was the most destructive I can think of. Those had their place as niche tools, but they somehow became the default for a while. Once you pick the wrong DBMS, you're building on quicksand.
I have come to realize why.
SQL has a problem, less of technical nature but more of organizational/knowledge transfer nature.
I have spent way to much time in discussions about schema, SQL types, SQL library usage and anything ORMs. Also a lot of hidden gotchas, like A LOT. Through most aren't really hidden it's more like people somehow having major knowledge gaps without realizing it. Like not understanding isolation levels and therefor misunderstanding which guarantees a transaction provides. Or somehow fundamentally rejecting that you design an application with a specific transaction level in mind and changing it later is non trivial, potentially to a point of making the change infeasible. Or pointless discussions about integer sizing and signing and the docent different ways you could map a unsiged 16bit number to SQL. Or people not understanding row/column locks. Or getting bitten by upserts not allowing upserting the same (compound)key twice in the same statement in some dbs. Or ...
Well I'm kinda feed up. But I still had way worse experiences with Mongo (but that was ~8? years ago).
SQL has a problem, less of technical nature but more of organizational/knowledge transfer nature.
I have spent way to much time in discussions about schema, SQL types, SQL library usage and anything ORMs. Also a lot of hidden gotchas, like A LOT. Through most aren't really hidden it's more like people somehow having major knowledge gaps without realizing it. Like not understanding isolation levels and therefor misunderstanding which guarantees a transaction provides. Or somehow fundamentally rejecting that you design an application with a specific transaction level in mind and changing it later is non trivial, potentially to a point of making the change infeasible. Or pointless discussions about integer sizing and signing and the docent different ways you could map a unsiged 16bit number to SQL. Or people not understanding row/column locks. Or getting bitten by upserts not allowing upserting the same (compound)key twice in the same statement in some dbs. Or ...
Well I'm kinda feed up. But I still had way worse experiences with Mongo (but that was ~8? years ago).
Yeah, SQL has its problems too, a lot of them seemingly from legacy support. I could write a nice one-page guide to using SQL the easy way and getting past the gotchas I've waded through, but it'd drown in the noise. The worst/funniest one is how you should only use `timestamptz` and not `timestamp`.
It's also complicated out of necessity. A relational DBMS is doing a lot of things people maybe take for granted or don't realize they need.
I think NoSQL was the natural next step after ORMs, which are also used in a lot of places they shouldn't.
It's also complicated out of necessity. A relational DBMS is doing a lot of things people maybe take for granted or don't realize they need.
I think NoSQL was the natural next step after ORMs, which are also used in a lot of places they shouldn't.
But, MongoDB is web-scale: https://www.youtube.com/watch?v=b2F-DItXtZs
I heard Snapchat uses it to support their web-scale disappearing photos, cause it erases your data randomly
Vendor lock in cloud fad is going to end badly. Kubernetes outside FAANG has potential to get bad.
That's just plain old using the wrong tool for the wrong job. Although, I suppose that part of the rise of any new tool will be trying to figure out which for which jobs it is the right tool, and sometimes the failure cases might live longer than expected.
The fad was "MongoDB is a tool that everyone has a job for" and it doesn't matter that I always knew that was a stupid take because I don't sign the purchase orders and if a manager listens to someone who makes way less than they do they feel less important.
This could also be a case of developers not pressing hard enough back on technically-less-competent manager-driven architectural decisions
I know it's a hype right now, but I didn't get good results with any AI, be it text or image generation.
It all looked impressive the first few days, but the novelty wore off quite quickly.
It all looked impressive the first few days, but the novelty wore off quite quickly.
Have you tried midjourney for image generation? Especially for photography style images, I've gotten some really cool results that I go back to occasionally
You are looking at a Nokia 3210 generation of AI.The most primitive version of what is to come. So the fact that the novelty has worn off is not really a good indicator of how much this will transform our everyday lives. Wait for the iPhone generation of AI, always in your pocket, interacting with you multiple times a day, changing how you consume news, how you communicate with the outside world, your friends and family.
Here we go again "it's early day", "it's like how the internet was born"
Here we go again. "640K ought to be enough for anybody". "The horse is here to stay but the automobile is only a novelty—a fad."
I don't think the notion is that we should be relying entirely on cached results from prior generations. Rather, we need to understand what was tried and what worked and what didn't, and why. With this knowledge, we can see when innovation has invalidated prior assumptions, and we can try again.
Yep, as nobody argues we should completely forget previous generations. The question is where to set the needle. The author definitely thinks we do not dwell enough on the past and should spend more time studying it.
The entirety of AI innovation is driven by hardware improvements. Almost all AI research is done at the edge of our compute capabilities, and most of the models which produce results today existed in some form 20 years ago.
We didn't leap-frog our predecessors presumptions, we built exactly what many envisioned but were unable to put to fruition with the computers of their time.
We didn't leap-frog our predecessors presumptions, we built exactly what many envisioned but were unable to put to fruition with the computers of their time.
The point is that we retried something that was previously deemed infeasible. Had you been too much aware of the history, you might not have done that.
An essay about academia (versus software engineering in industry) would probably make slightly different points. Academics definitely know their history.
Also, when an actual disruptive new technology is first invented, jumping on it and trying to do something with it is both trendy and arguably rational, but this is a relatively rare occurrence.
Also, when an actual disruptive new technology is first invented, jumping on it and trying to do something with it is both trendy and arguably rational, but this is a relatively rare occurrence.
It was deemed infeasible because it was infeasible.
It took 2 generations time for computers to improve enough that it became feasible. And also a huge unexpected discovery about 20 years ago, that you can pre-train a neural network and cost your costs by an order of magnitude.
It took 2 generations time for computers to improve enough that it became feasible. And also a huge unexpected discovery about 20 years ago, that you can pre-train a neural network and cost your costs by an order of magnitude.
“ today ChatGPT would like outperform a highschool competitive programming competition.”
Google did it first. You input a search string, find results on first or second attempt and then copy and paste the code.
Google did it first. You input a search string, find results on first or second attempt and then copy and paste the code.
Not even a close comparison.
At best, Googling StackOverflow gets me one function, but only if I know the right keywords and it is short. ChatGPT, I can (and have!) given it example data and said "make a python script to parse this", and it not only gives me code, not only does it work, but when I ask it to extend this to do more or differently, the changes also work coherently with the previous results. For example: https://github.com/BenWheatley/Studies-of-AI/blob/main/codin...
At best, Googling StackOverflow gets me one function, but only if I know the right keywords and it is short. ChatGPT, I can (and have!) given it example data and said "make a python script to parse this", and it not only gives me code, not only does it work, but when I ask it to extend this to do more or differently, the changes also work coherently with the previous results. For example: https://github.com/BenWheatley/Studies-of-AI/blob/main/codin...
I agree with some of what he is saying, but don't really get the "pop culture" framing. Isn't pop culture just popular cultural artifacts? I'm under the impression they are mostly looked down upon for class reasons more so than any of the intrinsic problems stated.
"Pop culture" is a post-WW2 US phenomenon that creates a shared societal reality through movies, TV shows, household items and brands, etc. As of late, it has infected the whole world through social media "virality". Something new appears, then thousands of outlets, youtubers and "tech" journalists are repeating it and most of society starts talking about it without any historic or technical background whatsoever. It's an overly-expressive culture based on hype and reactivity.
Not sure you are the author but I don't really think that's what pop culture is considered colloquially. And you're basically just describing any cultural ideas that can be considered "viral." I guess a sufficiently large number of people accepting that viral idea makes it popular but pop culture to me is just music/movies/books etc that are popular.
Basically this piece is just saying "the dominant (read: popular) culture in tech companies is bad" and they all have basically slight variations on this bad culture.
Basically this piece is just saying "the dominant (read: popular) culture in tech companies is bad" and they all have basically slight variations on this bad culture.
I am describing the transmission mechanisms of pop culture and what it's rooted in. It's inherently linked to consumerism, advertising, mass media and fashion. The currently popular music/movies/books are just a manifestation of that. Important scientific, political or philosophical ideas can also go "viral" among intellectual circles, but you wouldn't hear about them in an entertainment TV show or in an advertisement.
>It's inherently linked to consumerism, advertising, mass media and fashion.
Strongly disagree with this statement. It's currently linked to those things, but popular culture from even 300 years ago was not inherently linked to consumerism at all. It was more rooted in songs and stories that were performed and shared in relatively public spaces like taverns, schools and churches. What changed has mostly stemmed from the advent of the printing press and the subsequent creation of copyright laws.
Nowadays popular culture is linked to consumerism, but that's because new cultural content is treated strictly as a product first and a common point of reference second. We have created these perverse economic incentives that have wreaked absolute havoc on the creative commons, which for the vast majority of human history included essentially all of "popular culture".
Strongly disagree with this statement. It's currently linked to those things, but popular culture from even 300 years ago was not inherently linked to consumerism at all. It was more rooted in songs and stories that were performed and shared in relatively public spaces like taverns, schools and churches. What changed has mostly stemmed from the advent of the printing press and the subsequent creation of copyright laws.
Nowadays popular culture is linked to consumerism, but that's because new cultural content is treated strictly as a product first and a common point of reference second. We have created these perverse economic incentives that have wreaked absolute havoc on the creative commons, which for the vast majority of human history included essentially all of "popular culture".
Idk, I think what you're really talking about is just ideas going hyperviral in tech companies very quickly without adequete time to judge their merits based on historical comparison, or any meaningful debate. Then afterward any attempt to challenge the idea, the fact that the idea is so popular is used to defend it. "How can you think that when X on twitter said they agree! That company X is doing it so we're gonna do it."
Kind of ironic for the innovation industry to just be a bunch of followers chasing whatever's popular huh.
Kind of ironic for the innovation industry to just be a bunch of followers chasing whatever's popular huh.
Its even more micro, the current on trend tiktok dance from the last 15 minutes that everyone is doing is what everyone is doing.
Lemmings as a construct perhaps. Naive social media obsessed teens perhaps.
Lemmings as a construct perhaps. Naive social media obsessed teens perhaps.
I agree -- I found the author's definition distracting to the points being made.
> The “Pop” in “Pop Culture” stands for “popularity”. If it’s popular then it must be right.
No -- popular culture is simply what is currently popular.
The popular culture could value novelty and uniqueness -- inherently "unpopular" things. That's not the case today, but it fits the definition of pop culture.
> The “Pop” in “Pop Culture” stands for “popularity”. If it’s popular then it must be right.
No -- popular culture is simply what is currently popular.
The popular culture could value novelty and uniqueness -- inherently "unpopular" things. That's not the case today, but it fits the definition of pop culture.
> older is inherently inferior.
As an “older,” I’ve encountered this exact attitude.
Really uplifting.
As a positive, it pissed me off enough, to “drop out,” and lean into early retirement.
I spent the majority of my career at the antithesis of “pop culture,” which was a 100-year-old Japanese company.
I am grateful for the lessons and habits I got, there.
Plenty of stuff that they did wrong, but they also did a lot of stuff right.
As an “older,” I’ve encountered this exact attitude.
Really uplifting.
As a positive, it pissed me off enough, to “drop out,” and lean into early retirement.
I spent the majority of my career at the antithesis of “pop culture,” which was a 100-year-old Japanese company.
I am grateful for the lessons and habits I got, there.
Plenty of stuff that they did wrong, but they also did a lot of stuff right.
> As an “older,” I’ve encountered this exact attitude.
Same here. I was frustrating to watch young engineers insist on ignoring well-established knowledge only to go out and make mistakes that cost the company 6 to 8 months and hundreds of thousands of dollars, maybe more. And they were warned about the very things that happened during design reviews.
Two examples (without getting into identifiable details):
A complex mechanical assembly intended for challenging thermal and dynamic (vibration) environment. After studying the design I told the 20-something mechanical engineer the approach she took to the distribution of loads would fail instantly. This was done professionally, one-on-one and without any "attitude", to use the term. Her response: "I have a Masters degree in Mechanical Engineering from MIT, I think I know what I am doing.".
Six months later the assembly, quite literally, exploded during the vibration test. Even after that she still refused to listen to my recommendations. This joke easily cost the company a million dollars and six months of wasted effort. If you consider this in the context of the larger project, the cost and delays could have been an order of magnitude greater.
Second example. A EE designing a board to drive a bunch of LEDs. Again, 20-something. If I remember correctly, the board had 15 independent channels. He executed this as what I call "datasheet design". He picked a switched-mode LED driver, used the circuit from the datasheet with little modification and stuffed the board with 15 of these circuit blocks.
The board ends-up having hundreds of components, it bigger than what we wanted and complexity/reliability/RFI were of concern. After studying this I had a meeting with him and explained that we could use an analog circuit with somewhere around four components per channel to drive the LEDs with excellent efficiency. The board would shrink to 1/4 the size, use 80% less components, have a less intense RF signature, etc.
In this particular case, he actually laughed at me and said something like "Are you crazy? Everyone knows linear drive of LEDs is the most inefficient thing you can do". Of course, this is precisely the kind of thing a book-smart engineer who just copies circuits from datasheets would say. Not only is this not true, it is ridiculously easy math to show how you can build efficient LED drivers in the analog domain with just a few components (hint: control the power supply voltage with an efficient switched-mode regulator set to a precise voltage based on the LED string Vf range).
Once again, this design was implemented. It caused untold problems in the context of the greater project, all of which required mitigation in some form.
I don't know what it is. When I was a 20-something engineer I was eager to listen to and work with the older engineers. I learned more this way than I can possibly describe. Not just about engineering, about life.
Same here. I was frustrating to watch young engineers insist on ignoring well-established knowledge only to go out and make mistakes that cost the company 6 to 8 months and hundreds of thousands of dollars, maybe more. And they were warned about the very things that happened during design reviews.
Two examples (without getting into identifiable details):
A complex mechanical assembly intended for challenging thermal and dynamic (vibration) environment. After studying the design I told the 20-something mechanical engineer the approach she took to the distribution of loads would fail instantly. This was done professionally, one-on-one and without any "attitude", to use the term. Her response: "I have a Masters degree in Mechanical Engineering from MIT, I think I know what I am doing.".
Six months later the assembly, quite literally, exploded during the vibration test. Even after that she still refused to listen to my recommendations. This joke easily cost the company a million dollars and six months of wasted effort. If you consider this in the context of the larger project, the cost and delays could have been an order of magnitude greater.
Second example. A EE designing a board to drive a bunch of LEDs. Again, 20-something. If I remember correctly, the board had 15 independent channels. He executed this as what I call "datasheet design". He picked a switched-mode LED driver, used the circuit from the datasheet with little modification and stuffed the board with 15 of these circuit blocks.
The board ends-up having hundreds of components, it bigger than what we wanted and complexity/reliability/RFI were of concern. After studying this I had a meeting with him and explained that we could use an analog circuit with somewhere around four components per channel to drive the LEDs with excellent efficiency. The board would shrink to 1/4 the size, use 80% less components, have a less intense RF signature, etc.
In this particular case, he actually laughed at me and said something like "Are you crazy? Everyone knows linear drive of LEDs is the most inefficient thing you can do". Of course, this is precisely the kind of thing a book-smart engineer who just copies circuits from datasheets would say. Not only is this not true, it is ridiculously easy math to show how you can build efficient LED drivers in the analog domain with just a few components (hint: control the power supply voltage with an efficient switched-mode regulator set to a precise voltage based on the LED string Vf range).
Once again, this design was implemented. It caused untold problems in the context of the greater project, all of which required mitigation in some form.
I don't know what it is. When I was a 20-something engineer I was eager to listen to and work with the older engineers. I learned more this way than I can possibly describe. Not just about engineering, about life.
I am sorry to hear about that.
At my company, in Tokyo, there were job titles you couldn't get, until you reached a certain chronological age. Would not be possible, here in the US.
Sometimes, I look at some of these Jurassic-scale meltdowns, and ask myself "Were there any adults in the room, when this idea was discussed? Even a minimally-experienced geek could have foreseen most of these problems."
Of course, it's a trick question. The answer is, inevitably, "No."
At my company, in Tokyo, there were job titles you couldn't get, until you reached a certain chronological age. Would not be possible, here in the US.
Sometimes, I look at some of these Jurassic-scale meltdowns, and ask myself "Were there any adults in the room, when this idea was discussed? Even a minimally-experienced geek could have foreseen most of these problems."
Of course, it's a trick question. The answer is, inevitably, "No."
<<A “disdain for history”>>
A common problem in contemporary culture is a disregard for history, which can be seen not only in startup companies and the technology industry, but throughout society as a whole. During times of significant change, it is common for people to believe that they are much more intelligent and advanced than previous generations, who they may view as ignorant or backward. As the consequences of the revolution inevitably become clear, when the revolution turns on its children, people often begin to appreciate the positive aspects of the past and recognize that revolutions are usually not the solution you want (for the exact same reason why you usually don't want to rewrite a huge software project).
Let us hope that the current period of revolution is coming to an end.
A common problem in contemporary culture is a disregard for history, which can be seen not only in startup companies and the technology industry, but throughout society as a whole. During times of significant change, it is common for people to believe that they are much more intelligent and advanced than previous generations, who they may view as ignorant or backward. As the consequences of the revolution inevitably become clear, when the revolution turns on its children, people often begin to appreciate the positive aspects of the past and recognize that revolutions are usually not the solution you want (for the exact same reason why you usually don't want to rewrite a huge software project).
Let us hope that the current period of revolution is coming to an end.
> Let us hope that the current period of revolution is coming to an end.
Let us hope that the current need of revolution is coming to an end. FTFY
Let us hope that the current need of revolution is coming to an end. FTFY
Sometimes people disregard history in a very obvious way.
One time there is a person who wants a system rewritten, because of some perceived complexity. The original builders who built the system from the ground up is still actively maintaining it, but there is no attempt to understand whether the perceived complexity is incidental or essential, which in fact most of them are the latter. Some people just want things to fit their world.
But, on the bright side, there are people who just don't know history, but they would be happy to learn. There's a hopeful number of those people!
One time there is a person who wants a system rewritten, because of some perceived complexity. The original builders who built the system from the ground up is still actively maintaining it, but there is no attempt to understand whether the perceived complexity is incidental or essential, which in fact most of them are the latter. Some people just want things to fit their world.
But, on the bright side, there are people who just don't know history, but they would be happy to learn. There's a hopeful number of those people!
Well I think the author got one thing right:
> The “Pop” in “Pop Culture” stands for “popularity”. If it’s popular then it must be right.
And that's social media simplified. The internet is filled with pop-seeking garbage because pop was the best metric anyone could fathom. Even now the AI's are struggling to reach for a better version of "right".
But more to the author's point, yes, modern tech startups and their funders are absolutely obsessed with being trendy, even moreso than an 80's teenager (a lot of the big players were 80's teenagers, btw).
> The “Pop” in “Pop Culture” stands for “popularity”. If it’s popular then it must be right.
And that's social media simplified. The internet is filled with pop-seeking garbage because pop was the best metric anyone could fathom. Even now the AI's are struggling to reach for a better version of "right".
But more to the author's point, yes, modern tech startups and their funders are absolutely obsessed with being trendy, even moreso than an 80's teenager (a lot of the big players were 80's teenagers, btw).
Kind of a nitpick, but AIs mostly don't get to choose what's "right". I mean they're trained with a particular goal in mind already, so either their training data or whatever metric their self-training is set to optimize defines "right" for them in advance.
It's not AIs that are struggling to find a better version of "right", it's people building AIs.
It's not AIs that are struggling to find a better version of "right", it's people building AIs.
It’s true. People believe you can raise money on having a trendy feeling product idea with very little merit… and sadly they are right. It baffles me.
"$bigcompany uses it so we must use it as well" is modern-day cargo cult programming and i've seen it in lots of places.
It's also wishful thinking. Your problem isn't scaling to a hundred million users, your problem is finding simple product/market fit!
If tech companies are pop cultures, then HN is Teen Beat.
I'm looking at https://tigerbeat.com now and wishing I had the 'shop skills to do a HN front page. Buzz are stories, Crush is "Tell HN", and Polls are "Ask HN"; the mapping practically writes itself...
[Edit: and Beauty are the automatic YC front page spots?]
[Edit: and Beauty are the automatic YC front page spots?]
🆃 𝐓𝐢𝐠𝐞𝐫 𝐁𝐞𝐚𝐭 buzz | music | beauty | style | crush
1. ▲ Everything we know about 'Outer Banks' Season 2
2. ▲ Ask TB: Which New Song Off 'Sour' is Your Favorite?
3. ▲ Pick a Yearbook Superlative and We'll Tell You...
> There are two kinds of fools. One says, "This is old, therefore it is good"; the other says, "This is new, therefore it is better"
The former is a little Lindy. The latter is ready for paradigm shifts. Ideal is if you don't choose based on age.
But I'll say something contrary: neither of these things matter in technology. The layoffs are good for the firms that 2xed in the pandemic. The kubernetes is survivable or beneficial.
The former is a little Lindy. The latter is ready for paradigm shifts. Ideal is if you don't choose based on age.
But I'll say something contrary: neither of these things matter in technology. The layoffs are good for the firms that 2xed in the pandemic. The kubernetes is survivable or beneficial.
They're more like cults.
"a system or group of people who practice excessive devotion to a figure, object, or belief system, typically following a charismatic leader"
https://study.com/learn/lesson/cult-characteristics-types-be...
"a system or group of people who practice excessive devotion to a figure, object, or belief system, typically following a charismatic leader"
https://study.com/learn/lesson/cult-characteristics-types-be...
I expected the example at the end to be kubernetes, but instead it's layoffs. I think the article works almost equally as well if you swap in k8s, blockchain, or a few other buzzy buzzwords, which is kind of a testament to the truthiness of the argument.
Everyone I've ever met with experience deploying to heterogeneous environments wholeheartedly endorses Kubernetes.
If you use a managed version of k8s like AKS/EKS - it's a literal no-brainer for running containerized workloads.
I regularly wonder how much of the "tooling" in modern development stems from not knowing or making an attempt to understand what GNU applications from 30+ years ago offer out of the box.
Tech is a 24/7 popularity contest where everybody can have their 15 minutes of fame. Enjoy the ride.
Startups are pop culture cults.
Yes, tech companies are building an image of pop cultures, but they are not. For example, layoffs are never "mimicking" what other companies are doing. Pop culture people may think it is, but business people -- who tech CEOs really are -- always tries to make the right decisions.
Whoa whoa whoa. Regarding "layoffs are never 'mimicking' what other companies are doing" layoffs are getting hyped like other trends in tech. Tech management is very trend-driven. Over-hiring to lock down talent, swinging to lean to the point of dysfunction, is characteristic of the tech industry. Entrepreneurs managing on the basis of pop management books and gurus is rife in tech.
Having a lot of exposure to early stage startups, I get that most founders have essentially zero management experience, but the Darwinian process of VCs and go-to-market doesn't seem to favor them actually going out and acquiring some.
A lot of those VCs aren't really experienced trained managers themselves. The most visible ones tweet in ways that confirm this.
Layoffs are in very large part about mimicking what other companies are doing. I have no doubt that most CEOs are honestly trying to make the right decision, but (just like in pop culture!) the mere fact of what everyone else is doing has a substantial impact on the right business decision for you. If layoffs are a big trend this year, that substantially reduces both the reputational cost of doing your own layoff and the number of high performers you can expect to jump ship afterwards.
Then explain the over hiring during easy money after pandemic stimulus. Poor decision making, even if consistent, isn't 'right decision' making.
There was no straightforward way to tell in the post-pandemic environment which changes in the economy would be transient and which ones would be long-term. It's easy to tell a just-so story about how these companies' pandemic boom was obviously because of easy money and they should have known it wouldn't last. But back in 2020, I remember I used to go around telling a similar but wrong story about how remote work won't last.
I think it's easy to mistake the concept of fads within technology with the application of arguably necessary abstractions. Most of what is new and faddish is just another abstraction around some (probably, relatively) archaic system.
The abstraction is the new thing, not the technology or the language that it's written in.
I think there's some rationality.
Let's say as a company you need money. Money comes from investors and/or customers. Customers or (especially) investors may want you to make "modern" software using "modern" technology. Developers (especially the young talented ones you can afford) are also attracted to modern tech for rational ($£€) reasons.
So you can ignore that, and miss out on money and talent and thus maybe success. Or you can take the easier route and do what everyone else is doing.
Let's say as a company you need money. Money comes from investors and/or customers. Customers or (especially) investors may want you to make "modern" software using "modern" technology. Developers (especially the young talented ones you can afford) are also attracted to modern tech for rational ($£€) reasons.
So you can ignore that, and miss out on money and talent and thus maybe success. Or you can take the easier route and do what everyone else is doing.
I mean, it's turtles all the way down isn't it. I would just call that second hand irrationality. Why? Because investors chasing shiny new things because they are new is also irrational.
A better way to state this is that the problems we're facing today are due to the whims of capital owners and management, not labor.
We could have a system where companies don't do layoffs, and workers sit on 50% of board seats, and democracy in the workplace is standard.
I wonder how many majority shareholders truly want the billions of dollars in stock that comes with that, knowing that their wealth deprives countless thousands/millions of people of their opportunity. Would they be ok with a different kind of corporate structure? Something like a cooperative where management and the CEO are elected by workers, and difference in pay doesn't exceed perhaps 10:1?
We could have a system where companies don't do layoffs, and workers sit on 50% of board seats, and democracy in the workplace is standard.
I wonder how many majority shareholders truly want the billions of dollars in stock that comes with that, knowing that their wealth deprives countless thousands/millions of people of their opportunity. Would they be ok with a different kind of corporate structure? Something like a cooperative where management and the CEO are elected by workers, and difference in pay doesn't exceed perhaps 10:1?
> Constant churn in a software development team, both among the programmers and designers, is absolutely devastating. It is the death knell for a software project. Makes deadlines meaningless. It turns software into a disposable, single-use product like a paper towel. Anything that increases team member churn threatens the very viability of the project and the software it’s creating.
From an essay that is worth reading in full, "Theory-building and why employee churn is lethal to software companies": https://www.baldurbjarnason.com/2022/theory-building/
I think it's exactly right about the importance of "mental models" and "theory building", and if we could keep that in mind we could build better more maintainable software. ("More maintainable" over the long-term I think is almost synonymous with "has easy to grasp mental models that are sufficient to guide your work with the system")