19 ms·

My seatbelt rule for judgment

487 points by dguo 5y ago

cobertos 5y ago
I think the harder part is determining how much you actually know about something, to know how much you can judge. My default nowadays is I never know enough, even in the fields I'm specialized in. Part of it is I think just a limit of how much information I can accurately refer to/pull up in my brain at any given time too.
puffoflogic 5y ago
Sometimes the engineers are "too" clever. In my car, seatbelts have an additional mechanism which causes them to stop if the car is braking (with a certain acceleration, perhaps, or actual detection of the brake - I haven't determined). This seems very sensible until you live near an intersection which is not at right angles, which requires the driver to lean forward upon arrival at the intersection in order to look around the A pillar for oncoming traffic. What's interesting is that I now know something that the engineers designing the system should have known but apparently didn't, or knew and didn't care about. So sometimes (or much of the time?) users do know something the engineers don't.
- mlyle 5y ago
  > In my car, seatbelts have an additional mechanism which causes them to stop if the car is braking (with a certain acceleration, perhaps, or actual detection of the brake - I haven't determined). This seems very sensible until you live near an intersection which is not at right angles, which requires the driver to lean forward upon arrival at the intersection in order to look around the A pillar for oncoming traffic. This is a tradeoff. You can have a pure pay-out based locking retractor (centrifugal clutch). Or you can have a pendulum-based mechanism, or a combination of the two. If you have the pendulum-based one, you'll be less likely to false positive based on the movement of the occupant but more likely to false positive based on deceleration of the vehicle. The combination is best, because you can be relatively insensitive to individually occupant movement and vehicle deceleration and still actuate reliably in a crash. But it still will false positive. In any case, "not annoying the user" is prioritized beneath "saving lives in a crash" by regulators, and hence the auto industry. I'm guessing you brake rather abruptly in this situation if this is something you routinely encounter.
  - prh8 5y ago
    I recently upgraded vehicles from a 2009 to a current one with all the new safety features. In my research I read lots of complaints about emergency/auto braking activating too much and other features of the car stepping in to assist the driver. Since switching vehicles, on the incredibly rare occasions something has activated, it's always been valid and a quicker reaction than my own. Your tag line reminds me of all the times I've pondered how bad these complaining drivers must be.
    - puffoflogic 5y ago
      Odd that you should mention this: tonight my car decided it needed to ABS brake (very alarming when unexpected) while I was reversing at less than 5 mph, apparently because a car >20 feet away was turning into a parking spot, well out of my path of travel. The car proudly informed me it had averted a collision, when in fact the application of the brake was unnecessarily violent enough that it quite possibly did damage on its own, and could have caused injury. Progress!
- jacobr1 5y ago
  This is one of the things I love about open source software. When I want or need to, I can attempt to modify something to better suit the behavior I want. Some fraction of the time it ends up being too much effort, or I learn that my idea didn't take into account some secondary factor. But often enough I make can make a change, and even maybe contribute it back. I'd love to see more open-source with physical product - 3D printing seems like a good start.
- frosted-flakes 5y ago
  I think the auto-locking is pendulum-based. I've noticed that on steep slopes the seatbelt tends to lock very easily.
quickthrower2 5y ago
Then don't judge anything as 'stupidly designed'. What does that mean? Just say "I think the design flaw is XYZ". If I find a stupidly designed product, it is often because it was the cheap option. Spending more saves money in the long run. Water bottles spring to mind - most of them leak or get damaged by dish-washing sooner or later. Spending $20 on a water bottle is cheaper than spending $5 ten times. Although a high price isn't a guarantee of quality either!
- chrisseaton 5y ago
  > If I find a stupidly designed product, it is often because it was the cheap option. Well then they weren't being stupid - they were optimising for short-term cost. That's not stupidity - it's a tradeoff.
  - quickthrower2 5y ago
    Yes I should have airquoted "stupid" there!
  - jacobr1 5y ago
    Right, and then we bought the thing. Who is the stupid one now ;)
- notapenny 5y ago
  "I think" sums it up nicely. It's not a fact, its your opinion. Maybe it was actually designed stupidly, or maybe someone just made a different choice given a different set of circumstances.
csours 5y ago
When I was a kid I decided that test pilots must be idiots. My logic: Being a test pilot is dangerous. Only idiots do dangerous things. Therefore test pilots must be idiots. Later (embarrassingly later) I learned that many test pilots were also engineers. This made me reconsider my opinion. I learned to be very careful when judging intelligence, and also the limits of inference.
- nradov 5y ago
  Intelligence is generally orthogonal to physical risk tolerance. I don't know why anyone would conflate the two.
- scotty79 5y ago
  Being an idiot us a varied and nuanced thing. Plenty of very intelligent people are idiots in one way or another. Being drawn to excessively risky behavior is just one aspect of idiocy.
- TremendousJudge 5y ago
  >This made me reconsider my opinion Why? Plenty of engineers are complete idiots in many levels.
  - csours 5y ago
    I think these comments highlight to me how difficult it is to reason and talk about intelligence. Intelligence and stupidity suffer from fundamental attribution error. The main thing I learned from reflecting on my error is that making any sweeping conclusions about people is foolhardy. So yes, engineers can be idiots, test pilots can be idiots, smart people can decide to do dangerous things on purpose, idiots can do dangerous things on purpose, idiots can do dangerous things on accident, so on to absurdity. Putting people in buckets based on some observed criteria is rarely advisable; everyone's story is different.
unityByFreedom 5y ago
Learning often involves making mistakes, speaking out, etc. Don't be afraid to assert yourself.
- MPSimmons 5y ago
  I would add the caveat that, when doing so, be aware of, and vocalize, your current state of familiarity. Also, I find that asking questions leads to better outcomes than making statements.
  - city41 5y ago
    I agree in general. But at least on the internet I find an incorrect claim will be corrected more often than a question is answered.
  - unityByFreedom 5y ago
    Questions imply some unfamiliarity but sure that may be helpful if supplied.
codegeek 5y ago
Kinda related. When I was like 11-12ish, I remember waiting in my Dad's car with my younger brother when he went into a store for like 20 mins. We started playing with the steering wheel and then suddenly I couldn't turn it anymore. It was locked. We were shit scared that we broke something and how will Dad drive the car now ? I remember being quiet when my Dad got back to the car (I had warned my younger brother to deny that we did anything) and the moment he put the key in ignition, boom. I face palmed in my mind and learned how steering wheel locking works :)
- onpensionsterm 5y ago
  I think there are a lot of people who never learnt about this and will only learn after an embarrassing phonecall to a recovery company.
