I worked at a certain FAANG company at a time where the promo process rewarded "solving complex problems". The more complex of a problem you could solve the higher your level (and your pay, your status, etc).
Naturally, people were incentivized to find complex problems so they could solve them. Not only that, I think a lot of tech stacks at other companies evolved by copying this company's ideas, so even smaller companies with even less need for complex solutions ended up having them as well.
I’ve seen teams destroy themselves by solving complex problems that didn’t need to be solved. Instead of solving the real problems, they imagined a problem that was more interesting and complex, and tried to solve that.
No, it’s not. Identifying which problems are worth solving (regardless of their complexity), and solving those is worth promotion.
Lots of engineers have a fascination with solving complex problems purely for the sake of solving them. When you make that your criteria for promotion you end up have to do many rounds of layoffs in harder times because you’re staffed to the gills with people solving complex problems that deliver little to no actual value.
Solving problems that move the needle for the company in terms of customer experience, financials, or things like that are worth promotion. Sometimes these are complex problems. Sometimes not.
Software isn't an art project; it's a practical tool to solve practical problems.
Some of my more impactful changes haven't been all that complex; it was just a matter of knowing where and when to spend my time, based on working with our customer team, sales team, and directly talking to some customers.
One of my more praised changes was adding a link to our support backend that saved our customer team minutes of manual work every time. This was literally just adding a permalink: 3 minutes of work. Simple and low-complexity? Yes. But also impactful and moved the needle, and no one else had done it in the previous years.
Sometimes the promo committee can't tell the difference, i.e. was the problem complex to warrant the complex solution. They just see the effort put into solving it.
At the Austrian Institute of Advanced studies there was a professor that got real good at stochastic differential equations and made a career out of applying them to anything and all in economics. One big advantage was that almost no other economist can actually follow it. Those few that can are obviously super invested in the technique
Similarly, when the promo process rewards impact and influence on other engineers you get all the smart ambitious people making overengineered platforms, frameworks, and standards while no one competent or engaged is minding the actual end-user products.
This is a really tough problem to solve. If the company has amazing leaders, the leaders can correctly judge the depth of the problem and its impact, therefore rewarding the problem solver properly. Unfortunately promotion is really a tool for most leaders to advance their agenda. In a way Google invented this "solving complex problems" just to counter balance the misaligned incentives of the leaders, but to no avail.
When the value generation is so far removed from the individual, the system will get skewed towards private taking over something more globally beneficial (globally as in for the entire company).
Given the high bar that FAANG has set for filtering in self centered innovators, I bet some employees simply invented problems for solutions they already had at hand.
I have been thinking about this recently in relation to the complex and unwieldy nature of modern car UI (especially in electric cars).
It's so bad that it is keeping me from buying a car that I need.
The conclusion that I have come to is:
Sophisticated consumers are very different than aspirational consumers - and there are always many, many more aspirational consumers.
Therefore, catering to aspirational consumers at the expense of sophisticated ones is a rational economic choice.
An aspirational consumer will put up with all manner of deficiencies and gimmickry because they perceive them as being emblematic of their consumer achievement.
In cruder terms:
They are so happy to be driving a "luxury" car that they don't notice the garbage that came with it. Meanwhile, after decades of luxury car purchases, I just want the shifter to be intelligible ...
The older tesla cars had better controls. The software updates made things worse. The targets became SO small, for no reason. I think the developers must have written and tested the UI on a display firmly mounted on a desk or non-moving car. In a moving car, everything goes to hell.
The newer cars with no stalks (shifter, turn signals, wipers, lights) are just a mess. The display has nowhere to rest your hand, you must stab and hit the correct small target from your seat. They all make you a worse driver, through indirection, confusion, inaccuracy or distraction.
> complex and unwieldy nature of modern car UI (especially in electric cars)
Honestly, I love the UX and UI of a Tesla.
It automates so many things that I find tedious in other cars: lock/unlock, close windows, pre-heat/cool, auto-set navigation to office in the morning and home in the evening, set seating and other adjustments for the driver based on which phone key was used. Navigation works thanks to the free connectivity (all other in-car gpses I've had to use were useless). Nice screen to select and play music. Voice command works reasonably well for selecting music.
It's not perfect, but I prefer the UX & UI over all ICE cars I've driven before.
As an example: my user journey when starting my drive to the office in the morning is a 2 step process: (1) open door and (2) put in drive.
Especially in the winter that used to be 10+ steps for an ICE car: (1) find key (2) unlock car (3) open car (4) adjust seat because my wife drove before (5) press button to start engine (6) front-window defrost (7) rear window defrost (8) manually scrape the ice off the front window (9) select office in gps (10) release parking brake (11) clutch (12) put in gear.
Coming back to this I just wanna make an accurate comparison here
As an example: my user journey when starting my drive to the office in the morning is a 2 step process: (1) find phone, or hope it hasn't run out of battery while you were wherever (2) open door (3) sit down (4) close door and (5) put in drive and (6) drive because it's not actually self-driving despite the name.
Especially in the winter that used to be 10+ steps for an ICE car: don't find key because it's on the keyring I used to lock the house; unlock car while you're walking to it so it doesn't make any difference; (1) open door; (2) sit down; don't adjust seat because plenty of ICE cars have had automatic seat adjustment for decades, this isn't even remotely close to an innovation, I used to have a 1996 with this feature, and it could even be linked to the keypad code you used or the keyfob you used; (3) close door; (4) press button to start engine; automatic defrosters also exist; remote start also exists; (5) put in drive and (6) drive
It's almost like either way the process is literally "get key, get in, and drive away" because a car is a car... The key being your phone doesn't actually change anything.
While I agree with the sentiment that Tesla has wonderful UI/UX, your 10+ step EV-to-ICE comparison is disingenuous. Tesla does not scrape the ice by itself.
It’s kinda funny reading this as an owner of a Tesla. People who don’t have them like yourself keep lamenting touchscreens online, whereas Tesla owners explicitly stay with the brand because of how excellent it is compared to other vehicles, touchscreen or not.
Technology Connections just posted a video where he explains how he had to hold his car’s ugly 90s era stalk for 4 seconds to change his wipers. Had to read a manual to discover that. This kind of crap is very standard in cars with disjoint components cobbled together.
Meanwhile I get my live video sentry alerts on my phone, my car drives me to work, my gear selection is typically putting on a seatbelt and pressing the brake pedal as the car knows the right direction, everything important is contextually accessible via the wheels on the steering wheel instead of having 50 buttons for everything, and so on.
It is simple and powerful. The problem with those luxury vehicles you mention is just awful execution.
Humans are good at adapting to the common operations of even the worst user interfaces and then they will stop thinking about how awkward they are.
The iPhone is lauded as having a good UX. I think (even confining yourself to Apple's own apps) it's actually pretty inconsistent and a lot of things you "just have to know" because there are no cues that would lead you to discovery. But millions of people use them mindlessly because they have adapted to them.
> my gear selection is typically putting on a seatbelt and pressing the brake pedal as the car knows the right direction
What a hugely efficient time and energy saving innovation and only at the cost of lots of your money, personal safety, and basic human agency.
Soon you can probably just hop in and without facing difficult decisions about where to go, get instantly taken to the biggest corporate partner or affiliate advertisers. Maybe robots there can invert you and shake you down so you don’t even need to pull out the money
> Technology Connections just posted a video where he explains how he had to hold his car’s ugly 90s era stalk for 4 seconds to change his wipers. Had to read a manual to discover that. This kind of crap is very standard in cars with disjoint components cobbled together.
Yeah, he had to take a minute to pull the manual out of the glovebox, flip to the index, look under W, and then flip to another page. I guess he could have had to hunt through a bunch of different menus on a touchscreen instead?
(BTW the fact that you're worried about a stalk being ugly - and the fact that you think they're from the 90s? - shows which type of consumer you are :))
> my car drives me to work
Oh, so your Full Self Driving is actually fully self driving? Weird, I didn't think that existed.
I watch a YouTuber called Theo Browne sometimes. He is primarily a front end dev. When I watch him talk about his solutions to things I feel like i've been hit on the head with a baseball bat. The sheer number of things that go into his demos is eye watering. The number of arcane terms about React he will mention in a single video astounds me.
I don't mean to specifically call him out, but I worry that the complexity is what keeps him popular. And then you have someone like Pieter Levels just slinging raw php into production and not talking about anything like Suspense or Server Side Rendering or Hydration.
They both get to the same ends (well Pieter Levels makes magnitudes of order more money I think) but there is a gulf in complexity. I'd actually argue something like Nomad List is much more feature rich than anything I see from Theo.
I met Theo once. I didn't know who he was, but he made sure to tell me within the first few sentences that he was a very popular streamer/youtuber. I then watched him get recognized by someone else and they had a sort of friendly shouting match about something Theo has recently talked about in an opinionated way on his channel. His personality seemed perfectly suited for maximal media engagement through needless complexity. The more complicated things are the more arguments you can have and the smarter you can sound to those less familiar with all your esoteric choices.
I know Theo. He’s a good person who wants to educate folks, and make things simpler.
There are problems with education: you often have to make things contrived to show problems as fast as possible, and it’s hard to convey all of the nuance. Theo, and others, definitely try to strike that balance and I think it’s fair to say that this is because of how the front end world works rather than because of personalities.
My experience with frontend people is that they don't think twice about adding random libraries they just found that was released month ago. Also their projects are unmaintainable after one year, but they are long gone by that time and new developers arguing that they need to rewrite everything.
I really hate small libraries and in my projects I tend to rewrite lots of trivial stuff, but that keeps me comfortable.
> I'm finding more and more that Youtube influencer software development is completely disconnected from real world software development.
You don’t need the qualifiers. Influencers are disconnected from the real world, no matter the area. That’s why they’re “influencers”, being a celebrity is the point. Think of it in contrast to someone you’d label a “maker” where the value of what they teach/build is much higher yet they have a comparatively much smaller (and usually geeky) audience.
No, I think it's pretty well connected to real world software development. Most software developers these days, especially in web, tend to be more of "copy the stuff I've seen in tutorials before or find a library that does it" rather than "understand how the stuff I'm copying works and adapt it"
Each layer of framework or abstraction you add, actually tends to make the complexity go up, as it includes so much crap you'll never use but gets in the way of the stuff you will use. And now when something goes wrong not only do you need to understand the programming language, and your own code, but also all the code in the paths you use through this framework, which can easily be 10-20 functions deep (hi facades), and is extremely rarely documented with enough specificity to understand what happens in various corner cases.
My biased opinion that this is Frontend/JS landscape. The amount of tools used to make relatively simple things is staggering. I feel similar things going on in DevOps.
I have been hoping that isomorphic JS would take over PHP for a long time. Sadly these complexity gurus have been sucking the oxygen out of the room for over a decade now. I think it's the corporate "front end developers" who caused these problems. Almost like an envy of full stack or back end developers doing the "real engineering". Which drove the desire to have "real engineering" problems on the front end.
Over some decades of doing development work on legacy systems - sometimes by my companies own design, sometimes contract work for a customer - I've seen lots of things that make me believe that certain customers do prefer complex, buggy software for a very specific reason:
They can hide behind it. "I couldn't finish the task on time because the software had a bug" - sort of stuff. "I couldn't do X because the software doesn't support Y", "The dog ate my homework", etc.
In many cases, it would have been quite possible to design simple, easy and far less bug-prone solutions - but then people working with the software would no longer be able to hide that certain failures might be due to their own incompetence, rather than being a software issue. Therefore - especially in companies with high top-down pressure - people actually prefer working with software that their managers don't fully understand, and that's known for having some bugs and problems.
> They can hide behind it. "I couldn't finish the task on time because the software had a bug" - sort of stuff. "I couldn't do X because the software doesn't support Y", "The dog ate my homework", etc.
I was quite naive most of my career (and life, come to think of it). Back when I changed my first job where I spent 5 years, and was 27 at the time, I replaced one super-complex GUI program with a small GUI wrapper around 2 CLI programs. The thing worked EVERY TIME even with faulty input and on the rare occasion it did not work it gave informative error messages.
The 3 women working with it HATED my guts for it. Took me probably a year after I left to finally understand why. Yeah, I was not very bright back then.
And with time I started to think that people want e.g. Microsoft Teams because they can wipe their arse with it when the need calls for it.
In physical UI our group calls this the Microwave Problem. No one uses the 20 extra buttons on the microwave, they mostly just use one or two buttons. But no one will buy a microwave with few buttons.
Hilarious coincidence. I had and loved that exact same model for the same reasons. Until one of the dials broke and I discovered how utterly irreparable the thing is. Had to get rid of it and indeed, it’s impossible to find similarly simple models. Oh well!
They can, actually! Your microwave probably has an arcane button combo that will turn off the beep. You'd never, ever stumble across it randomly, you need to read the manual. On mine, I need to hold the "2" button for five seconds.
High-end blenders too. All I want is speed dial, pulse switch, and on/off switch. And that's all anyone wants, but for some reason every new generation has to have all these functions nobody uses.
There is value in choice. Not won't necessary always use just the same two buttons, so people like have the option to use other buttons. And quite often more buttons also come with better specs.
Apple used to sell stuff that had “curated UIs”: few control, few functions, and excellent UX. I remember the cleanliness of the iPod vs the overfeatured and complicated competitors.
iPod was useless without iTunes, and I wouldn't call iTunes a curated, excellent UX. We can't only look at the beautiful light and ignore the angler fish behind it.
PS: if we include Sony's minidisk in the competion, the overall listening experience, especially the wired remote was just better. The digital walkman was still a better UX on the device side, except it has an even worse horrible PC experience and Sony barriers that made it a non starter.
The competitors were too cheap to have any feature, usually they had a big play button, a next and previous button and that's pretty much it.
The settings were usually pretty poor on those mp3 players, on mine you had a microphone mode, language, timezone, some shuffle configuration and that's pretty much it.
The iPod did look much much better and refined but in terms of simplicity, it's hard to beat the single play button of an mp3 player which doesn't know to do anything else. Those things were designed like appliance more than tech products.
Alledgedly simple UI (although I never was a Apple guy, was using iRivers at that time), but building the iPod was hard, probably entailing a flew of difficult, complex hardware and design issues to tackle.
Built like a tank. Stainless steel. Compact yet roomy.
And there's no stupid rotating platter.
What they do is rotate the microwave antenna instead. But that's inside the guts somewhere so you never see it. (Why don't they do that on all microwaves? I dunno)
So it's easy to clean. Even cooking. Max microwave.
Only because popcorn manufacturers don't want the quality of their popcorn to be judged by the quality of your specific microwave's popcorn button implementation. They have no control over how it's implemented.
The IKEA MATÄLSKARE Microwave oven has 4 buttons, I press one to add 30 seconds and another one to cycle through the 4 power settings. That is their mid-range microwave, it has 750 watts of power and the more expensive models seem to have similar controls.
Their low end microwave TILLREDA has two knobs, but I've never used it.
This is also my preferred control scheme, and I bought one a few years ago.
To see what's easy to find now, I typed "microwave oven knobs" into amazon.com and got several with the classic mechanical timer and power knob design. Most of those are relatively small, but "commercial microwave oven" found some larger ones.
Honestly, I've had a number of microwaves in my life and I have read the manuals and attempted to use various other types of operation (such as sensor cooking). The reasons why I don't typically use those additional modes of operation are perfectly rational and not due to UI bias as such:
1. I know exactly how to cook something, based on time (and power level), because that's a mental model that's universal across microwaves.
2. I don't know how to cook something and need to follow package directions, which are always expressed as time (and power level).
3. I am iterating towards a desired end state, and want to do so in small step increments. The only possible way to do so is by short bursts of time (at a specified power level).
These are the reasons I've never used any of the extra modes. Technology Connections did an entire hour long video about the popcorn button, and it sounds like at least /some/ microwaves actually implement a very good method, but most don't, and so these types of modes are also generally untrustworthy. Having additional modes has never been a deciding factor in buying a microwave for me, most of the time I bought am microwave based on materials, appearance, and mounting options.
Now, a toaster oven, on the other hand, I want all the modes, and I use them.
> But no one will buy a microwave with few buttons.
Marketing is the king. Spend resources on memeing your way into people minds, then advertise “we removed the cruft to give you <something>” (more space, better experience, whatever you can think of, even if it’s a big stretch) as some sort of revelatory breakthrough and bleeding edge innovation - and they’re gonna buy it and joke about “uncool” others’ microwaves with silly extra buttons are, affirming how cool their microwaves are.
I find such laments annoying, because they're full of obvious platitudes. It's easy to sound smart quoting Einstein and Dijkstra. It's cheap to make generalizations, and point fingers at complex solutions when having both the benefit of hindsight, and ignorance about their true requirements.
"as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs. Maybe it is easier to focus on maintaining one complex database, than to have 3 "simple" ones, and triple admin work, and eventually end up having to sync them or implement distributed transactions.
Something simple to implement now may cause complex problems later. A simple off-the-shelf solution that doesn't fully solve the problem will breed complex workarounds for the unsupported cases, and eventually add complexity of migrating to something adequate. If you didn't correctly predict how a solution will fit all your requirements, you should have simply listened to Einstein.
All the advice to "just" do something "simple" is blissfully unaware that these solutions are not panacea, and it's rarely a plain choice between complex vs simple. Projects have constraints - they may need to work with existing messy systems, inconsistent legal requirements, or changing business requirements. They may prioritize time to market, or skills they can hire for. And there's brutal economics: maybe annual report export is a Rube-Goldberg machine, but it's done once a year, and a rewrite wouldn't pay for itself in 50 years.
The discussion about complexity rarely acknowledges that projects and their requirements grow, so something perfectly simple now may become complex later, in a perfectly rational way, not due to incompetence or malice. Storing data in a plain text file may be beautifully simple in the beginning, and become a bad NIH database later. But starting with a database for 3 rows of data would be overcomplicating things too. And there's cost to refactoring, so always using the ideal solution is not that simple either.
You and I would think the platitudes are obvious but I've been at tables with people where stating those made people blink with that unnamed dread that hits you when you realize you haven't understood something super simple for a very long time and are just now getting it for the first time. That happened... a number of times in my life and career.
Truth is, much less things are as obvious as you and I think.
> "as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
Nah, that's obviously (heh) a non-sequitur; iteration always beats planning. We know it by practice.
> In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs.
That's why you don't ask for permission, you ask for forgiveness. :) Another law of our profession, if not in many others too.
I didn't mean agreement as permission, but as having the same judgement. One person may say bash is the simplest, another that Makefile is even better, and third person will say they'll both become a mess, and it's simplest to use Python from the start, and so on.
Reasonable people may disagree where is the line of "but not simpler". Something that is "simple" to one person, is "primitive" to another.
If someone says they have a simple and elegant solution, but it requires their skills, is it really simpler than a "dumb" solution that more people can understand? (e.g. DB vs Excel? C vs JS?).
Everyone may be in agreement that things should be super simple, but there may be a choice between simplifying implementation vs simplifying operations. Or people may disagree about future requirements and argue that a solution that is the simplest now will hit a complex scaling problem later, and the total-lifetime-complexity of the product will be minimized by another solution instead.
Some complexity is inherent to the problem, but most seems to be incidentally introduced by the realities of deployment (non-functional), configuration (functional) and chaos monkeys (users). There is a particular 'breed' of incidental complexity I see with space cadets and front end developers for sure. Complexity is complex lol.
Outsiders don't see what happens inside companies.
A solution may need to integrate with in-house frameworks and billing (and you'll die trying to make billing simple).
A feature may get added for a big customer, and be warped by their requirements.
A feature may need to be implemented in a hurry (taking on tech debt) to win a bid/contract.
Conway's law shapes implementations - the right team to implement a thing simply may be busy with something more important, so another team will need to work around them.
In such situations the obvious simplest solution may not be available, and you either do what you can given the constraints, or fail to meet business' requirements.
There is also a secondary effect where more complex systems generate a bunch of surrounding materials: tutorials, videos, etc. It also creates job security for the people who learn it, as they have a necessary skill and responsibility in the company, as opposed to something that "just works" which doesn't require that.
Of course. If you were running an evil open-source company, you would favor "solutions" that generates demand for the services you sell (training, tech support contracts,...) while maintaining the belief that all this is necessary in "modern" IT.
I think it's Rich Hickey who links in his one of his talks complexity with entanglement through etymology. This entanglement is sometimes also there to bind the customer. Although more often the "never attribute to malice..." rule is at work, as it's just easier, cheaper, etc... to let the complexity grow.
If we are talking about paper reviews, what I am looking for in a paper as a reviewer is neither simplicity nor complexity. I am not even looking for "novelty". What I am looking for is a thorough and thought-provoking empirical analysis of a problem.
I see plenty of submissions where 1) authors propose a system that is clearly a monstrosity Frankenstein patched together from a dozen of existing ideas - clearly a successful attempt at getting "bold numbers" using as many new shiny toys they could get their hands on without analyzing failure modes of either part in depth; 2) a simple modification of an existing method that accedentally improves the performance of the system but still lacks proper empirical or therotical justification of why this modification helps.
While the second type of papers has at least some marginal value to the community or the reader, I still find such papers mostly useless. What brings value to the reader is a phd student who stared at the problem long enough to find quantitative and verifiable confirmations to his intuitions about the problem that lead to reproducible observations with predictive power. Ie "we experimentally verififed that indeed X affects Y exactly though the mechanism Z described in this paper in all cases, this helped us to improve metric A by B%, agreeing with Z". Not "we did X, and we saw A increase by B%", regardless of the complexity of A.
Readit News
Naturally, people were incentivized to find complex problems so they could solve them. Not only that, I think a lot of tech stacks at other companies evolved by copying this company's ideas, so even smaller companies with even less need for complex solutions ended up having them as well.
Lots of engineers have a fascination with solving complex problems purely for the sake of solving them. When you make that your criteria for promotion you end up have to do many rounds of layoffs in harder times because you’re staffed to the gills with people solving complex problems that deliver little to no actual value.
Software isn't an art project; it's a practical tool to solve practical problems.
Some of my more impactful changes haven't been all that complex; it was just a matter of knowing where and when to spend my time, based on working with our customer team, sales team, and directly talking to some customers.
One of my more praised changes was adding a link to our support backend that saved our customer team minutes of manual work every time. This was literally just adding a permalink: 3 minutes of work. Simple and low-complexity? Yes. But also impactful and moved the needle, and no one else had done it in the previous years.
I have been thinking about this recently in relation to the complex and unwieldy nature of modern car UI (especially in electric cars).
It's so bad that it is keeping me from buying a car that I need.
The conclusion that I have come to is:
Sophisticated consumers are very different than aspirational consumers - and there are always many, many more aspirational consumers.
Therefore, catering to aspirational consumers at the expense of sophisticated ones is a rational economic choice.
An aspirational consumer will put up with all manner of deficiencies and gimmickry because they perceive them as being emblematic of their consumer achievement.
In cruder terms:
They are so happy to be driving a "luxury" car that they don't notice the garbage that came with it. Meanwhile, after decades of luxury car purchases, I just want the shifter to be intelligible ...
The older tesla cars had better controls. The software updates made things worse. The targets became SO small, for no reason. I think the developers must have written and tested the UI on a display firmly mounted on a desk or non-moving car. In a moving car, everything goes to hell.
The newer cars with no stalks (shifter, turn signals, wipers, lights) are just a mess. The display has nowhere to rest your hand, you must stab and hit the correct small target from your seat. They all make you a worse driver, through indirection, confusion, inaccuracy or distraction.
Honestly, I love the UX and UI of a Tesla.
It automates so many things that I find tedious in other cars: lock/unlock, close windows, pre-heat/cool, auto-set navigation to office in the morning and home in the evening, set seating and other adjustments for the driver based on which phone key was used. Navigation works thanks to the free connectivity (all other in-car gpses I've had to use were useless). Nice screen to select and play music. Voice command works reasonably well for selecting music.
It's not perfect, but I prefer the UX & UI over all ICE cars I've driven before.
As an example: my user journey when starting my drive to the office in the morning is a 2 step process: (1) open door and (2) put in drive.
Especially in the winter that used to be 10+ steps for an ICE car: (1) find key (2) unlock car (3) open car (4) adjust seat because my wife drove before (5) press button to start engine (6) front-window defrost (7) rear window defrost (8) manually scrape the ice off the front window (9) select office in gps (10) release parking brake (11) clutch (12) put in gear.
As an example: my user journey when starting my drive to the office in the morning is a 2 step process: (1) find phone, or hope it hasn't run out of battery while you were wherever (2) open door (3) sit down (4) close door and (5) put in drive and (6) drive because it's not actually self-driving despite the name.
Especially in the winter that used to be 10+ steps for an ICE car: don't find key because it's on the keyring I used to lock the house; unlock car while you're walking to it so it doesn't make any difference; (1) open door; (2) sit down; don't adjust seat because plenty of ICE cars have had automatic seat adjustment for decades, this isn't even remotely close to an innovation, I used to have a 1996 with this feature, and it could even be linked to the keypad code you used or the keyfob you used; (3) close door; (4) press button to start engine; automatic defrosters also exist; remote start also exists; (5) put in drive and (6) drive
It's almost like either way the process is literally "get key, get in, and drive away" because a car is a car... The key being your phone doesn't actually change anything.
Good thing it's not an object whose entire purpose is to be driven. Oh wait.
Technology Connections just posted a video where he explains how he had to hold his car’s ugly 90s era stalk for 4 seconds to change his wipers. Had to read a manual to discover that. This kind of crap is very standard in cars with disjoint components cobbled together.
Meanwhile I get my live video sentry alerts on my phone, my car drives me to work, my gear selection is typically putting on a seatbelt and pressing the brake pedal as the car knows the right direction, everything important is contextually accessible via the wheels on the steering wheel instead of having 50 buttons for everything, and so on.
It is simple and powerful. The problem with those luxury vehicles you mention is just awful execution.
The iPhone is lauded as having a good UX. I think (even confining yourself to Apple's own apps) it's actually pretty inconsistent and a lot of things you "just have to know" because there are no cues that would lead you to discovery. But millions of people use them mindlessly because they have adapted to them.
As such, we get lots of car, mostly EV (but not only), up to 100k€/u
The Telsas are indeed not the worst
They are still boring af and not in the top of the basket
What a hugely efficient time and energy saving innovation and only at the cost of lots of your money, personal safety, and basic human agency.
Soon you can probably just hop in and without facing difficult decisions about where to go, get instantly taken to the biggest corporate partner or affiliate advertisers. Maybe robots there can invert you and shake you down so you don’t even need to pull out the money
Teslas seem great if you live in California though.
Deleted Comment
Yeah, he had to take a minute to pull the manual out of the glovebox, flip to the index, look under W, and then flip to another page. I guess he could have had to hunt through a bunch of different menus on a touchscreen instead?
(BTW the fact that you're worried about a stalk being ugly - and the fact that you think they're from the 90s? - shows which type of consumer you are :))
> my car drives me to work
Oh, so your Full Self Driving is actually fully self driving? Weird, I didn't think that existed.
Dead Comment
I don't mean to specifically call him out, but I worry that the complexity is what keeps him popular. And then you have someone like Pieter Levels just slinging raw php into production and not talking about anything like Suspense or Server Side Rendering or Hydration.
They both get to the same ends (well Pieter Levels makes magnitudes of order more money I think) but there is a gulf in complexity. I'd actually argue something like Nomad List is much more feature rich than anything I see from Theo.
There are problems with education: you often have to make things contrived to show problems as fast as possible, and it’s hard to convey all of the nuance. Theo, and others, definitely try to strike that balance and I think it’s fair to say that this is because of how the front end world works rather than because of personalities.
The amount of libraries and code for toy stuff is humongous compared to anything I see in production, and I've seen some monstrosities.
I wonder for how long, though.
I really hate small libraries and in my projects I tend to rewrite lots of trivial stuff, but that keeps me comfortable.
You don’t need the qualifiers. Influencers are disconnected from the real world, no matter the area. That’s why they’re “influencers”, being a celebrity is the point. Think of it in contrast to someone you’d label a “maker” where the value of what they teach/build is much higher yet they have a comparatively much smaller (and usually geeky) audience.
They can hide behind it. "I couldn't finish the task on time because the software had a bug" - sort of stuff. "I couldn't do X because the software doesn't support Y", "The dog ate my homework", etc.
In many cases, it would have been quite possible to design simple, easy and far less bug-prone solutions - but then people working with the software would no longer be able to hide that certain failures might be due to their own incompetence, rather than being a software issue. Therefore - especially in companies with high top-down pressure - people actually prefer working with software that their managers don't fully understand, and that's known for having some bugs and problems.
I was quite naive most of my career (and life, come to think of it). Back when I changed my first job where I spent 5 years, and was 27 at the time, I replaced one super-complex GUI program with a small GUI wrapper around 2 CLI programs. The thing worked EVERY TIME even with faulty input and on the rare occasion it did not work it gave informative error messages.
The 3 women working with it HATED my guts for it. Took me probably a year after I left to finally understand why. Yeah, I was not very bright back then.
And with time I started to think that people want e.g. Microsoft Teams because they can wipe their arse with it when the need calls for it.
two dials is the only ui you need for a microwave.
Really? I want "quiet". A certain level of noise is inevitable, and blenders are way, way past that point. They're louder than food processors!
PS: if we include Sony's minidisk in the competion, the overall listening experience, especially the wired remote was just better. The digital walkman was still a better UX on the device side, except it has an even worse horrible PC experience and Sony barriers that made it a non starter.
The settings were usually pretty poor on those mp3 players, on mine you had a microphone mode, language, timezone, some shuffle configuration and that's pretty much it.
The iPod did look much much better and refined but in terms of simplicity, it's hard to beat the single play button of an mp3 player which doesn't know to do anything else. Those things were designed like appliance more than tech products.
One dial.
Built like a tank. Stainless steel. Compact yet roomy.
And there's no stupid rotating platter.
What they do is rotate the microwave antenna instead. But that's inside the guts somewhere so you never see it. (Why don't they do that on all microwaves? I dunno)
So it's easy to clean. Even cooking. Max microwave.
I love it
They used to, but the standing waves are formed by the cavity geometry, so it's not nearly as good as rotating the platter.
How did you end up with it?
Their low end microwave TILLREDA has two knobs, but I've never used it.
To see what's easy to find now, I typed "microwave oven knobs" into amazon.com and got several with the classic mechanical timer and power knob design. Most of those are relatively small, but "commercial microwave oven" found some larger ones.
My only criticism of it is there’s no button to cancel the time back to zero and you have to wind the timer knob back
1. I know exactly how to cook something, based on time (and power level), because that's a mental model that's universal across microwaves.
2. I don't know how to cook something and need to follow package directions, which are always expressed as time (and power level).
3. I am iterating towards a desired end state, and want to do so in small step increments. The only possible way to do so is by short bursts of time (at a specified power level).
These are the reasons I've never used any of the extra modes. Technology Connections did an entire hour long video about the popcorn button, and it sounds like at least /some/ microwaves actually implement a very good method, but most don't, and so these types of modes are also generally untrustworthy. Having additional modes has never been a deciding factor in buying a microwave for me, most of the time I bought am microwave based on materials, appearance, and mounting options.
Now, a toaster oven, on the other hand, I want all the modes, and I use them.
Marketing is the king. Spend resources on memeing your way into people minds, then advertise “we removed the cruft to give you <something>” (more space, better experience, whatever you can think of, even if it’s a big stretch) as some sort of revelatory breakthrough and bleeding edge innovation - and they’re gonna buy it and joke about “uncool” others’ microwaves with silly extra buttons are, affirming how cool their microwaves are.
Worked for a lot of crap on the market.
"as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs. Maybe it is easier to focus on maintaining one complex database, than to have 3 "simple" ones, and triple admin work, and eventually end up having to sync them or implement distributed transactions.
Something simple to implement now may cause complex problems later. A simple off-the-shelf solution that doesn't fully solve the problem will breed complex workarounds for the unsupported cases, and eventually add complexity of migrating to something adequate. If you didn't correctly predict how a solution will fit all your requirements, you should have simply listened to Einstein.
All the advice to "just" do something "simple" is blissfully unaware that these solutions are not panacea, and it's rarely a plain choice between complex vs simple. Projects have constraints - they may need to work with existing messy systems, inconsistent legal requirements, or changing business requirements. They may prioritize time to market, or skills they can hire for. And there's brutal economics: maybe annual report export is a Rube-Goldberg machine, but it's done once a year, and a rewrite wouldn't pay for itself in 50 years.
The discussion about complexity rarely acknowledges that projects and their requirements grow, so something perfectly simple now may become complex later, in a perfectly rational way, not due to incompetence or malice. Storing data in a plain text file may be beautifully simple in the beginning, and become a bad NIH database later. But starting with a database for 3 rows of data would be overcomplicating things too. And there's cost to refactoring, so always using the ideal solution is not that simple either.
Truth is, much less things are as obvious as you and I think.
> "as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
Nah, that's obviously (heh) a non-sequitur; iteration always beats planning. We know it by practice.
> In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs.
That's why you don't ask for permission, you ask for forgiveness. :) Another law of our profession, if not in many others too.
I didn't mean agreement as permission, but as having the same judgement. One person may say bash is the simplest, another that Makefile is even better, and third person will say they'll both become a mess, and it's simplest to use Python from the start, and so on.
Reasonable people may disagree where is the line of "but not simpler". Something that is "simple" to one person, is "primitive" to another.
If someone says they have a simple and elegant solution, but it requires their skills, is it really simpler than a "dumb" solution that more people can understand? (e.g. DB vs Excel? C vs JS?).
Everyone may be in agreement that things should be super simple, but there may be a choice between simplifying implementation vs simplifying operations. Or people may disagree about future requirements and argue that a solution that is the simplest now will hit a complex scaling problem later, and the total-lifetime-complexity of the product will be minimized by another solution instead.
But why the true requirements are hidden?
A solution may need to integrate with in-house frameworks and billing (and you'll die trying to make billing simple).
A feature may get added for a big customer, and be warped by their requirements.
A feature may need to be implemented in a hurry (taking on tech debt) to win a bid/contract.
Conway's law shapes implementations - the right team to implement a thing simply may be busy with something more important, so another team will need to work around them.
In such situations the obvious simplest solution may not be available, and you either do what you can given the constraints, or fail to meet business' requirements.
So many people in IT have a job because if software were constructed that would be both simple & Just Work, those jobs wouldn't exist.
(For simple cases it "just works" just don't look under the hood or try to do anything non-trivial and it'll be fine.)
I think it's Rich Hickey who links in his one of his talks complexity with entanglement through etymology. This entanglement is sometimes also there to bind the customer. Although more often the "never attribute to malice..." rule is at work, as it's just easier, cheaper, etc... to let the complexity grow.
I see plenty of submissions where 1) authors propose a system that is clearly a monstrosity Frankenstein patched together from a dozen of existing ideas - clearly a successful attempt at getting "bold numbers" using as many new shiny toys they could get their hands on without analyzing failure modes of either part in depth; 2) a simple modification of an existing method that accedentally improves the performance of the system but still lacks proper empirical or therotical justification of why this modification helps.
While the second type of papers has at least some marginal value to the community or the reader, I still find such papers mostly useless. What brings value to the reader is a phd student who stared at the problem long enough to find quantitative and verifiable confirmations to his intuitions about the problem that lead to reproducible observations with predictive power. Ie "we experimentally verififed that indeed X affects Y exactly though the mechanism Z described in this paper in all cases, this helped us to improve metric A by B%, agreeing with Z". Not "we did X, and we saw A increase by B%", regardless of the complexity of A.
Not all reviewers agree with me, sadly.