We should IMO also entertain one more possibility: namely pressure from the top.
A lot of people who I knew as sympathetic and calm before they took management roles turned into something I could code in one minute: namely a program that asks "how much is this going to take?" and if your answer is above N hours/days then they say "no, we're not doing it". And that's not because they are stupid or suddenly non-sympathetic. It's because their bosses optimize for those metrics and measure them (and their salary, and their bonuses, and even their vacation days) by the same metrics.
Perverted incentives play a big part in the current state of things where everyone just looks baffled at thing X and is like "why in the holy frak isn't this working better?".
Truth is, MANY, and I mean really A LOT of people know that their work is sub-optimal but pressure from above prevents them from making it better.
And people are not independent -- for most people outside IT and other prestige / high-skill professions, standing up to the boss means 3 to 9 months of unemployment and maybe no food on the table. Hence everybody learns to suck it up and do the bare minimum that keeps them employed, perpetuating the cycle.
Multiply that to at least 90% of our world and it's IMO quite easy to understand why it is like it is.
My issue is mostly with my profession -- programming. Sometimes we are so micromanaged and our time is so sliced and diced that all of this short-term thinking easily gets 5x more expensive on a short time frame anywhere from 3 to 6 months.
This has been observed numerous times yet IT managers seem to want to never learn.
It's OK to try and save money. But saving money short-term in order to have a huge expense down the line is just being irresponsible from those managers.
I have had similar managers to what was described above, in those types of organizations. It may be a lost cause but it may be an opportunity to work on your influence skills; being able to explain and sell your solution is perhaps even more important than coming up with it in the first place.
3 years into major project, my team finally got prioritized to work on and improvement that will take us a couple weeks, that we were not able to work on previously because we could not justify its value. But for the past 3 years the organization has lived with pain that this would have resolved. So now we can justify it. And the thing is, it's not like we didn't know 3 years ago when we said we wanted to make this happen but things are going to be terrible if we were not able to prioritize it but in many organizations it's not good enough to just say how bad things will be. People need to actually have felt the pain.
Honestly, I think that's okay on its face. My bigger issue is that frequently there is no or very little trust around engineers who predict what the major problems will be an advocate for them and then it's not like when they're proven right management now listens to them the next time. I think that's the real problem.
This is a problem. But at any given time management hears programmers arguing for both sides - the "if you're not using Kubernetes you're a moron" and the "learn how to sysadmin and you'll realize you don't need Kubernetes in the first place" (quotes from the top of the thread). In many cases folks in senior management do not have any idea of these things, and they rely on one of these two opinions, resulting in the other half claiming here on HN that management is all bull.
What the profession lacks is a code of practices - like a Joel Test accepted by every accredited engineer.
I am not sure that is net positive for such a rapidly evolving space. Even now people are debating if unit tests are needed and other basic topics. The only "settled" thing about the profession seems to be that gotos are bad.
I'm not sure how one gets software engineers to justify and back up their decisions like this on a regular basis, but I suspect it would help management trust their engineers more.
More balanced senior engineers (I know anecdotally that there are lots of them) speaking up and challenging their fellow-engineers to justify their extreme positions will be a good start IMO.
No matter what brand,the base unit comes with enough RAM, processing power and spacious SSD.
Everybody gets the same brand,as it's easier to support from the IT perspective.
Keyboard,mouse,monitors should be an individual choice. Some want to ruin their vertebrae by staring at a tiny 13" screen and be happy about it,while some need 3 monitors and 2 keyboards to feel the power,why not.
Not sure why some companies are so tight when it comes to the equipment for developers,as it's always a small fraction of the overall cost of the position.
"If you use extremist and simplistic generalizations you are not worth listening to in a discussion" would be the first policy I'd put into a team.
Balanced arguments with pro/con analysis is what makes an engineer senior and a contributor to an argument. Everybody else shouldn't participate the next time around.
"The whole problem with the world is that fools and
fanatics are always so certain of themselves, and
wiser people so full of doubts."
"Give me a one-handed Economist. All my economists
say 'on hand...', then 'but on the other..."
If you demonstrate that you will not submit to extremists, I've found that a good chunk of the more balanced people are then encouraged to speak up.
---
TL;DR: Silence the bad and loud voices, and the wiser and quieter voices will start speaking.
I think it was Andrew Grove (of Intel / High Output Management) who boiled this down to the following algorithm:
(1) Invite all sides to a meeting. (2) Ask them what their decision is. (3a) If they agree, implement the decision. (3b) If they disagree, tell them to discuss it, then give you their decision at the next meeting. GOTO (1)
His point being that managers are the least informed (by virtual of organizational pyramids), and therefore the least effective at picking solutions. Build a team that can arrive at consensus, then trust the team.
I know this goes against the normal and people want to attach "right now " value (hours it took reflected on check) but going beyond the call can also give you leverage when your yearly review comes up for example.
What one can do is is deliberately allot time to the team to work on any side-project as long as they are somehow attached to the business. There are ways to do this more organized, for example innovation-weeks or the famous Google-fridays.
Just like those that never have been hacked dont care about security. Or those that have never lost data dont care about backups. Or those who has never had more then 10 simultaneous users dont care about performance. Basically we do stuff in order to avoid pain.
I've been working on it for a few years now and it's REALLY difficult but even the small wins feel very rewarding and are motivating me to refine my comm skills further.
While that's true, considering those incentives and changing them if necessary is part of my boss's job, not mine. My job is only to report the misaligned incentives I perceive to my boss. If my boss isn't able to make me understand his decisions, that's my cue to find a new boss. And I concede, those bosses are rare. I've only had two in twenty years of employment.
It takes time to recognize the qualities you need in a boss to perform well. I know myself well enough in that department to actively look for those qualities. Even to the point where I prefer a less challenging job under the right boss than the perfect job under the wrong leadership.
But there is also a flip-side where I see the opposite happen - especially in startups and VC-funded companies. These companies can take massive losses while at the same time investing huge amounts into elaborate solutions that appear to primarily exist for the purpose of creating impressive bullet points on the resumes of careerist employees. In these companies, even in management, the work seems to be driven by everyone trying to maximize the impact of their own, personal "tour of duty", then making a profitable exit. These incentives are not the same as those of people working at more legacy/boring companies.
Yep, that's one of the things I had in mind when I said "perverse incentives".
To extend this to non-tech examples, failing big companies, like Sears, do not disappear overnight; the decline was in full view for over a decade but ultimately the ship could not be turned. With tech the problem may be even worse; Uber still has not turned a net profit, but with tech investors like to throw money at losing businesses. Some turn around, but that's not guaranteed.
Your bosses optimize for those metrics because it's the one they can communicate higher up on the short time they can get higher ups attention.
If it were because the metric was any good, there wouldn't be so many cases of companies bankrupted by technical and cultural debits pilling up.
That's their problem and not mine, is it?
A good manager doesn't just reflect the lightning bolt to their underlings. They absorb part of the shock and process / transform what they will transfer down below. If they aren't doing that then they aren't managers; they are uneducated opportunists in suits.
> If it were because the metric was any good, there wouldn't be so many cases of companies bankrupted by technical and cultural debits pilling up.
Really well articulated, kudos.
But I'd argue that most 'computer nerds' have pretty deeply seated perfectionism flaws.
To take a simplified example, we tend to want perfect security, and like to prove that we're smarter than each other by understanding complicated attacks.
When it comes to running a business, though, a 10 person startup cannot afford to act like their threat model includes defending from hostile nation state actors willing to do Stuxnet-levels of effort to hack them. If they do that much work on security their product will never get off the ground.
The goal of most companies when it comes to security is never to have perfect security, but to have good enough security to stay out of the headlines.
It is like tradeoffs that have evolved in nature. You don't see organisms that maximize one feature at the expense of everything else. That energy always needs to go into competing concerns.
So sometimes as technical people we fetishize the perfect solution to some problem in the Enterprise, when actually doing that solution would be horrible for the Enterprise due to the costs.
(Of course the flip side is sometimes management only cares about window dressing the company so they can bailout with some golden parachutes and that has nothing to do with running a healthy company -- but not every example of a company not being perfect is due to deeply cynical and perverse incentives like that, but may be entirely rational).
My goal here absolutely was not to turn this sub-thread into a ping-pong of "but managers bad at X" and "but but but programmers bad at Y".
I am very aware of the nuance you introduced and I've been guilty of being a tech perfectionist much more times that I'd be comfortable with sharing. But finally I learned.
(Granted, many haven't and maybe never will. In this regard you do have a solid point.)
> So sometimes as technical people we fetishize the perfect solution to some problem in the Enterprise, when actually doing that solution would be horrible for the Enterprise due to the costs.
Absolutely. Not denying it. It's just that what gets me is the reaction to some of the engineers' flaws is to go to the other extreme.
Which is just as bad state of things. Both extremes are unproductive.
In my point of view, that's how you lose solutions to stay in the comfort zone, and I'm not saying the people whom actually "just obey orders" but those who make them.
As I gain more experience, with age and some wisdom (I hope), I see that most top-down decisions are actually the worst way to decide things, people who are "at the bottom" maybe not understand how a entire system works however they do really knows (and suffer) on how their work is sub-optimal.
Trying to solve every problem top-down manifests as micro-management that beats the morale and initiative out of strong ICs. But on the other hand, trying to address everything bottoms-up leads to local maxima, no standardization across tech or product, and warring factions within the company.
There is real art to this. Being able to grok the incentives and structures of a vertical slice through the org (C-level, VP, Director, Mgr, IC) as well as the tech (Brand, Product, Pages, Components, APIs, Middleware, Storage, Infra) is a rare and extremely valuable talent that allows solving problems that are impenetrable by any traditionally defined role.
That's an unbalanced state of affairs that completely loses very valuable feedback everywhere along the chain.
Part of the job of a manager is to find this perfect balance on the level they are working at. And most don't. They just pass the pressure put on them, down below to their underlings.
https://en.wikipedia.org/wiki/Toyota_Production_System
But somehow, management never accepts this reality. Even the Japanese auto industry is regressing into Taylorism.
I've worked the line twice - first time as a teen looking for any work, the second time as an undercover analyst hired to examine why Lean was failing at a plant, both doing the same type of job: electrical component assembly. I got physical injuries (minor) both times. The majority of the assembly line workers had repetitive stress injuries, including losing fine motor skills and wrist control due to use of impact wrenches and exposure to bad ergonomics. If a human delaminates, you can't glue them back.
Although rational (Taylorism, Management by Objectives, MBO, OKR, Milestones, management by goals ) vs. normative (Lean / Toyoda, human-centric, Agile, humanist, culture ) division of management styles/rhetoric has been proposed, they should perhaps be seen through the prism of Creative Destriction (not disruption, and surprisingly, CD comes from Marx).
In a vulgar approximation, imagine capital-backed entities served by the manager class, which are stressed by short deadlines and performance-tied bonuses and careers. They are constantly shifting basic approximations of solutions and perspectives, without challenging the system.
Give employees more autonomy, and output and managerial control suffer. Instill more rigid control, and risk losing the ability to innovate and "knowledge producing" (Drucker of MBO fame) talent such as programmers.
In an antagonistic system, whatever you come up with has its own roots of destruction on top of built-in conflict (Marx again). Hence the back-and-forth re-framing between "rational" (Taylorism) and normative "culture, baybe, Holocracy!" so fast that today it is a zombie that has both and neither.
You end up with projectification, corporate "culture" that demands the soul and meeting arbitrary "milestones" from employees, but the corporation itself can only guarantee arbitrary termination.
There is a great and influential analysis "Design and Devotion: Surges of Rational and Normative Ideologies of Control in Managerial Discourse" by Barley and Kunda. I would suggest reading "Management fashion" by Abrahamson as well. Both can be found through G.scholar, including no-registration copies.
https://www.jstor.org/stable/2393449 https://journals.aom.org/doi/abs/10.5465/amr.1996.9602161572
(I don't know about worker health problems, and I imagine that poor as Japan was at the time, any empiric data on it would be useless. But, anyway, I don't think the management structure is the correct place to fix that one problem.)
And I'll have to break into your Marxist narrative, but all that was once incredibly successful in a fully capitalist framework. It never became non-competitive, it was only replaced by order of top-down command structures.
The approach I outline can explain and predict why the two Ts rotate, including at Toyota (Toyota going Taylor, or rather normative - rational).
I prefer not to base my experience on what Deming or anyone else wrote, but how their writing relates to real-life practice (though of course as a critic of Taylorism as represented by MBO and other Performance Evaluation rational schools, he is a welcome breath of fresh air).
Have you observed, preferably both as a participant and independent, Deming idealism in a functional real-life system? I have only seen a shift towards projectification and cultural hegemony.
> Have you observed, preferably both as a participant and independent, Deming idealism in a functional real-life system?
As a participant, never. As an independent, we are talking about the mentor of the movement that teached the Japanese management how to go from an industry that didn't produce anything good into the highly developed one that outcompeted everybody all ever the world.
So why the shift to Taylorism at Toyota, the heart of the Toyota system? Why the shift to projectification from life-long employment at Japan? How can one explain chronic injury if workers get to plan and improve the workflow (or are wasted humans not considered waste)?
And the Toyoda principles at the heart of Toyota predate Deming. (Ohno, Taiichi (March 1988), Just-In-Time For Today and Tomorrow, Productivity Press, ISBN 978-0-915299-20-1 )
The list of paradoxes can continue indefinitely, or one can elect to look for the root cause.
well, for the performance pay, Deming is more subtle: its not that it doesn’t work, its that the performance must be something meaningfully under the employees control for performance pay based on it to work (otherwise it can’t influence anything), and it must be a holistic measure of company value (otherwise you get perverse incentives around microoptimizations), and your measure of performance must take into account the degree of uncontrolled variation in the process (otherwise you give false negative and positive signals due to random variation rather than real problems/improvements).
I had this exact same thought recently when reflecting on my behavior in my new role as a "technical product owner". All of it was reflexive, as if I suddenly forgot all of the software engineering knowledge I accumulated over the years and became a deadline-driven cog.
I don't have a solution yet; I think it comes down to that I don't yet speak the same language that people I report to do, and thus I feel like I can't defend my position well enough. It comes with experience, I guess!
There's sadly an inherent conflict of interest between the people doing the job on the ground (programmers) and the rulers (managers).
Your job is to find the middle ground -- not to completely side with your higher-ups.
That would be a good starting point for you IMO.
We as an industry tried the all engineers thing and it didn’t work.
Have you considered the possibility that the boss’ bosses have a point? That the intelligent people you once respected have been convinced rather than intimidated?
It's the organization that shapes the individual, not the other way around. Changing a cog in an existing gear system only works if the cog is of a particular shape, and it will get chafed and dented if not sufficiently so. If the cog is too different, it will break and be replaced again.
Occam's razor says that if many different people fail within the same organizational structure, the problem is not with those people.
And as said in other comments, for some companies and businesses they are right indeed.
But not in programming / IT in general. At least not where I worked (and where many of my former colleagues worked).
It's all optimizing for short-term and never the long-term. And I have seen people playing the long game gaining a lot so I also know I am not imagining it.
Make it 75% short-term objective and give the other 25% to longer-term planning and/or simply playing with ideas and I'll be very happy to work in such a place.
I am not a fanatic -- and most programmers are actually quite understanding (if a bit too timid sometimes) people.
We just want the pendulum to not be on one of the sides 100% of the time. That's it really.
Example of when this was tried?
> if a solution exists today, and it has yet to be replaced, it's at least possible that it's over all the best solution, and the reason you're not seeing that is because of a lack of understanding.
And once you build mastery of $fwk/$lib/$tool, it's deprecated and you migrate to another one. GOTO START
Conversely, it's surprisingly difficult to get engineers to master things they aren't intrinsically interested in. We've had a stable tech stack and core architecture for 4+ years and one of my major challenges is to stop employees constantly trying to introduce $new/$shiny or major refactor X because it wasn't built how they personally would have done it and get them to just learn and understand the stack we already have - which addresses all our needs at most 5% less optimally than $new/$shiny.
If people have a good social safety net and a good job security, the depth of their skills improves by a lot.
Management and owners are a far from perfect group that make plenty of bad strategic decisions for a host of reasons, but they also have to deal with the real/perceived constraints of time, budget, market, competition, etc. that are easy to not appreciate when you are focused on the design/build portion of the business.
Then you look a little deeper and realise most of them are pretending, they're photoshopping their selfies, renting their expensive cars for a day and taking their selfies on other peoples property.
HN can be a bit like that, you can feel completely inadequate compared to these super-geniuses doing everything perfectly, when really you're doing ok.
HN attracts a broad range of ability, but generally upvotes the smartest content. So if you sample from “upvoted HN articles and comments”, the content you read is heavily biased toward things written by unusually smart people. But there’s a range.
By contrast, most companies will attract and hire people like their current employees. So the variance at any particular company is much smaller than in the general pool. Everyone ends up working alongside people like them.
So if you work at a big bank or something, you probably don’t interact with many people like the super geniuses who write interesting articles that get upvoted a lot on HN. They’re over represented amongst HN content, but most programmers are average and getting by just fine. And remember, hotshots are equally ungrounded. Lots of good engineers you meet at Google were hired at straight out of collage. They have no idea how the sausage is made anywhere else. Lots of folks here don’t have your experience. They have no idea what it takes to do software at a company that sees their job as a cost centre. Or what it takes to get good work done in spite of political pressure to stagnate.
Having a variety of voices gives all of us something to learn and something to teach.
We see the effects of that throughout our industry and yet it's never publicly acknowledged.
> And remember, hotshots are equally ungrounded. Lots of good engineers you meet at Google were hired at straight out of college. They have no idea how the sausage is made anywhere else.
One of the most eye opening experience one can do is 3x the compensation for a software role and see what caliber of engineers it attracts. I remember one company who did that for college hires and they were shocked. They had been whining for a while about the "talent shortage" and that it was hard finding folks in the local market. Turns out the folks they really wanted to hire were there all along, just invisible.
Does HN really upvote the “smartest” content? Citation needed, please.
The amount of pretense and smug here isn't any less about its domain than any other self-selected community.
HN is a financially-oriented tribe. It's like in the Bitcoin community. Only the pro-Bitcoin content gets upvoted and anti-Bitcoin content gets downvoted. The smartness of the content hardly matters at all. Sometimes the smartest content is at the bottom of the list.
Usually, I read both the top and bottom parts of HN then I get some of the best arguments on both sides.
Also, user ailmanki (also last page) said:
>> Every system requires sooner or later another system on top. https://en.m.wikipedia.org/wiki/Chaos_theory
That would explain what is happening.
The user narrator (also last page) also raises an interesting point:
>> I'm surprised this article didn't mention test driven development for building large pieces of software!
^ He then makes a good case for TDD.
TBH I don't see much improvement in quality at all reading the top comments. Some are dead wrong, for example, the user snidane says (which is/was in the top three on the first page if you ignore nested sub-comments):
>> The tooling is simply not there, so every software project keeps pushing the boundary of what is possible in its own unique fragile way.
Not only is that comment dead wrong (the tooling is definitely there, I've worked on some of these scalability open source tools), it contradicts another comment just above it (by user the_duke) which received just a few more votes:
>> At scale software stops being a technology problem and becomes a people problem. And groups of humans don't scale.
Probably not; across both the world as a whole and the profession specifically, a power law distribution is a lot more believable.
Even in a particular firm, its probably closer to a power law, or maybe an offset bell-like curve where the median is above the mode and there is a much longer high tail, then a common bell curve.
The more complex solution is to develop a worldview where you only compete against yourself, i.e. is what I'm doing now going to make me a better person in X time.
It's up to each person to decide for themselves what better means, it could be an emotional thing "will it make me more empathetic?" or a financial thing "will this allow me to earn more money?" or something else "will it make me a better programmer, chess player, cyclist, *happier*?".
For all the size of the world and its complexity it collapses down to a local optimisation problem for you as a person.
Even if everyone were to post the mundane it wouldn't generally be what would get upvoted or liked in a given medium enough to counter the successes.
And on HN, comments are filled with insight backed up by decades of deep experience. But the Perl expert in one thread is unlikely to be the Russian historian in the other. There are few masters-of-all-trades (though they do exist, as if to inspire and mock us). Not to mention the majority of readers whose experience is rarely relevant enough to comment.
However we are humans, only recently evolve from something a bit like an ape. Hampered by emotions and constant fits of irrationality. Actually achieving the correct behaviors that we can easily imagine is very hard and very rare.
So we are correct in our criticisms but could be more calm and understanding about the fact that everything is terrible, and strive to make even very small improvements and enjoy those.
I don't believe this is true, an average person can easily imagine a local maxima, but everyone's local maxima is different.
For example it might be very convenient for person A if the licensing office were open 24 hours but probably not so convenient for person B who would have to cover the night shift every other week or person C whose taxes would need to pay for it. And so on.
Nearly every sub-optimality from one perspective is an optimality from another.
I'm willing to assume that this is the best of all possible worlds, that everybody did the best they could in the moment. But having all that history behind us gives us lessons such that tomorrow's best possible world is surely better than today's.
I agree that we should have less technical arrogance and jackassery in the future. But that emotional immaturity is also part of today's best possible world.
[1] https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
- Usually, the "right way" to do something is only apparent halfway through doing that thing, or after you finished that thing.
- There's rarely time to redo things with benefit of hindsight, because the priority is always to work on business goals first.
That's how things were everywhere I worked or seen, so I believe this is likely a general phenomenon. But the consequence of that is strong path dependence. It's not that using Kubernetes makes you a moron or a smart person. It's that somebody already deployed Kubernetes for a project that's too simple for it (or they were too inexperienced), but business pressure makes it impossible to spend a couple of weeks undoing it, so everyone is stuck with the pain. Perhaps the reason for the initial Kubernetes deployment was because it was the fastest way to fix some other issue, and the company could not allocate enough time for engineers to do it right.
To be clear, this isn't me ranting about "stupid managers with their priorities". Pursuing business goals is the raison d'être of a software company (it's pretty much a tautology). I'm just saying, it's hard to improve things without lots of slack, and slack is a competitive disadvantage.
Perhaps another facet to this is: business lifecycle is too short for software lifecycle. If you were to spend time on redoing things properly, by the time you were done, you'd be out of business.
Think of it like gradient descent. The location you end up is the best location in the neighborhood of your starting position, but it's almost certainly a local minimum, and if you started over from a different initial position there's a good chance you'd find a lower minimum.
Since we can't avoid thinking in generalizations, and they're usually false, the only option is to accept contingent thinking. Sometimes, respecting "the way things are" is the right way. Sometimes, rejecting the way things are is the right way. It's often how things get better. There isn't a true "way" you can live by in all circumstances.
There are hints though. If you're using disrespect/challenge to write a good essay (like this author) or to try and change something.... rejecting "the way things are" might be good. If you're just whining, probably not.
Humility good. Complacency bad. These are definitions, not value statements. They're not necessarily contradictory, if you care about such things... but they can have a Hillel/Shamai^ dynamic to them. Sometimes, an adversarial discussion like "Kubernetes" vs "Learn Tow to Sysadmin, You Moron" is enlightening. Sometimes it's no-it-all asholery. I don't think there are universal rules governing the distinction.
In any case, I don't think this author is being "terrible." He does recognize that scaling is a problem that he doesn't fully understand and meanders through a lot of possible reasons. None of it is mean. The title is a little click-bait, but I don't think it's a foul. He's quite respectful, in fact.
^Like political left/right, but more bearded.
It's like applying principles like DRY. If you push that principle to the extreme, your code will be shit. DRY is a good principle, but not a rule to follow blindly.
Basically he's investigating and goes and talks to the software guys and quickly concludes everything is awesome, and moves onto investigating hardware.
I was initially taken aback by this part. But he later he wrote:
"To summarize, then, the computer software checking system is of highest quality. There appears to be no process of gradually fooling oneself while degrading standards, the process so characteristic of the solid rocket booster and space shuttle main engine safety systems."
It makes sense, I mean they can fly simulations over and over before the shuttle is even built, let alone launched.
[1] The first book was "Surely You're Joking Mr Feynman", the second with the challenger investigation was, "What do you care what other people think?"
Large systems in general are hard to refactor. Our impulse in tech is to always consider the refactor because we see how in other systems a refactor is impossible or takes blood (our governments and countries, institutions like education/healthcare). Those in tech have seen many systems to compare against (what went wrong, what went good, even on the most basic projects).
The first thing they tell you about capitalism is that humans haven’t encountered a better system, which is true. Make that argument to a programmer. They either saw a shittier system, a better one, a more fitting one, a proper one, a terrible one, etc. You pretty much can’t tell us anything because we’ve seen it somewhere.
Being content with systems is bad for all of us. Being content with your life is good for all of us.
In my opinion, what makes most of the wrongs we see is that computing is very young and we haven't had the time to set up half decent solutions for anything.
There is a huge demand for any solution, because a bad solution is better than no solution. The Kubernetes vs sysadmin is like the Diogenes story. There are two versions. In one of them someone tells Diogenes "if you praised the king, you wouldn't need to eat lentils" and he replied "if you ate lentils you wouldn't need to praise the king". In the other version it's just the same story only Diogenes talks first.
I don't like lentils. I don't like to praise the king either. Both are terrible solutions, but while we have kingpraiseless burgers, we need to choose something that somehow works.
It also doesn’t have to be the best, and probably isn’t – the space of all possible bit strings large enough to encode Kubernetes is quite big. Being “good enough” is sufficient, and often the discussion really comes down to differing opinions on what that means. These is no uniquely and clearly defined objective function here. People need to stop thinking that theirs is the one and only.
Precisely. And, building the truly best solution, is often a mistake, in that it can take pointlessly long.
Good enough is good enough, and others might find things to improve, and be correct that it'd been better in their way — the important thing is instead to realize that actually making any improvement one might have found, can be far down on the priority list. Maybe there'll always be other more important things to do, so it'll never happen.
> > "at least possible that it's over all the best solution"
can be rewritten as:
> > "at least possible that it's a good enough solution"
And maybe it can make sense to make improvement suggestions, and then, when the others say "yea but there's too much else to do", then, ok, maybe forget about it and be happy anyway.
I've been on both sides of this, and look back and cringe when I think about projects I've criticized before trying to understand them. I've also had the experience of being early at a startup and having later employees come in and constantly complain about how sub optimal everything is. The problem is they're missing the time crunch that was in place, and the fact that if subpar solutions weren't used the company would have never gotten to market and they would have never gotten a job there. Software isn't created in a vaccuum.
Even the best possible solution is only best in the time it was created, and because it's good it will get entrenched and keep getting used, even when the constraints it was created in no longer apply even remotely and it's actually a very suboptimal solution given new constraints.
Everything from programming languages, OS kernels, file systems, distributed computing frameworks - soo much of it has ideas and solutions that are technically better but it's hard to overcome the inertia
I'm sat in front of a machine that is literally billions of times faster and many orders of magnitude more powerful in every other axis (storage, bandwidth).
And yet, strip away the fancy IDE, the container tooling and it's all still my brain, some text on a screen and my understanding of the problem.
Neural networks were a hypothetical approach, nowadays you can rent a ML pipeline for a couple of bucks and download prebuilt models.
So taking an approach from that era (for example C or UNIX) has obvious legacy baggage and isn't optimal in modern context but is still used because of inertia.
Also at this point it's less about your brain and understanding and more about being able to search and mash together. It's not just having a fancy IDE, internet and search fundamentally changed how you learn and solve problems.
The primitives we use are at the wrong level of abstraction for the problems we are solving but..well I haven't seen anyone come up with ones better enough they displace the existing solutions.
https://en.m.wikipedia.org/wiki/Pareto_efficiency
https://en.m.wikipedia.org/wiki/There_ain't_no_such_thing_as...
Either way might be a better choice for a given situation and due to lack of information and changing environments carry their own risks.
If you don't know what these reasons are, it is hard to know with certainty that they no longer apply.
see above reference to Chesterton's fence.
Both forces exist, the important part is to balance them properly.
Ah yes, the novelty seeking magpie developer
Isn't this line of thought disproven by a single improvement? People before the improvement could have argued along the same lines and then be proven wrong.
Maybe the field of software can really mature only when looking for subtractive solutions become part of the computing culture.
Agree. See: https://fs.blog/2020/03/chestertons-fence/
That said, we may not get far if no one makes an attempt to tear down those fences. Tech is like art in that respect: Lets practitioners experiment like no other engineering discipline.
Ideally you want 'seasoned vets' for whom this level of engineering/development is old-hat and have them churn out a solid product that handles all the edge cases that you only know about when you have a long-term experience with the technology/domain.
Still, looking back we can see how software solutions were not optimal for their age, and how amazing things can be coaxed out of old hardware using new insights. It would be pretty remarkable that precisely now is when we finally achieved optimal software. More likely, we’re still getting it wrong, and this is just one more step along the line.
The truth can be a little of both: yes, we can do better than what exists now, but we’re not guaranteed to unless we understand what came before.
The thing is, most software projects have an inherent complexity that can’t be reduced. This gives an implicit limit on what can be reasonably created by humans.
And most software is insanely complex — simply because otherwise they would not be useful in many cases. So writing software from scratch takes pretty much the same amount of time as it did 10 or 20 years ago. Yeah performance is much better both in hardware and in software (runtime, compiler), but eg. desktop app development may have become less productive since. All in all, there is No Silver Bullets, and there haven’t been since either. The only thing there is is incorporating already existing software.
There’s also the case where you or someone is hired to offer a fresh perspective on an existing system. After looking at it if your solution is “it looks great the way it is”. The person who hired you would think “why the hell did I even hire this guy?”
So even though you know the current system it’s a good system you try to propose a solution just to show value. That it was worth it to hire you.
This is true of any "real world" subset, vs its online outlets; HN may just be more niche than some.
K8s is just a container orchestrator. And containers are just virtual machines.
> containers are just virtual machines
I think this part is false though. Containers are, well, contained processes with contained storage. No simulated hardware like VM implies
Unless you're using something like PCIe passthrough to give raw hardware access to a VM.
Gottfried Leibniz suffered no small amount of flak for his conclusion that the reason the world looks the way it does is because it's already "the best of all possible worlds": you may think you see an improvement, but you lack divine understanding and therefore you don't see how it would actually make things worse.
While this is in my opinion a silly idea, I think most people who work in tech could use a bit of humility influenced by this line of thought: if a solution exists today, and it has yet to be replaced, it's at least possible that it's over all the best solution, and the reason you're not seeing that is because of a lack of understanding.
Of course this is not always true, but if nothing else it would lead to more interesting discussions than those stemming from someone saying "if you're not using Kubernetes you're a moron" and another replying "learn how to sysadmin and you'll realize you don't need Kubernetes in the first place".