irrational 5y ago
> An overwhelming feeling of stupidity hit me almost as fast. Nine-year-old me was not in fact smarter than Toyota engineers. It’s unfortunate how many people never come to this realization.
- throwaway0a5e 5y ago
  I think we have the opposite problem too. People ascribe way too much intentional design to shit they don't understand even where no such intentional design exists. Like 99% of the stuff you encounter on a daily basis is how it is because of some 3-way trade between aesthetically pleasing, the economic realities of producing that object and "how they've always been." It is not engineered for performance in the slightest other than some basic "yeah that should do" napkin analysis.
  - vlovich123 5y ago
    Or where the original constraints made sense at the time but they’ve been forgotten and all we’re left with is the end product.
    - timClicks 5y ago
      I think of this whenever I see coat hooks with dual hooks, the top one extending further. I've always assumed that they were designed when people regularly wore hats.
      - maccard 5y ago
        In my house, we use the bottom hooks for "outdoor base" and the longer top hooks for "outdoor top layer". It means you're never putting dry base layers on top of a wet waterproof layer. But your explanation makes _way_ more sense.
      - vineyardmike 5y ago
        I think it also provides value for people to hang purses. But as other comments mention they found utility in it through layering. It may have been for hats once, but it’s certainly kept around because people found new uses.
TheOtherHobbes 5y ago
How do you know how much you don't know? I'd suggest there's a difference between "I don't understand how this is supposed to work" to "I do understand how this is supposed to work, and I don't understand why it isn't working." Seat belt story seems to be Type 1. But what if a lot of "stupid" design decisions are actually Type 2? And the reasons may or may not be good - somewhere on a scale from real budget and/or time constraints, lack of insight, indifference, penny pinching economics, to passive aggressive user hostility. When Apple removed Magsafe no doubt there were perfectly good internal justifications for that decision. But ultimately the people outside the company who said it was a poor move from a user POV turned out to be right.
- grp000 5y ago
  I think it's a case of defining what you know, and asking questions for what you don't know. But, of course that's easier said than done. Maybe you chase after a red herring, maybe you ask the wrong questions. But I think asking the right questions comes from expert understanding of the fundamentals of anything, which is really hard, maybe for a lot of new fields, impossible because no one has established fundamentals, unless you're really smart. Maybe you permute the thing, or its joined with another thing, so it really becomes it own new thing. I personally hate the non-magsafe charger because I trip over it and yank the laptop around, but I can see the trade off in being able to use a single charger for everything. Because of that, I see the magsafe issue being a permutation, because by changing the environment that laptop chargers operate in, with the addition of usb-c, you've changed the game.
  - deleted 5y ago
    [deleted]
  - CRConrad 5y ago
    > I personally hate the non-magsafe charger because I trip over it and yank the laptop around, but I can see the trade off in being able to use a single charger for everything. So why the *ck didn't they just include a little bit of magsafe-to-USB-C cable with the phones, and keep the wall-plug-to-magsafe charger? Then they could have transitioned the laptops over to USB-C at any time without inconveniencing users, added the safety of magsafe to the phones, and allowed users to mix-and-match chargers and cables. But no, that's exactly what they didn't do. Funny that, for this vaunted "customer-centric" company...
emehrkay 5y ago
I feel that I made the transition from jr to mid level developer when I was able to come into some new code and judge it, instantly pointing out what was wrong and how it could be improved, and how it should've been built. I feel that I went from mid to senior when I would enter that same situation and try to understand the why behind the code (even though I probably still thought it was poorly architected) before passing judgement or trying to "fix" it with a refactor.
- nostrademons 5y ago
  You transition from senior to manager when you first try to understand the importance of the code to the business and whether anyone will ever touch it before bothering to understand the code.
  - ThalesX 5y ago
    Your short comment really triggered my management PTSD. I wrote a huge ass post but decided to delete it and just summarize: * Senior tradesman -> manager is not a natural transition; * Senior tradesmen take business into account without needing to transition; * Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious. I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application. I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
    - thyrsus 5y ago
      Why does Dunning-Kruger come to mind?
      - CRConrad 5y ago
        On the part of the GP, or the management caste?
Tehdasi 5y ago
The reverse is also quite true. You can get a thing which just seems too slow/fiddly/buggy/etc, but it's in an area where you are unfamiliar with, so you pass it off as just your misunderstanding of the thing. Whenever you investigate more on it, you find that there are ways ppl use it that avoid the problems that you are having with it, or that pieces of the thing make a certain amount of sense the way they are. Then as you learn more you begin to understand the underlying reason that the thing is the way it is, and you realise that it's not you. Poor decisions were made in the design of the thing initially (or at least decisions which once valued the right things, but now do not), and have become baked into the DNA of the thing so it could not be fixed without major changes that nobody wants to do. It's at that point, you realize that the emperor has no clothes, and certainly didn't deserve the benefit of the doubt. I find this is particularly the case when the design flaw is particularly bad, the developers end up adding complexity to work around the flaw, which has the effect of hiding the flaw, making it alot less obvious to the novice.
burlesona 5y ago
Obligatory: be careful you’re not standing atop Mount Stupid. https://www.smbc-comics.com/?id=2475 https://www.smbc-comics.com/?id=2475
justnotworthit 5y ago
> My willingness to judge something should be proportional to how much I know about it. I'd also add: ...should be proportional to my need to or benefit from passing judgement. Postpone judgement and you observe more. It's counterproductive to stamp everything in life "good/bad" "dumb/smart" "friend/foe" as soon as possible.
sturza 5y ago
I drew a similar conclusion about people's observations, in general: the faster the conclusion the less knowledge about the topic - which is similar to Kahneman's system 1(intuition).
helsinkiandrew 5y ago
It's always terrified me how one experience or one anecdote can completely change a persons view on a topic and make them blind to the overwhelming evidence they've previously experienced and accepted (and ignore future evidence) A single rude salesperson and they won't step foot in the entire chain, a bad cop or doctor and the whole police force or medical establishment is corrupt. Listen to a politician giving a speech and people become lifelong supporters even when their policies change radically. There is something deeply embedded in the human mind that makes us very susceptible to some stories - against all evidence, if it fits our preconceived perception or coincides with something in our memory.
- 8192kjshad09- 5y ago
  I think there is an innate human bias to weight negative experiences more strongly than positive ones. For example, I will forget a compliment a day later, but I will never forget that one time I was harshly criticized. It makes sense from an evolutionary perspective as well, the worst possible experience (death) is far worse than the best possible experience (food,sex,comfort,etc). Re: your example about politics. Politicans explot this by talking about how bad the others are, rather than how good they are.
- andrei_says_ 5y ago
  > a bad cop or doctor and the whole police force or medical establishment is corrupt. I’m not sure these are the greatest examples. If “good” cops stand by watching “bad” cops abusing their position including stealing, lying, assaulting, murdering or torturing people, then maybe we are speaking of institutional issues blurring the lines between behaviors typical for organized crime and ones observed with the police force. Especially if whole police teams threaten to stop doing their jobs if their insanely inflated budgets get reduced. Of course there are good cops. You can often hear about them getting pushed out of the police force for reporting the crimes of the bad ones. If doctors are allowed 20 minutes per patient visit and are constantly pressured to prescribe medication and procedures for profit then we might have an issue there, too.
  - virgilp 5y ago
halikular 5y ago
Like how most things is for a reason. Especially within rigorous domains such as engineering, math, physics and programming. It is not to be expected in BS vendors safe space in subjects like politics, economics and social science.
- jevgeni 5y ago
  Tell me you haven't touched economics as a science, without telling me you haven't touched economics as a science.
  - CRConrad 5y ago
    I have, and I can see GP's point.
    - jevgeni 5y ago
      Then you can also see that what GP implies about econ academic practice applies at most to pop science articles and financial analysts.
      - CRConrad 5y ago
        No.
