Deregulation and the general decay of governance are the major drivers but it should also be pointed out that inequality is a huge driver of gambling. Charlie Munger had a whole speech once about how dumb poor people are for playing the lottery, but thats spoken like a true rich person - from the poor persons perspective, the lottery is one of the only realistic ways out of your current predicament, saving $5 a week will do nothing and just get eaten up elsewhere.
No because small businesses arent hiring ad agencies who spent years studying psychology in order to manipulate people into doing what the company wants, not what the person wants. This is very much an issue of scale
This is irrelevant to what OP said which is that it this should be the default. One anecdote of "with effort and technical expertise I returned the appliance to a workable state" doesn't mean things are ok.
edit: Im not trying to be snarky, I think your reply was genuinely trying to be helpful, but its not ok that we're being sold this crap
I agree it should be the default, but this TV was readily placed into dumb mode at first powerup. Set your country & language, select dumb mode ("Basic TV"), skip WiFi and most would be satisfied with the result.
Some effort's needed to clean up the homescreen, but you never need to see it. Hand your grandparents a basic programmable remote without extras like the home button. They should be good to go.
there are upsides but I dont know if its net upside. In this particular example, communicating by text - letter writing has existed for millenia and has arguably degraded considerably in this age of instant messaging
100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing
ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.
Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.
The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.
It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.
Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.
I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.
I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.
The good news if you take 2 years to ship the system "properly" then you won't have to re-factor it because the company went out of business or that product was too late to market.
There is a phrase "million dollar problems". You do stuff at your startup that will take a million dollars to fix because it doesn't scale.
The point is that if your startup doesn't get to that scale then it doesn't matter. If you startup does reach that scale then you have plenty of money/people to spend a million dollars fixing it.
Replies like yours gloss over nuance. I don't mind prioritizing time to market as a programmer; I am not clueless, I understand that imperfect product that pours money into my employer's coffers is infinitely better than it sinking and we all get fired out of necessity.
My problem comes from the fact that the leadership _never_ compromises and never allows us to avoid at least some crises that are extremely easy to foresee (and have happened like clockwork in 95% of the cases where I or other colleagues have predicted them).
Again, sure, let's go to market and start making sales. I completely agree. But scolding a dev for fixing a DB schema anomaly that slows down ~40% of _all_ feature requests and that it took him the grand day or two to do so, is not just myopic. It's moronic.
---
Even shorter / TL;DR version: If the balance of power was 80% leadership and 20% engineers, I'd still be completely OK with that. But wherever I go the "balance" of power is more like 99% leadership and 1% engineers (and that's only when stuff really has hit the fan; they'd take away that last one percent as well if they could).
That is the problem. There's no balance. No compromise. Just people barking orders.
It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app.
I don’t like all the fantasy about “just talk to the customers” - nah it is not just, it is super hard to get their time.
You can’t often demote them because usually the people responsible for bad initial design decisions left the company years ago with a desperate need to go and start a new mess somewhere else.
All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.
> i think people that were promoted for building systems that turned out bad, should be demoted
Nope, in the same vein of "lording" over others, they become the expert of knowledge of bullshit. The environments that allow such behavior have already engrained reward of such behavior.
> 100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing
I moved teams a few years ago, and the very first thing I did was push hard to re-structure the schema they (sorry, pals) slapped together without much thought. It took some fair amount of arguing, and maybe a PR that I had reviewed by only a single person and pushed through because it's easier to ask for forgiveness, but we got there in the end.
Luckily, we were able to do this before the code started hitting production traffic; it would have been significantly more difficult to fix once we started getting real data into the system.
> language models are more likely to suggest that speakers of [African American English] be assigned less-prestigious jobs, be convicted of crimes and be sentenced to death.
This one is just so extra insidious to me, because it can happen even when a well-meaning human has already "sanitized" overt references to race/ethnicity, because the model is just that good at learning (bad but real) signals in the source data.
Family law judges, in my small experience, are so uninterested in the basic facts of a case that I would actually trust an LLM to do a better job. Not quite what you mean, but maybe there is a silver lining.
We are already (in the US) living in a system of soft social-credit scores administered by ad tech firms and non-profits. So “the algorithms says you’re guilty” has already been happening in less dramatic ways.
reply