gyulai 5y ago
One particularly prominent special case of this is when one engineer makes a snap judgment about another engineer's work that it's "overcomplicated". Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution. I feel like, at this point in my career, and in the specific context where I work, this has now become the bottleneck to my career progress. The problem is: It works as a self-fulfilling prophecy based on the fallacies of social proof and fundamental attribution error. People reach for the snap judgment "this is overcomplicated" because they expect me to just be the kind of person who just overcomplicates things. And they feel easily justified in that judgment given that other people also tend to make that judgment about me. This means they budget even less time for trying to understand the complexities in the problems I solve before reaching for the easy judgment of "this is overcomplicated". So: The guy who always overcomplicates things, thus draining the company's cognitive resource needlessly and just generally being a nuisance, ends up looking much the same from the outside as the guy who could just be a company's strongest engineering asset. He could be the guy to put the company ahead of the competition, always understanding the engineering problems more deeply and solving them more thoroughly than others, including the competition, in a way that the competition can't easily replicate. -- ...if only the people tasked with passing judgment could overcome biased and lazy decision-making.
- alkonaut 5y ago
  > Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution. This is often the case, but even more often I think my annoyance with the overcomplexity of the code isn't that the code solves the problem in a too complex way, but that the code solves a much too complex problem. Most of my job as a developer is fighting complexity. Doing it in code is an uphill battle. If you have to solve complex problems with non-complex code, you are fighting a losing battle. The struggle to keep complexity out of the code happens in the dialogue with stakeholders (Project managers, customers, team etc). Now, there are of course cases where the conclusion after the complexity debate might have been that "yes, the requirement is for the program behavior to really be this complex, meaning the complexity of the code is required". But this is extremely rare. The reason I get annoyed when seeing complex code is because through the decades I have learned that almost invariably, someone took a complex requirement at face value and implemented a complex solution to the requirement.
spullara 5y ago
If you are a 9-yr old developer, this makes a lot of sense. Most people in a professional situation are closer in skill level and this kind of disparity indicates a lack discipline when hiring. I see it all the time so it is not unusual.
foreigner 5y ago
A corollary to this that I read somewhere: we tend to judge other's actions by the outcome, but our own actions by our intent.
Scarblac 5y ago
I first tried out the WWW when it had fewer than 2000 pages, and didn't see the point. My constant reminder that if something initially looks useless to me, it's probably me.
captainmuon 5y ago
I see your Chesterton's fence and raise a Gell-Mann amnesia. Yes, the phenomenon in the article is real, but the opposite is also true. Many times I have seen something, thought it is silly, wrong, or could be done better, but I reserved judgement because I didn't know much about the subject. And then in the end, I was right. Be it some technical choice at work that had obvious flaws. Or when we were renovating our house and as a layperson I noticed a serious problem the experts didn't see. Or when I was reading about poststructuralism, or critical theory at university. I had a feeling it was just a lot of word games around a couple important ideas - then I put in the work and read books and went to courses, and yupp, that was basically true. Looking at it from the other side, as an expert on some topics, I know there are a lot of things we do that are not justified by the "subject matter" but we just do them because we have always been doing them, or because a pointy haired boss decided so. Or we have operational blindness and can't notice the flaws anymore.
jonpalmisc 5y ago
For those who just want to see the rule: > My willingness to judge something should be proportional to how much I know about it. I think it’s a sound rule. Going to try to remind myself of this more.
- jimkleiber 5y ago
  I wish the author would have added this last sentence to the rule: > There’s so much I don’t know. To become: "My willingness to judge something should be proportional to how much I know about it and there’s so much I don’t know."
Graffur 5y ago
I feel like this is captured in the popular wisdom: "Don't jump to conclusions"
- Medicineguy 5y ago
  I like the human-relatable story behind it. I think many kids experience a similar situation that sparks this life lesson. My younger self condemned my father's printer as "dumb" for printing a multi-page print job in reverse order. It took me a couple days to understand it does that so that you have them sorted once you pick them up (printed side was up). By that time I also have already publicly declared the stupidity of that printer. I think the shame after my enlightment deepened this life lesson.
  - Swizec 5y ago
    Before calling something dumb, I try to come up with at least 1 answer to “Why would you do it that way” Mostly stopped calling things dumb since I adopted that rule.
    - Dylan16807 5y ago
      But very often the answer is "It saved some development effort, but not all that much." or "It saved a very small amount off the per-unit cost." In those situations, "dumb" tends to be a correct judgement.
WaitWaitWha 5y ago
My experience has bit more expansion to this 'mental rule'. I judge something 'proportional to how much I know about it' and in context when it was developed. Designers take things outside of the design into consideration. The design may remain alive and in use (but not necessarily the original intended use) way past the original, outside environment.
- asdfasgasdgasdg 5y ago
  Yep. Sometimes: "this is no longer how we would handle this today, but at the time it made sense because of X" is a common finding if you dig deep enough.
nyokodo 5y ago
In the spirit of humility that this article promotes, can anyone explain to me why so many doors have handles that stick out when they’re push doors and a sign that says push instead of having no handle and say a protruding flat push surface that requires no sign and intuitively indicates to push even for the sight impaired?
- csours 5y ago
  The people who build, buy, and commission things are not the same ones who use them.
- deltaonefour 5y ago
  Saves manufacturing costs. When I make a door I want to make one model that will function for every use case. The "pull bar" can be used for push and pull so I put it on both sides and be done with it.
  - closeparen 5y ago
    My household was a little more conspiratorial, so my childhood version of “the engineers must be stupid” was “they figured out it was a good way to rip you off.”
  - deleted 5y ago
    [deleted]
  - aidenn0 5y ago
    Also if the bar goes all the way across it can be pre-assembled without regard to left- or right-handed doors.
- pm90 5y ago
  Probably contractors built it as a mistake and then users use a cheap hack rather than pay to replace it.
  - jethro_tell 5y ago
    lol, this is the very action the article is saying you should avoid. Assuming stupidity when you don't really know anything about the subject.
deltaonefour 5y ago
Managers with this attitude are dangerous.
- lordleft 5y ago
  I'm really surprised by the pushback this sentiment and the related idea of Chesterton's Fence gets from a lot of folks at HN. It seems eminently sensible to me. I understand how some people might think it would promote inertia, tech debt, and a kind of conservatism that can kill companies and institutions, but approached in good faith, I think it can probably prevent a lot of headaches. Surely the point is not to uncritically preserve the status quo, but to interrogate deeply why the status quo is the way that it is, to better decide whether or how a thing should be changed. And surely there is peril in the opposite impulse.
  - jacobr1 5y ago
    There are two parts to this 1) willingness to challenge the status quo 2) intellectual humility enough to seek to understand why the status quo exists. There is some conflation of these two concepts in the comment threads.
    - lanstin 5y ago
      Probably more software is objectively bad than other things people make, so we are used to looking into the details and immediately making things 10x or 100x better https://xkcd.com/2030/ https://xkcd.com/2030/
    - not2b 5y ago
      Lots of 1) around here. Not so much 2).
  - voidhorse 5y ago
    I think the cavalier attitude stems from the fact that a lot of people work on software that’s really not that important in the grand scheme of things so it’s not a huge deal to break things down, make mistakes, and ship buggy code. There are a lot more people programming social media sites than there are programming train traffic systems or missile controls—I have a strong feeling those that work on these sorts of projects have a much different attitude.
seanalltogether 5y ago
This reminds me of a quote from John Carmack that gnaws on the back of my brain during day to day development - "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in." Seems it would also be relevant to most of modern inventions.
- ReptileMan 5y ago
  Well ... with modern environments it is impossible to understand the states. Too many layers, too many components, too many abstractions etc etc.
  - feoren 5y ago
    The whole point of layers and abstractions is to reduce the number of states you have to worry about. The way that people talk about abstractions like they're a bad thing makes me think they've never really stopped and thought about all the many, many good abstraction layers they use. It makes sense: a great abstraction is basically invisible, so you don't even notice it unless you pay attention. But everyone who says "too many abstractions" has clearly not stopped and paid attention. You don't need fewer abstractions, you need better abstractions.
    - nyanpasu64 5y ago
      An abstraction layer makes itself most visible when it fails. Avoiding failure requires better or less abstraction layers. In many cases I don't trust others to build correct abstraction layers, good UI libraries, reliable GPU drivers that don't corrupt memory when sleeping the system, etc. (Filesystems and virtual memory are largely reliable in the common case, though it's still common to avoid filesystems and allocations and swapping in real-time code, and schedulers cause grief when they cause media payback to stutter when I'm running compiler jobs.) Often I trust myself to work with less abstraction layers, more than I trust others to build better ones.
    - FranksTV 5y ago
      Nonsense. Abstractions.are for fools. I count my electrons by hand, just like my grandfather did.
nojs 5y ago
The other side of this coin is that some ignorance can be beneficial to break out of local minima. > How do you overcome schlep blindness? Frankly, the most valuable antidote to schlep blindness is probably ignorance. Most successful founders would probably say that if they'd known when they were starting their company about the obstacles they'd have to overcome, they might never have started it. Maybe that's one reason the most successful startups of all so often have young founders. http://paulgraham.com/schlep.html http://paulgraham.com/schlep.html
- nraynaud 5y ago
  My “other side of the coin” is: as a designer of a system, never explain how they work, just tell people it is smart and that they should not assume otherwise since they don’t know how they work. And then go back swimming in your giant vault of money saved by skimping on security.
- actually_a_dog 5y ago
  Re: "young founders," this is simply not true, at least not anymore, if it ever was: > More broadly, 2018 research published in the Harvard Business Review found that the average age at which a successful founder started their company is 45. That’s “among the top 0.1% of startups based on growth in their first five years,” according to the report. https://www.cnbc.com/2021/05/27/super-founders-median-age-of-billion-startup-founders-over-15-years.html https://www.cnbc.com/2021/05/27/super-founders-median-age-of... Let's not perpetuate yet another ageist myth.
  - quickthrower2 5y ago
    To me young is < 60. Also "most successful startups". OK let's do a quality of life scale, 0 for destitute, 10 for billionaire. Millionaire would be 9.8 on the scale. Hell maybe the other way around, being a millionaire is better than being a billionaire (because of the problem of fame). A lot of people reach that by doing mundane things like starting a tyre fitting shop, or janitorial business, or flipping houses, or very niche software businesses. Depends what we mean by success. There is the 'make investors rich' kind of success that an investor is looking at encouraging people to do.
a2tech 5y ago
I work in a lot of old systems and this is something I have to remind myself of constantly--the people that were working on these systems before me were not necessarily dumber than me. If they made these choices, they may have had good reasons for it that are not immediately clear to me, but if I change it may have far flung consequences that I am just not aware of.
- Olreich 5y ago
  If a change has far flung consequences that aren’t obvious, the code is of poor quality. If the reasons for the decisions are non-obvious, the code is of poor quality. I’ve been bitten y assuming that people thought things through the first time too many times. If it’s not in the code base or documentation, I’m assuming that it was done for expedience. Not because they were dumb, but just because that part of the code base wasn’t important when it was written.
  - fvold 5y ago
    Yep, that's what I usually call "four weeks worth of code done in three weeks", and it's the cause of every rewrite I've been a part of so far.
  - elygre 5y ago
    > If it’s not in the code base or documentation, I’m assuming that it was done for expedience. That sounds exactly like the kind of judgement the article talks about.
    - tsibelman 5y ago
      Trying to understand everything passively prevent you from actually understanding things, trying to change something will teach you about underlying issues or it will show there no issues.
  - kqr 5y ago
    Zoom out a little. Code can work perfectly fine technically yet have far-flung consequences in terms of business cases, human workflows, etc, etc. So it's not as easy as saying "there's always a good reason" or "there's never a good reason". Make a fair effort at uncovering the reason and then it's a judgment call with insufficient data.
bede 5y ago
The seatbelt is an excellent example since there are multiple mechanisms with varying observability contributing to its effectiveness. Even after discovering the dynamic locking behaviour, a naive yet inquisitive passenger remains blind to the pretensioning feature that is observable only during a collision.
- gregmac 5y ago
  Another is why they lock when you pull them out all the way: I discovered this accidentally as a kid, but just learned the lesson "don't do that" and didn't really think about it further. It wasn't until I had to install a child seat for the first time when suddenly it became clear this was a very useful feature.
  - bentcorner 5y ago
    It's an ingenious design. Given a seat belt that cannot be intentionally locked in this way, how would you address complaints from users who want to arbitrarily lock their seat belts? To me, "pull it out all the way" isn't an obvious choice, but is such an elegant solution.
  - borski 5y ago
    Thank you! I have wondered this myself and mostly just fine with “it’s annoying so I make sure not to ratchet it anymore,” but since I don’t have kids (yet?) — thank you for the explanation!
spchampion2 5y ago
Relevant XKCD - https://xkcd.com/277/ https://xkcd.com/277/
- aunty_helen 5y ago
  ffff. Can confirm, people setting up traffic lights are idiots. Sometimes they're set up based on 15 minutes of observation. I don't care how many weeks you run your crappy simulations, they're so inaccurate that its laughable. Source: I built a startup in this industry to prove it. Edit: I kid you not, I once went to a conference and a traffic engineer for a sizable city got on stage to present the best idea they had and it went like this: > So once traffic gets to 80% on the main road, we're just going to change all the lights to green and everybody on the side streets can just suck eggs for 5-7 minutes. That's it. That's the best their simulations could come up with. These people use interns with clipboards to get their data. Edit 2: "Suck eggs" were their words not mine.
  - jiggawatts 5y ago
    I worked at a local department of roads and motor vehicles where their traffic light management software was written in the late 80s to early 90s and looked like it. Mind you, they had modernised it! It worked on 32-bit! If anyone thinks that this Windows 95-era application had any kind of smarts in it at the same level as modern machine learning, AI, or even basic queuing theory, they would be sorely mistaken. I believe all it had were some basic weekday-weekend and peak-afterhours scheduling capabilities. It also had sensor integration, but only at a few hundred key intersections around the city.
hn_throwaway_69 5y ago
> My willingness to judge something should be proportional to how much I know about it. When everyday folk start doubting the safety and/or effectiveness of mRNA vaccines this is what comes to my mind.

487 points by dguo 5y ago

I think the harder part is determining how much you actually know about something, to know how much you can judge. My default nowadays is I never know enough, even in the fields I'm specialized in. Part of it is I think just a limit of how much information I can accurately refer to/pull up in my brain at any given time too.

puffoflogic 5y ago

Sometimes the engineers are "too" clever. In my car, seatbelts have an additional mechanism which causes them to stop if the car is braking (with a certain acceleration, perhaps, or actual detection of the brake - I haven't determined). This seems very sensible until you live near an intersection which is not at right angles, which requires the driver to lean forward upon arrival at the intersection in order to look around the A pillar for oncoming traffic. What's interesting is that I now know something that the engineers designing the system should have known but apparently didn't, or knew and didn't care about. So sometimes (or much of the time?) users do know something the engineers don't.

mlyle 5y ago
> In my car, seatbelts have an additional mechanism which causes them to stop if the car is braking (with a certain acceleration, perhaps, or actual detection of the brake - I haven't determined). This seems very sensible until you live near an intersection which is not at right angles, which requires the driver to lean forward upon arrival at the intersection in order to look around the A pillar for oncoming traffic. This is a tradeoff. You can have a pure pay-out based locking retractor (centrifugal clutch). Or you can have a pendulum-based mechanism, or a combination of the two. If you have the pendulum-based one, you'll be less likely to false positive based on the movement of the occupant but more likely to false positive based on deceleration of the vehicle. The combination is best, because you can be relatively insensitive to individually occupant movement and vehicle deceleration and still actuate reliably in a crash. But it still will false positive. In any case, "not annoying the user" is prioritized beneath "saving lives in a crash" by regulators, and hence the auto industry. I'm guessing you brake rather abruptly in this situation if this is something you routinely encounter.
- prh8 5y ago
  I recently upgraded vehicles from a 2009 to a current one with all the new safety features. In my research I read lots of complaints about emergency/auto braking activating too much and other features of the car stepping in to assist the driver. Since switching vehicles, on the incredibly rare occasions something has activated, it's always been valid and a quicker reaction than my own. Your tag line reminds me of all the times I've pondered how bad these complaining drivers must be.
  - puffoflogic 5y ago
    Odd that you should mention this: tonight my car decided it needed to ABS brake (very alarming when unexpected) while I was reversing at less than 5 mph, apparently because a car >20 feet away was turning into a parking spot, well out of my path of travel. The car proudly informed me it had averted a collision, when in fact the application of the brake was unnecessarily violent enough that it quite possibly did damage on its own, and could have caused injury. Progress!
jacobr1 5y ago
This is one of the things I love about open source software. When I want or need to, I can attempt to modify something to better suit the behavior I want. Some fraction of the time it ends up being too much effort, or I learn that my idea didn't take into account some secondary factor. But often enough I make can make a change, and even maybe contribute it back. I'd love to see more open-source with physical product - 3D printing seems like a good start.
frosted-flakes 5y ago
I think the auto-locking is pendulum-based. I've noticed that on steep slopes the seatbelt tends to lock very easily.

quickthrower2 5y ago

Then don't judge anything as 'stupidly designed'. What does that mean? Just say "I think the design flaw is XYZ". If I find a stupidly designed product, it is often because it was the cheap option. Spending more saves money in the long run. Water bottles spring to mind - most of them leak or get damaged by dish-washing sooner or later. Spending $20 on a water bottle is cheaper than spending $5 ten times. Although a high price isn't a guarantee of quality either!

chrisseaton 5y ago
> If I find a stupidly designed product, it is often because it was the cheap option. Well then they weren't being stupid - they were optimising for short-term cost. That's not stupidity - it's a tradeoff.
- quickthrower2 5y ago
  Yes I should have airquoted "stupid" there!
- jacobr1 5y ago
  Right, and then we bought the thing. Who is the stupid one now ;)
notapenny 5y ago
"I think" sums it up nicely. It's not a fact, its your opinion. Maybe it was actually designed stupidly, or maybe someone just made a different choice given a different set of circumstances.

csours 5y ago

When I was a kid I decided that test pilots must be idiots. My logic: Being a test pilot is dangerous. Only idiots do dangerous things. Therefore test pilots must be idiots. Later (embarrassingly later) I learned that many test pilots were also engineers. This made me reconsider my opinion. I learned to be very careful when judging intelligence, and also the limits of inference.

nradov 5y ago
Intelligence is generally orthogonal to physical risk tolerance. I don't know why anyone would conflate the two.
scotty79 5y ago
Being an idiot us a varied and nuanced thing. Plenty of very intelligent people are idiots in one way or another. Being drawn to excessively risky behavior is just one aspect of idiocy.
TremendousJudge 5y ago
>This made me reconsider my opinion Why? Plenty of engineers are complete idiots in many levels.
- csours 5y ago
  I think these comments highlight to me how difficult it is to reason and talk about intelligence. Intelligence and stupidity suffer from fundamental attribution error. The main thing I learned from reflecting on my error is that making any sweeping conclusions about people is foolhardy. So yes, engineers can be idiots, test pilots can be idiots, smart people can decide to do dangerous things on purpose, idiots can do dangerous things on purpose, idiots can do dangerous things on accident, so on to absurdity. Putting people in buckets based on some observed criteria is rarely advisable; everyone's story is different.

unityByFreedom 5y ago

Learning often involves making mistakes, speaking out, etc. Don't be afraid to assert yourself.

MPSimmons 5y ago
I would add the caveat that, when doing so, be aware of, and vocalize, your current state of familiarity. Also, I find that asking questions leads to better outcomes than making statements.
- city41 5y ago
  I agree in general. But at least on the internet I find an incorrect claim will be corrected more often than a question is answered.
- unityByFreedom 5y ago
  Questions imply some unfamiliarity but sure that may be helpful if supplied.

codegeek 5y ago

Kinda related. When I was like 11-12ish, I remember waiting in my Dad's car with my younger brother when he went into a store for like 20 mins. We started playing with the steering wheel and then suddenly I couldn't turn it anymore. It was locked. We were shit scared that we broke something and how will Dad drive the car now ? I remember being quiet when my Dad got back to the car (I had warned my younger brother to deny that we did anything) and the moment he put the key in ignition, boom. I face palmed in my mind and learned how steering wheel locking works :)

onpensionsterm 5y ago
I think there are a lot of people who never learnt about this and will only learn after an embarrassing phonecall to a recovery company.

irrational 5y ago

> An overwhelming feeling of stupidity hit me almost as fast. Nine-year-old me was not in fact smarter than Toyota engineers. It’s unfortunate how many people never come to this realization.

throwaway0a5e 5y ago
I think we have the opposite problem too. People ascribe way too much intentional design to shit they don't understand even where no such intentional design exists. Like 99% of the stuff you encounter on a daily basis is how it is because of some 3-way trade between aesthetically pleasing, the economic realities of producing that object and "how they've always been." It is not engineered for performance in the slightest other than some basic "yeah that should do" napkin analysis.
- vlovich123 5y ago
  Or where the original constraints made sense at the time but they’ve been forgotten and all we’re left with is the end product.
  - timClicks 5y ago
    I think of this whenever I see coat hooks with dual hooks, the top one extending further. I've always assumed that they were designed when people regularly wore hats.
    - maccard 5y ago
      In my house, we use the bottom hooks for "outdoor base" and the longer top hooks for "outdoor top layer". It means you're never putting dry base layers on top of a wet waterproof layer. But your explanation makes _way_ more sense.
    - vineyardmike 5y ago
      I think it also provides value for people to hang purses. But as other comments mention they found utility in it through layering. It may have been for hats once, but it’s certainly kept around because people found new uses.

TheOtherHobbes 5y ago

How do you know how much you don't know? I'd suggest there's a difference between "I don't understand how this is supposed to work" to "I do understand how this is supposed to work, and I don't understand why it isn't working." Seat belt story seems to be Type 1. But what if a lot of "stupid" design decisions are actually Type 2? And the reasons may or may not be good - somewhere on a scale from real budget and/or time constraints, lack of insight, indifference, penny pinching economics, to passive aggressive user hostility. When Apple removed Magsafe no doubt there were perfectly good internal justifications for that decision. But ultimately the people outside the company who said it was a poor move from a user POV turned out to be right.

grp000 5y ago
I think it's a case of defining what you know, and asking questions for what you don't know. But, of course that's easier said than done. Maybe you chase after a red herring, maybe you ask the wrong questions. But I think asking the right questions comes from expert understanding of the fundamentals of anything, which is really hard, maybe for a lot of new fields, impossible because no one has established fundamentals, unless you're really smart. Maybe you permute the thing, or its joined with another thing, so it really becomes it own new thing. I personally hate the non-magsafe charger because I trip over it and yank the laptop around, but I can see the trade off in being able to use a single charger for everything. Because of that, I see the magsafe issue being a permutation, because by changing the environment that laptop chargers operate in, with the addition of usb-c, you've changed the game.
- deleted 5y ago
  [deleted]
- CRConrad 5y ago
  > I personally hate the non-magsafe charger because I trip over it and yank the laptop around, but I can see the trade off in being able to use a single charger for everything. So why the *ck didn't they just include a little bit of magsafe-to-USB-C cable with the phones, and keep the wall-plug-to-magsafe charger? Then they could have transitioned the laptops over to USB-C at any time without inconveniencing users, added the safety of magsafe to the phones, and allowed users to mix-and-match chargers and cables. But no, that's exactly what they didn't do. Funny that, for this vaunted "customer-centric" company...

emehrkay 5y ago

I feel that I made the transition from jr to mid level developer when I was able to come into some new code and judge it, instantly pointing out what was wrong and how it could be improved, and how it should've been built. I feel that I went from mid to senior when I would enter that same situation and try to understand the why behind the code (even though I probably still thought it was poorly architected) before passing judgement or trying to "fix" it with a refactor.

nostrademons 5y ago
You transition from senior to manager when you first try to understand the importance of the code to the business and whether anyone will ever touch it before bothering to understand the code.
- ThalesX 5y ago
  Your short comment really triggered my management PTSD. I wrote a huge ass post but decided to delete it and just summarize: * Senior tradesman -> manager is not a natural transition; * Senior tradesmen take business into account without needing to transition; * Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious. I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application. I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
  - thyrsus 5y ago
    Why does Dunning-Kruger come to mind?
    - CRConrad 5y ago
      On the part of the GP, or the management caste?

Tehdasi 5y ago

The reverse is also quite true. You can get a thing which just seems too slow/fiddly/buggy/etc, but it's in an area where you are unfamiliar with, so you pass it off as just your misunderstanding of the thing. Whenever you investigate more on it, you find that there are ways ppl use it that avoid the problems that you are having with it, or that pieces of the thing make a certain amount of sense the way they are. Then as you learn more you begin to understand the underlying reason that the thing is the way it is, and you realise that it's not you. Poor decisions were made in the design of the thing initially (or at least decisions which once valued the right things, but now do not), and have become baked into the DNA of the thing so it could not be fixed without major changes that nobody wants to do. It's at that point, you realize that the emperor has no clothes, and certainly didn't deserve the benefit of the doubt. I find this is particularly the case when the design flaw is particularly bad, the developers end up adding complexity to work around the flaw, which has the effect of hiding the flaw, making it alot less obvious to the novice.

burlesona 5y ago

Obligatory: be careful you’re not standing atop Mount Stupid. https://www.smbc-comics.com/?id=2475 https://www.smbc-comics.com/?id=2475

justnotworthit 5y ago

> My willingness to judge something should be proportional to how much I know about it. I'd also add: ...should be proportional to my need to or benefit from passing judgement. Postpone judgement and you observe more. It's counterproductive to stamp everything in life "good/bad" "dumb/smart" "friend/foe" as soon as possible.

sturza 5y ago

I drew a similar conclusion about people's observations, in general: the faster the conclusion the less knowledge about the topic - which is similar to Kahneman's system 1(intuition).

helsinkiandrew 5y ago

It's always terrified me how one experience or one anecdote can completely change a persons view on a topic and make them blind to the overwhelming evidence they've previously experienced and accepted (and ignore future evidence) A single rude salesperson and they won't step foot in the entire chain, a bad cop or doctor and the whole police force or medical establishment is corrupt. Listen to a politician giving a speech and people become lifelong supporters even when their policies change radically. There is something deeply embedded in the human mind that makes us very susceptible to some stories - against all evidence, if it fits our preconceived perception or coincides with something in our memory.

8192kjshad09- 5y ago
I think there is an innate human bias to weight negative experiences more strongly than positive ones. For example, I will forget a compliment a day later, but I will never forget that one time I was harshly criticized. It makes sense from an evolutionary perspective as well, the worst possible experience (death) is far worse than the best possible experience (food,sex,comfort,etc). Re: your example about politics. Politicans explot this by talking about how bad the others are, rather than how good they are.
andrei_says_ 5y ago
> a bad cop or doctor and the whole police force or medical establishment is corrupt. I’m not sure these are the greatest examples. If “good” cops stand by watching “bad” cops abusing their position including stealing, lying, assaulting, murdering or torturing people, then maybe we are speaking of institutional issues blurring the lines between behaviors typical for organized crime and ones observed with the police force. Especially if whole police teams threaten to stop doing their jobs if their insanely inflated budgets get reduced. Of course there are good cops. You can often hear about them getting pushed out of the police force for reporting the crimes of the bad ones. If doctors are allowed 20 minutes per patient visit and are constantly pressured to prescribe medication and procedures for profit then we might have an issue there, too.
- virgilp 5y ago

halikular 5y ago

Like how most things is for a reason. Especially within rigorous domains such as engineering, math, physics and programming. It is not to be expected in BS vendors safe space in subjects like politics, economics and social science.

jevgeni 5y ago
Tell me you haven't touched economics as a science, without telling me you haven't touched economics as a science.
- CRConrad 5y ago
  I have, and I can see GP's point.
  - jevgeni 5y ago
    Then you can also see that what GP implies about econ academic practice applies at most to pop science articles and financial analysts.
    - CRConrad 5y ago
      No.

gyulai 5y ago

One particularly prominent special case of this is when one engineer makes a snap judgment about another engineer's work that it's "overcomplicated". Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution. I feel like, at this point in my career, and in the specific context where I work, this has now become the bottleneck to my career progress. The problem is: It works as a self-fulfilling prophecy based on the fallacies of social proof and fundamental attribution error. People reach for the snap judgment "this is overcomplicated" because they expect me to just be the kind of person who just overcomplicates things. And they feel easily justified in that judgment given that other people also tend to make that judgment about me. This means they budget even less time for trying to understand the complexities in the problems I solve before reaching for the easy judgment of "this is overcomplicated". So: The guy who always overcomplicates things, thus draining the company's cognitive resource needlessly and just generally being a nuisance, ends up looking much the same from the outside as the guy who could just be a company's strongest engineering asset. He could be the guy to put the company ahead of the competition, always understanding the engineering problems more deeply and solving them more thoroughly than others, including the competition, in a way that the competition can't easily replicate. -- ...if only the people tasked with passing judgment could overcome biased and lazy decision-making.

alkonaut 5y ago
> Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution. This is often the case, but even more often I think my annoyance with the overcomplexity of the code isn't that the code solves the problem in a too complex way, but that the code solves a much too complex problem. Most of my job as a developer is fighting complexity. Doing it in code is an uphill battle. If you have to solve complex problems with non-complex code, you are fighting a losing battle. The struggle to keep complexity out of the code happens in the dialogue with stakeholders (Project managers, customers, team etc). Now, there are of course cases where the conclusion after the complexity debate might have been that "yes, the requirement is for the program behavior to really be this complex, meaning the complexity of the code is required". But this is extremely rare. The reason I get annoyed when seeing complex code is because through the decades I have learned that almost invariably, someone took a complex requirement at face value and implemented a complex solution to the requirement.

spullara 5y ago

If you are a 9-yr old developer, this makes a lot of sense. Most people in a professional situation are closer in skill level and this kind of disparity indicates a lack discipline when hiring. I see it all the time so it is not unusual.

foreigner 5y ago

A corollary to this that I read somewhere: we tend to judge other's actions by the outcome, but our own actions by our intent.

Scarblac 5y ago

I first tried out the WWW when it had fewer than 2000 pages, and didn't see the point. My constant reminder that if something initially looks useless to me, it's probably me.

captainmuon 5y ago

I see your Chesterton's fence and raise a Gell-Mann amnesia. Yes, the phenomenon in the article is real, but the opposite is also true. Many times I have seen something, thought it is silly, wrong, or could be done better, but I reserved judgement because I didn't know much about the subject. And then in the end, I was right. Be it some technical choice at work that had obvious flaws. Or when we were renovating our house and as a layperson I noticed a serious problem the experts didn't see. Or when I was reading about poststructuralism, or critical theory at university. I had a feeling it was just a lot of word games around a couple important ideas - then I put in the work and read books and went to courses, and yupp, that was basically true. Looking at it from the other side, as an expert on some topics, I know there are a lot of things we do that are not justified by the "subject matter" but we just do them because we have always been doing them, or because a pointy haired boss decided so. Or we have operational blindness and can't notice the flaws anymore.

jonpalmisc 5y ago

For those who just want to see the rule: > My willingness to judge something should be proportional to how much I know about it. I think it’s a sound rule. Going to try to remind myself of this more.

jimkleiber 5y ago
I wish the author would have added this last sentence to the rule: > There’s so much I don’t know. To become: "My willingness to judge something should be proportional to how much I know about it and there’s so much I don’t know."

Graffur 5y ago

I feel like this is captured in the popular wisdom: "Don't jump to conclusions"

Medicineguy 5y ago
I like the human-relatable story behind it. I think many kids experience a similar situation that sparks this life lesson. My younger self condemned my father's printer as "dumb" for printing a multi-page print job in reverse order. It took me a couple days to understand it does that so that you have them sorted once you pick them up (printed side was up). By that time I also have already publicly declared the stupidity of that printer. I think the shame after my enlightment deepened this life lesson.
- Swizec 5y ago
  Before calling something dumb, I try to come up with at least 1 answer to “Why would you do it that way” Mostly stopped calling things dumb since I adopted that rule.
  - Dylan16807 5y ago
    But very often the answer is "It saved some development effort, but not all that much." or "It saved a very small amount off the per-unit cost." In those situations, "dumb" tends to be a correct judgement.

WaitWaitWha 5y ago

My experience has bit more expansion to this 'mental rule'. I judge something 'proportional to how much I know about it' and in context when it was developed. Designers take things outside of the design into consideration. The design may remain alive and in use (but not necessarily the original intended use) way past the original, outside environment.

asdfasgasdgasdg 5y ago
Yep. Sometimes: "this is no longer how we would handle this today, but at the time it made sense because of X" is a common finding if you dig deep enough.

nyokodo 5y ago

In the spirit of humility that this article promotes, can anyone explain to me why so many doors have handles that stick out when they’re push doors and a sign that says push instead of having no handle and say a protruding flat push surface that requires no sign and intuitively indicates to push even for the sight impaired?

csours 5y ago
The people who build, buy, and commission things are not the same ones who use them.
deltaonefour 5y ago
Saves manufacturing costs. When I make a door I want to make one model that will function for every use case. The "pull bar" can be used for push and pull so I put it on both sides and be done with it.
- closeparen 5y ago
  My household was a little more conspiratorial, so my childhood version of “the engineers must be stupid” was “they figured out it was a good way to rip you off.”
- deleted 5y ago
  [deleted]
- aidenn0 5y ago
  Also if the bar goes all the way across it can be pre-assembled without regard to left- or right-handed doors.
pm90 5y ago
Probably contractors built it as a mistake and then users use a cheap hack rather than pay to replace it.
- jethro_tell 5y ago
  lol, this is the very action the article is saying you should avoid. Assuming stupidity when you don't really know anything about the subject.

deltaonefour 5y ago

Managers with this attitude are dangerous.

lordleft 5y ago
I'm really surprised by the pushback this sentiment and the related idea of Chesterton's Fence gets from a lot of folks at HN. It seems eminently sensible to me. I understand how some people might think it would promote inertia, tech debt, and a kind of conservatism that can kill companies and institutions, but approached in good faith, I think it can probably prevent a lot of headaches. Surely the point is not to uncritically preserve the status quo, but to interrogate deeply why the status quo is the way that it is, to better decide whether or how a thing should be changed. And surely there is peril in the opposite impulse.
- jacobr1 5y ago
  There are two parts to this 1) willingness to challenge the status quo 2) intellectual humility enough to seek to understand why the status quo exists. There is some conflation of these two concepts in the comment threads.
  - lanstin 5y ago
    Probably more software is objectively bad than other things people make, so we are used to looking into the details and immediately making things 10x or 100x better https://xkcd.com/2030/ https://xkcd.com/2030/
  - not2b 5y ago
    Lots of 1) around here. Not so much 2).
- voidhorse 5y ago
  I think the cavalier attitude stems from the fact that a lot of people work on software that’s really not that important in the grand scheme of things so it’s not a huge deal to break things down, make mistakes, and ship buggy code. There are a lot more people programming social media sites than there are programming train traffic systems or missile controls—I have a strong feeling those that work on these sorts of projects have a much different attitude.

seanalltogether 5y ago

This reminds me of a quote from John Carmack that gnaws on the back of my brain during day to day development - "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in." Seems it would also be relevant to most of modern inventions.

ReptileMan 5y ago
Well ... with modern environments it is impossible to understand the states. Too many layers, too many components, too many abstractions etc etc.
- feoren 5y ago
  The whole point of layers and abstractions is to reduce the number of states you have to worry about. The way that people talk about abstractions like they're a bad thing makes me think they've never really stopped and thought about all the many, many good abstraction layers they use. It makes sense: a great abstraction is basically invisible, so you don't even notice it unless you pay attention. But everyone who says "too many abstractions" has clearly not stopped and paid attention. You don't need fewer abstractions, you need better abstractions.
  - nyanpasu64 5y ago
    An abstraction layer makes itself most visible when it fails. Avoiding failure requires better or less abstraction layers. In many cases I don't trust others to build correct abstraction layers, good UI libraries, reliable GPU drivers that don't corrupt memory when sleeping the system, etc. (Filesystems and virtual memory are largely reliable in the common case, though it's still common to avoid filesystems and allocations and swapping in real-time code, and schedulers cause grief when they cause media payback to stutter when I'm running compiler jobs.) Often I trust myself to work with less abstraction layers, more than I trust others to build better ones.
  - FranksTV 5y ago
    Nonsense. Abstractions.are for fools. I count my electrons by hand, just like my grandfather did.

nojs 5y ago

The other side of this coin is that some ignorance can be beneficial to break out of local minima. > How do you overcome schlep blindness? Frankly, the most valuable antidote to schlep blindness is probably ignorance. Most successful founders would probably say that if they'd known when they were starting their company about the obstacles they'd have to overcome, they might never have started it. Maybe that's one reason the most successful startups of all so often have young founders. http://paulgraham.com/schlep.html http://paulgraham.com/schlep.html

nraynaud 5y ago
My “other side of the coin” is: as a designer of a system, never explain how they work, just tell people it is smart and that they should not assume otherwise since they don’t know how they work. And then go back swimming in your giant vault of money saved by skimping on security.
actually_a_dog 5y ago
Re: "young founders," this is simply not true, at least not anymore, if it ever was: > More broadly, 2018 research published in the Harvard Business Review found that the average age at which a successful founder started their company is 45. That’s “among the top 0.1% of startups based on growth in their first five years,” according to the report. https://www.cnbc.com/2021/05/27/super-founders-median-age-of-billion-startup-founders-over-15-years.html https://www.cnbc.com/2021/05/27/super-founders-median-age-of... Let's not perpetuate yet another ageist myth.
- quickthrower2 5y ago
  To me young is < 60. Also "most successful startups". OK let's do a quality of life scale, 0 for destitute, 10 for billionaire. Millionaire would be 9.8 on the scale. Hell maybe the other way around, being a millionaire is better than being a billionaire (because of the problem of fame). A lot of people reach that by doing mundane things like starting a tyre fitting shop, or janitorial business, or flipping houses, or very niche software businesses. Depends what we mean by success. There is the 'make investors rich' kind of success that an investor is looking at encouraging people to do.

a2tech 5y ago

I work in a lot of old systems and this is something I have to remind myself of constantly--the people that were working on these systems before me were not necessarily dumber than me. If they made these choices, they may have had good reasons for it that are not immediately clear to me, but if I change it may have far flung consequences that I am just not aware of.

Olreich 5y ago
If a change has far flung consequences that aren’t obvious, the code is of poor quality. If the reasons for the decisions are non-obvious, the code is of poor quality. I’ve been bitten y assuming that people thought things through the first time too many times. If it’s not in the code base or documentation, I’m assuming that it was done for expedience. Not because they were dumb, but just because that part of the code base wasn’t important when it was written.
- fvold 5y ago
  Yep, that's what I usually call "four weeks worth of code done in three weeks", and it's the cause of every rewrite I've been a part of so far.
- elygre 5y ago
  > If it’s not in the code base or documentation, I’m assuming that it was done for expedience. That sounds exactly like the kind of judgement the article talks about.
  - tsibelman 5y ago
    Trying to understand everything passively prevent you from actually understanding things, trying to change something will teach you about underlying issues or it will show there no issues.
- kqr 5y ago
  Zoom out a little. Code can work perfectly fine technically yet have far-flung consequences in terms of business cases, human workflows, etc, etc. So it's not as easy as saying "there's always a good reason" or "there's never a good reason". Make a fair effort at uncovering the reason and then it's a judgment call with insufficient data.

bede 5y ago

The seatbelt is an excellent example since there are multiple mechanisms with varying observability contributing to its effectiveness. Even after discovering the dynamic locking behaviour, a naive yet inquisitive passenger remains blind to the pretensioning feature that is observable only during a collision.

gregmac 5y ago
Another is why they lock when you pull them out all the way: I discovered this accidentally as a kid, but just learned the lesson "don't do that" and didn't really think about it further. It wasn't until I had to install a child seat for the first time when suddenly it became clear this was a very useful feature.
- bentcorner 5y ago
  It's an ingenious design. Given a seat belt that cannot be intentionally locked in this way, how would you address complaints from users who want to arbitrarily lock their seat belts? To me, "pull it out all the way" isn't an obvious choice, but is such an elegant solution.
- borski 5y ago
  Thank you! I have wondered this myself and mostly just fine with “it’s annoying so I make sure not to ratchet it anymore,” but since I don’t have kids (yet?) — thank you for the explanation!

spchampion2 5y ago

Relevant XKCD - https://xkcd.com/277/ https://xkcd.com/277/

aunty_helen 5y ago
ffff. Can confirm, people setting up traffic lights are idiots. Sometimes they're set up based on 15 minutes of observation. I don't care how many weeks you run your crappy simulations, they're so inaccurate that its laughable. Source: I built a startup in this industry to prove it. Edit: I kid you not, I once went to a conference and a traffic engineer for a sizable city got on stage to present the best idea they had and it went like this: > So once traffic gets to 80% on the main road, we're just going to change all the lights to green and everybody on the side streets can just suck eggs for 5-7 minutes. That's it. That's the best their simulations could come up with. These people use interns with clipboards to get their data. Edit 2: "Suck eggs" were their words not mine.
- jiggawatts 5y ago
  I worked at a local department of roads and motor vehicles where their traffic light management software was written in the late 80s to early 90s and looked like it. Mind you, they had modernised it! It worked on 32-bit! If anyone thinks that this Windows 95-era application had any kind of smarts in it at the same level as modern machine learning, AI, or even basic queuing theory, they would be sorely mistaken. I believe all it had were some basic weekday-weekend and peak-afterhours scheduling capabilities. It also had sensor integration, but only at a few hundred key intersections around the city.

hn_throwaway_69 5y ago

> My willingness to judge something should be proportional to how much I know about it. When everyday folk start doubting the safety and/or effectiveness of mRNA vaccines this is what comes to my mind.