（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40266464

本文讨论了识别和解决适当问题而不是制造不必要的复杂性的重要性。作者分享了一些团队做出不必要的复杂决策以及随之而来的负面后果的个人经历。他们提到了一些例子，团队选择使用复杂的技术来实现琐碎的目的，或者为简单的问题寻求复杂的解决方案。作者认为，由于大公司的市场主导地位以及网络效应和平台锁定的力量，它们常常忽视基本的良好实践。然而，颠覆现有行业的初创企业的存在证明了市场在短期内的低效率。作者强调，员工，尤其是工程岗位的员工，应该主动明确问题，评估成本和收益，并提出有效的解决方案。高级工程师是工程、产品和业务领导者之间协作的催化剂。复杂性有其优点和缺点。虽然有些人认为这是一种挑战，但另一些人则因为他们知识的独特性而从中找到乐趣。作者强调了一位教授的例子，他通过专注于经济学中的随机微分方程而获得认可，这使得该学科对其他人来说具有挑战性。尽管提到了复杂性，但作者认为简单性至关重要。为了说明这一点，他们描述了特斯拉先进用户界面的个人经历，以及当关键部件变速杆损坏时遇到的挫败感，揭示了看似复杂的技术的不切实际本质。

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 don't say it is necessarily a good metric for promotions, but solving complex problems is not the same as finding complex solutions

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.

in my defense I can think of at least four times I needed to prototype a complex solution to understand why it was the wrong solution and then discard it

+100. A lot of us love to over-engineer things because that's more fun to solve and looks good on a resume / evaluation.

Kubernetes, (micro-)services, queues, nosql, lambda and other aws service are examples that I've seen in the wild. These can absolutely be valuable and cost-effective, if the problem needs that complexity.

I love engineers that focus on the user, problem and business. They are soo valuable, especially for startups and smaller companies. Engineers that love solving complex problems without thinking much about the user are still awesome, if they can operate in an organisation where that critical thinking is done by others (product people or other engineers)

I once wasted several months of schedule and payroll wrestling to improve a DNN model - which resulted in that model getting much much better thanks to tons of creative and interesting work.

We swapped the learned model for a perfect a oracle and realized the actual problem was elsewhere in the system and was easily fixed. None of those model enhancements were needed.

Not the person you asked, but working on remote sensing and perception I have seen (not once) the teams turning from improving use of available sensor data to things like cutting edge messaging technologies to support real-time data delivery from thousands of sensors (when they have three sensors today and might get another one next year and their current simple streaming will work just fine for up to 20).

While those are interesting problems they have nothing to do with their current perception challenges (that have to be solved for a successful deployment), steal resources from the team and make life harder for a few remaining people actually working to solve current challenges, as they now need to switch to a more complex messaging and rewrite some of their existing utilities.

These weren't fatal to the project or team, but did contribute extra work for net negative value (slower & more maintenance, with no relevant extra features):

- Using Kubernetes to host an application when Docker Compose would do (specialist application with <10 concurrent users).

- Using DynamoDB to store a few kB of temporary data in a processing pipeline, despite having several existing PostgreSQL instances already and no DynamoDB ones.

I worked on a team for a short while that decided to use Cassandra to store a few hundred thousand accounts, despite the data changing only slowly and being an exact match for a relational database. It was one of the worst choices I've ever seen in my career, and the only reason I could find was that people at the time wanted to learn Cassandra.

Sounds somewhat familiar. I worked at a place that replaced a basic LAMP stack with microservices written in Perl and MongoDB as a backing store, for the sole purpose of raising complexity.

And left Mongo on the default settings for the time (speed of return over reliability of saving data), so they ended up with a reporting replica which was MySQL.

Don't think I've seen anything before or since which was architected so exactly backwards.

Think my company burned a year on a solution using Cassandra. I think the problem was 1/3 Cassandra and 2/3rds the people that would pick Cassandra amd Java over PostgreSQL and C# or go.

For less than 10 concurrent users, I would rather say:

- "Using Kubernetes to host an application when NodeJS would do..."

I am not very knowledgeable about Kubernetes or Docker, but often times NodeJS+PM2 worked just fine for me for a small user base.

Years ago, my team at AWS considered writing our own declarative language to configure EC2 instances which would replace some old functionality within CloudFormation (cfn-init) until I pointed out you could achieve the same thing with our existing features (State Manager Ansible playbooks)

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

Stochastic differential equations is fundamental knowledge to do option pricing (black-scholes) among other things. I would expect an average guy educated in that field to be able to understand

In functional analysis, it is somewhat of a sport to attach indices to all four corners of a symbol. I remember overhearing a discussion between two big players in the field, and they obviously did not share the same starting point for reading the indices out loud. For sure, I didn't understand what they were talking about, but neither did they.

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.

> Identifying which problems are worth solving (regardless of their complexity)

I think you are completely wrong. Wouldn't the easy problems have been solved as they are by definition, easy?

If there is economic incentive to solve a problem, and it's easy problem to solve then everyone can do it. That is not true of complex problems.

> Wouldn't the easy problems have been solved as they are by definition, easy?

No, not at all. “Easy” does not mean “obvious”. I once replaced a call to scp with a call to rsync in a script I didn’t originally write. The result was that an operation which used to take more than an hour and was thus run occasionally now took seconds and was executed every time. Both speed and reliability were increased with one simple and easy line change.

While the bottleneck had been recognised earlier, the original authors had learned to live with it. They weren’t aware of how it could have been improved so drastically with so little effort. That’s another thing: easy is relative.

Either way, you’re conflating easy (the opposite of difficult) with simple (the opposite of complex, which is the word used by the person you’re replying to). They are not the same thing. Easy mathematical formulas can make complex fractal shapes and complex programs can do simple things.

Similarly I sped up a python script by 3 orders of magnitude by running a linter on it; the script intended to cache a value for reuse, but neglected to actually reuse the value, resulting in an unused-variable warning in the linter.

> Wouldn't the easy problems have been solved as they are by definition, easy?

Only in an efficient market. And real world markets often have vast inefficiencies. The reasons they're inefficient don't always generalize, either. Companies can behave in certain ways because of personalities (2024 Twitter vs 2018 Twitter), embedded institutional norms (2024 Boeing vs 2020 Boeing vs 1980 Boeing), changing conditions (any 2024 startup vs any 2019 startup's finances), or a million others that don't necessarily spell doom for trying a different approach.

One that's relevant a lot in the real world is market share. Large organizations very frequently get away without doing easy good things for long periods of time, which they can do because network effects and platform lock-in are powerful defenses against disruption. A lot of startups get founded on the idea "large incumbents are not doing this easy good thing, so let's do that and beat them". The fact that this ever works is a sign that incumbents must be leaving a _lot_ on the table, or their lock-in would never be overcome. The very existence of the startup scene is proof of the frequent inefficiency of markets in the short-to-medium-term (or at least of investors' belief in such).

Even in cases where the incentives _are_ aligned and the market _is_ efficient, the world is often in non-equilibrium states. I like to think of incentive gradients as something akin to a (very complex) differential equation, and consider what _simple_ DEs can teach us about them. Consider, say, Newton's law of cooling: dT/dt = -k(T-T_e). Some calc 101 will tell you that solutions to this equation trend (exponentially! so not even slowly!) to a constant stable equilibrium T = T_e. But if you try to use that analysis on a fresh batch of french fries, you're going to get burned, because it turns out T(0) is very relevant to predicting T(1 minute) for realistic values of k.

I slightly disagree.

There are lot of problems that are not identified as “easy” before someone tries to solve them.

Hence, “identifying” step is often required to find the low hanging fruits.

One catefory for these types of issues is “Complex root cause analysis, easy fix”

So there might be a “medium severity” issue - something that is not business-lethal - and that appears hairy enough that everybody just avoids it. Then someone spends some time digging into it and finds it’s some arbitrarily small change that fixes it.

These things happen more often than not.

The trick here is to look at the problem long and hard enough and realize a small change will fix it - instead of doing something completely tangential and complex to circumvent the problem.

These problems fall into the class of “anyone could have fixed it” but only the person who fixed it actually did the hard work of figuring out the root cause.

Reality disagrees with your worldview. There is only one thing that's "worth a promotion" and that's convincing the person able to greenlight it that you deserve it.

This very rarely corresponds with the ability to deliver good software in medium to large enterprises and entirely with your ability to market yourself. Which is easier if you're able to show them a super complex problem you've solved, because it sounds impressive to a mba...

It is very difficult for management to over time not change the rules on promotion enough that it tends towards a random walk where your level is approximately proportional to your length of service. Also,in at least the places I have worked, the enormous emphasis on individual performance both detracts from looking at group performance, i.e. actual productivity, and sucks up so much time. Copying from what execs have heard about Google they have promo boards, overly defined level descriptions, endless work of writing and rewriting promo packets, tactical discussions on which VPs need to be impressed independently of the merits or scope of a change, etc. There is a clear incentive to help people in a sister org over helping your team accomplish its goals.

The whole system seems destined to be replaced by something more useful.

> Reality disagrees with your worldview. There is only one thing that's "worth a promotion" and that's convincing the person able to greenlight it that you deserve it.

It seems pretty clear to me that the person you’re replying to was talking in the sense of how things should be, not describing the way things are. Also, “worth promotion” is not their wording. You’re nitpicking the wrong thing.

You’re assuming what results in a promotion is the same as what’s worth a promotion. Nepotism makes it really easy to convince someone to promote you, but it doesn’t mean someone else doing the same thing would get a promotion.

$ define nepotism

the practice among those with power or influence of favouring relatives, friends, or associates, especially by giving them jobs.

how is that related to someone finding a complicated but irrelevant problem to solve to show how competent they're to the mba thats in the position to greenlight the promotion...?

Do engineers at FAANG choose what problems they want to solve? At places I worked, it was more of management task to choose problems to solve. Developers just worked on tasks they were given.

If all you do as a developer is just work on tasks given to you then you aren't going to rise very high in the ranks in any tech-forward company, FAANG or not. Sure you can make a decent career out churning tickets given to you by someone else, but you'll run into a glass ceiling pretty quickly. The tasks don't just appear out of thin air.

A key part of being a senior+ engineer anywhere is the initiative and autonomy to identify problems, quantify costs and benefits, and work with management and stakeholders to come up with solutions that balance cost, complexity, schedule, and quality.

Much of my work as a staff engineer is working with engineering, product, and business leaders to collectively identify what our biggest challenges are and how we should go about attacking them from the engineering side given all our resources and constraints. And then spearhead the implementation to get projects going the right direction and overseeing more junior team members.

The actual coding is the "easy" part that comes after first defining the problems and specifying solutions and wrangling the competing needs of the business. Engineering should have a seat at that table since we're on the hook to build (and maintain) it, after all.

I agree with you up until the cliche "code is the easy part". People say this at the same time that they complain that people with 10 years of experience can't even solve FizzBuzz.

The amount of badly architectured, buggy code I've seen in a couple of decades working with software tells me that "code is the easy part" is an absolute lie.

Writing good code that's well tested and mostly just works, while being efficient, is such an extremely difficult task that I am not sure many developers in the world can do it. So, no, code is not the easy part, it's only the part where you can probably escape accountability (as no one will be able to tell) unless you have good devs in your team that can properly code review (which is also very rare).

Code is the smallest portion of the job for sure, but as you say it's seldom also the easy part (unless greenfielding a domain you know decently).

I wonder what % of developers simply espouse that mantra to downplay their technical shortcomings to the team.

I mean, code is both the hard and the easy part. I can write the code to get good code, or I can spend more effort on finding the right problems to solve and let others write shitty code.

It hurts to let people do that, but ultimately shitty code still works, while having solved the wrong problem means that all the work goes down the drain.

¿Por qué no los dos? - find the right problems to solve and write good code (or insist on good code being written) to fix them? Because bad code (unless it's throwaway code) will quickly become a problem all of itself...

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.

> Software isn't an art project; it's a practical tool to solve practical problems.

Yet me and my colleagues have seen code that resembles abstract art far too often - it's interesting to look at, but mind-bogglingly complex. Getting rid of that is a delicate balance act, as you risk stepping on the shoes of the people who wrote the code.

Yes it's a problem; that's why I've started to use the "this isn't an art project" line, because some people really do seem to treat it as such.

I do see writing software like writing a book. I write it with the future reader in mind. It needs to be meant to be read.

I picture my colleagues or young engineers 20 years from now combing through my programs, learning the problem domain, learning the tradeoffs we made at the time and why it made sense.

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.

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).

Hmmm ...

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 ...

> keeping me from buying a car that I need.

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.

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

I'm working on a r&d team dedicated to finding ways to repair modern cars at scale

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

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.

I'm finding more and more that Youtube influencer software development is completely disconnected from real world software development.

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'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.

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 wouldn't call it exactly right "all along", after years of him and the Rails team jumping bandwagons and having Prototype, Scriptaculous, jQuery, CoffeeScript, SASS, Sprockets with Babel, Webpack and then whatever is there now shipping as defaults in Rails, along with lots of other stuff.

But he's been reasonable in the last couple years, sure.

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!

I would love a microwave with a slider for power level and a dial for time.

Best I have found so far is the now obsolete Breville BMO734 with jog dials for power and time, plus I use the quick-start and cancel buttons. Importantly you can change power and time even while it is running - very nice. Jog dials are not my favorite but the UI works. Extra feature buttons on inside door jam is a good design although honestly I never use the extra features. Ervery microwave with a keypad has been total shit UI in my experience.

https://www.breville.com/content/dam/breville/us/assets/micr...

I bought a spare second hand one the other day for parts!

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.

I actually have gotten free Vita-Preps on occasion by doing events with the company. Most everything Vitamix has made for years has all sorts of that stuff. They thankfully still have a base line that is simple.

> All I want is speed dial, pulse switch, and on/off switch.

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!

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.

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.

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.

I don’t think that’a true. Too many years have passed so I cannot cite makes and models, but I worked in an IT magazine back then and there were mp3 players with a lot of buttons, not unlike those overcomplicated VHS recorders which sold on “features”.

That's true, those also existed but what I've seen, they were not bought as much as the cheap kind. The ipod gave a reason to pay extra, those half way though products really did not.

Those things really didn't have a single real feature beyond playing music and recording with a microphone in the settings (which nobody really used)

The screen and processing power was way too bad to do anything else anyways, even if they wanted to.

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.

Our microwave has two knobs… one for the power setting and one for the time

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

What would be the advantage of a button to cancel instead of turning the knob back to zero? It seems like that would add quite a bit of complexity to the mechanism to provide a UI that's just different rather than obviously better.

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.

> 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 ” (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.

Just got a new microwave. Panasonic NE 25 F.

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

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.

I had this history teacher in high school giving the class an assignment to write an essay on the events leading up to the Second World War. The first question that came up was how long does this essay need to be – to which the teacher replied that if you can cover this complex topic on one single A4 that would give you full score on the assignment – but that he sincerely doubted that anyone could cover such a complex topic in such a short amount of text. Everyone was mind blown by this argumentation. Nobody had ever heard a teacher say anything like that and that kind of shows how we already as kids are thought that more is always better.

It's a good anecdote but needs a bit more boundary condition. One can always pick a level of abstraction to make an explanation long or short; humans usually pick this level based on context and social convention. For example, if the question was "describe how a keypress results in a screen glyph" can be described in one sentence, or in a long series of books (assuming you get into the firmware, software stack, electronics and materials science, manufacturing processes, etc). For WW2 you could say it started when Hitler invaded Poland, and then France. Or you could get into the Versailles treaty. Or you could talk about the evolution of life on Earth. You might say the latter is pedantic, and it is, but it's also technically an event that led to WW2.

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.

> That's why you don't ask for permission

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.

Oh, I absolutely agree that there are all kinds of constraints when dealing with real world problems, including non technical ones like time constraints and expertise level. But those constraints are never documented and communicated when the resulting complex artifact is released, which causes a lot of unpleasant surprises for users. That's the reason why many engineers avoid such artifacts to mitigate the risks.

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.

Not all reviewers agree with me, sadly.

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.

It would seem that way, but organizations that are truly about improving and growth would have the people available to help improve other things.

As a SQL Server DBA I couldn't possibly understand what you mean.

(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.)

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.

I highly recommend the Rich Hickey talk “Simple made Easy”. Complexity doesn’t sell well at all, but easy does. If a company can hire a bunch of people that know how to use ‘foo’ and the industry keeps talking about ‘foo’, they’ll choose it even if foo is a complete boondoggle. See lambda architecture, most Apache projects, containers, etc

If only simplicity always meant easy to use. There would be no paradox if it did.

One big problem is that for any product/feature not used in isolation in a very controlled context, simplicity is often suboptimal, inflexible and limiting.

Complexity is often the result of building one thing that works well in a variety of situations, a lot of interoperable things or features to work (relatively) well together, or one thing with a lot of ways to interface with it. The worst case is all three - which is true for a lot of software.

The result is a simpler purchasing choice, buy the most flexible product, but at the cost of far more product complexity than any particular user needs.

> One big problem is that for any product/feature not used in isolation in a very controlled context, simplicity is often suboptimal, inflexible and limiting.

"suboptimal" from the global perspective, because to me a simple solution should be a local optimum for a specific problem. For instance, one could argue that the Unix motto "do one thing well" generate lots of specialized programs that, even though they are an order of magnitude smaller than generic programs individually, together they take globally more space for same service level - a symptom of that is e.g. Busybox.

For physical devices, the problem is probably more acute, or at least more visible.

"inflexible and limiting" are terms I can agree on, that's generally how simplification works unless you have a genius idea. I don't see those words as absolute negatives, though, but rather as terms in a trade-off. If the software is open those issues can be mitigated sometimes by hacking; one advantage of starting from a simple (simplistic even), inflexible and limiting solution is that it's easier to evolve - that is to add the necessary complexity.

> “ suboptimal" from the global perspective, because to me a simple solution should be a local optimum for a specific problem.

Except if that requires a company to create and support dozens of “optimal” versions of the same functionality for similar, but different performance impacting, circumstances.

That is not globally simple for the producer, or for customers trying to figure out what version they need. Or having to manage multiple versions for different uses.

> For instance, one could argue that the Unix motto "do one thing well" generate lots of specialized programs

The clear design philosophy of Unix file and stream tools, and there interoperability, does enable much simpler command construction.

But as a maker of tools, you can only leverage interoperability standards if they exist. For many software objects, and ways of combining them, standardized conventions are less well defined, less reliable, or non-existent.

Thus ubiquitous glue code - navigating complex mismatches in information and conventions between components.

Also note, that Unix scripting didn’t eliminate C apps! The cost of Unix tool simplicity, is a massive loss of performance for many use cases. So similar functionality gets recreated over and over again, in virtually every C (or other language) app, to optimize for slightly different contexts.

With work and standards, simplicity “islands” are achieved. But they form an archipelago - not a continent. Need to go in an unsupported direction and you have to swim a mile, instead of walk one.

Completely agree here. Complexity is the result of combining simple things together to optimally solve a specific problem under specific boundary conditions. The reason so many software devs are frustrated by complex artifacts, is that the initial problem and boundary conditions are usually not documented, often because some boundary conditions are actually a hidden agenda hostile to the recipient of the artifact.

Not specifically about ML, but a good paper about unnecessary complexity introduced by a premature 'scalabilitization':

  The COST of a given platform for a given problem is the hardware configuration required before the platform outperforms a competent single-threaded implementation.

Or

  “You can have a second computer once you’ve shown you know how to use the first one.” –Paul Barham

https://www.usenix.org/system/files/conference/hotos15/hotos...

At my current place of work complexity signals minimum viable product stacked upon minimal viable product stacked upon minimum viable product.

Function additions as patches upon a platform that started life as an MVP but was never properly even planned out nevermind built out, and then suddenly demand for new features arrive with dollars attached and the baselines are tossed out with the bath water.

Complexity sells also because it obscures and overwhelms.

"Mark me down, too, as an adversary of complexity, complexity that obfuscates and confuses, complexity that comes hand in hand with costs that serve its creators and marketers even as those costs thwart the remote possibility that a rare sound idea will serve those investors who own."

This is John Bogle talking about finance, but I think it's more generally true.

This idea also applies to software sales.

e.g. A bloated, overly complicated, CMS is easier to sell to a company as a solution than a sleeker, cleaner solution.

“If you can’t dazzle them with brilliance, baffle them with bullshit”

Clients will actively seek it out.

My boss used to try and make clients understand they could do minor adaptations of their workflows, and adapt a few labels of the product and they’d be done and productive in a few days, and they’d requests weeks of system customisation instead.

Yep - seems clients have a knack for asking for the most complicated way of doing things.

Frustrating as a developer that is already slammed, but good for the business overall. But how many times have we all built extremely complex features that never ever get used.

Clients also don't want to be told they'll have to adapt their workflows/processes. A long time ago the COO of our very small company was adamantly opposed to replacing Exchange (which went down with some regularity) with a SaaS because they'd have to make changes to the filing system for their contracts (was before Google had nested labels). The CEO overrode them but the issue was clearly that they didn't want change.

A client that adapts their workflow to a readily available software and customizes the rest isn't a client at all.

First: I think you guys misunderstand the very nature of business. All customers have problems they want YOU to solve in exchange for money. The rest of the people just don't contact you. It's kind of the "survivorship bias."

Secondly: Within an organization, if a project manager has a budget and is tasked with solving a problem, "let's make IT adapt our systems" is not an acceptable solution. Most of the time all you have is money, not software developers or IT staff. They are hopefully working on their core product and not on billing or sending emails.

Thirdly: Don't underestimate the ongoing support that stems from point two. If you ever make adaptions to someone else's software, you know what's going to happen when there's an incident and you call support: They are going to blame your customization, they are not going to understand your needs or customization and they'll kindly string you along until you fix it yourself using precious staff ressources. It is much easier to let someone else do everything from start to finish and pick up the phone when there's a problem.

> seems clients have a knack for asking for the most complicated way of doing things

Sometimes clients don't know what they want. Sometimes you have to show them. “If I had asked people what they wanted, they would have said faster horses” ~ Henry Ford.

The enterprise buying process is geared to achieve consensus and reduce the risk of purchasing the wrong thing. As a result, dozens of groups get invited to participate and all throw their requirements into the ring. Vendors then do contortions to try and sell to these customer, and you end up with software that tries to be everything to everyone.

My dad sold software for electron crystallography. You could buy the software and 4 electron microscopes and fund a team of doctoral students for the same price as one big fancy electron microscope that did the same thing in hardware. He could not compete.

Complex solutions are easy. Simple is hard. Often simplicity takes time, iteration and understanding that comes from actually operating a system. I think the missing link here is the Kaizen-oriented refinement that turns complex into simple over time. I find that modern OO-languages frustrate this process by needing cross-cutting changes to refactor for incremental improvements. Expression-oriented languages (like Clojure) are much more fluid, enabling the incremental refactoring required to transform the initially complex and awkward system into the simple and refined scalable system. Unfortunately, just like other languages, it is possible to write difficult-to-change systems in Clojure. And that seems to be often the way it is done.

Specifically for clojure, do you have any recommendations about how to make systems easy to refactor? I've often read discussions about how dynamic languages are quicker to write and more difficult to refactor than static ones, and I've had my fair share of dealing with issues during refactoring of clojure code, but I don't remember having read anything particular around clojure best practices. Googling for a bit does not produce particularly insightful results, so if you have any insights that'd be awesome.

EDIT: Part of the things I'm finding are my own comments in HN from some years back, in fact :(

Yes, I like to call the style Procedural Composition. The key characteristics are no logic with IO, and all system functions are assembled from higher-order middleware functions. This is the way ring, the web framework, and various client libraries like clj-http work. One of the best ways to get familiar with it is to look at the ring libraries.

What this allows one to do is assemble handlers from lots of small higher order functions. It has the downside of one needing to have initialization well organized and thought out. But the fractal-cul-sac as one co-worker has nicknamed it of ever dividing and increasingly specialized functions with IO and logic twisted together is effectively prevented. One can always modify one handler without affecting others or changing how existing functionality works. And it is always testable in small unit tests because the logic is pure.

Systems built in this style can radically reform themselves in a controllable, reliable and consistent way indefinitely. They are immune to the "apogee" phenomena whereby a system gets to the size and fragility where it can no longer be modified without causing unforeseen regressions, triggering the need to rewrite it to move it forward.

This style is for handler-oriented procedural software common in web services etc. It does not apply to embedded state-machine oriented software that operates real-time control etc. That is a different problem space.

I saw a 2x2 matrix recently that showed how NP-hard problems require exponential time to solve but polynomial time to verify the solution. It gave examples for every other cell of the matrix besides (exponential time to solve, exponential time to verify), which it left as blank or N/A.

I think we have found something that fits that square: truly simple solutions. It's easy to come up with a simple solution that is unsatisfactory, that's not what I'm talking about.

I mean a solution that is so simple and complete, that it was HARD to come up with. It's easy to verify that such a solution is simple, sure, but it is HARD to verify that the solution is truly complete or satisfactory

> It gave examples for every other cell of the matrix besides (exponential time to solve, exponential time to verify), which it left as blank or N/A.

I would be interested in seeing this matrix, because it sounds incomplete to me.

Any NP-complete problem, as in a problem that is exponential to solve but polynomial to verify, is a "decision problem" version of a "optimization problem" that is exponential to both solve and verify.

For example, the decision-problem version of the traveling salesman is, "given a graph of nodes and weighted edges, does there exist a route that visits all nodes with a total edge cost of less than N?" Solutions are hard to compute (evaluate many paths to find a good solution) but easy to verify (evaluate the given path exactly once and compare the cost to N).

Meanwhile, the optimization-problem version of the traveling salesman is "given a graph of nodes and weighted edges, what is the route that visits all edges with the least cost?" The solution is now both hard to compute and hard to verify, because to verify it you also need to consider the entire decision space to determine whether or not there's a route with a lesser cost.

The reason it's hard to refactor to simplicity is that one must feel free to modify foundational assumptions, and the repercussions of that change are both hard to implement (you must recapitulate all following changes with the new assumption) and test. By "foundational assumption" I mean architecture at the high level, and general code organization at the lower level. It is the "second system" problem, writ small but many times over.

Given that code grows over time in accordance with selection pressure, these lateral, foundational changes are always going to be difficult because recapitulating the following growth in general takes the same amount of time as the original system took to grow. The irony is that if that system is making money, it is even LESS likely that the will to simplify it will arise; if the system doesn't make money, then there will be neither will nor resources to try it.

"Physics progresses one funeral at a time", Planck's Principle [1], applies here. Software gets simpler but not laterally within a working project; it only gets simpler with new projects. Luckily software devs seem more open-minded than physicists so we can progress faster than funerals, but not arbitrarily so.

1 - https://en.wikipedia.org/wiki/Planck%27s_principle

I'm always surprised at how much people can talk about simplicity and complexity without giving any definition of those terms.

Basically, the actual content of this article is giving the author's own indirect definition of the word 'complex'. The way I understood the definition is 'complex = overgeneralised and purposefully made harder to understand'.

This is different from other definitions. For example, according to Rich Hickey's definition, multimethods are 'simple' because they provide 'polymorphism a-la carte'. According to author's definition they would be complex because they are an overgeneralised implementation of polymorphism.

It doesn't really matter. There might be a "simple" or a "complex" solution to a problem, but there is no guarantee whoever is given the problem, has the time, or cash, or tools, or skill, or info, or team, etc etc to do the job right. And thanks to history we know quite well, very few like to admit shortcomings and limitations, so endless misunderstandings are the result.

Quoting Herbert Simon - "You can satisfice either by finding optimum solutions for a simplified world, or by finding satisfactory solutions for a more realistic world. Neither approach, in general, dominates the other, and both have continued to co-exist in the world"

I think another aspect of complexity is that your customers, either internal or external, have a very specific idea of what they want, even if their idea is trash. So your product needs to be flexible(complex) enough to support all the use cases conceivable. Going to a customer and saying "trust us, do it this way" will make them lose interest fast.

I work on a small internal ERP, and our new UX guy said “nobody needs all this info”. And I said “agreed, nobody uses more than six columns. But the key stakeholders can only agree on 5.”

I think that’s the key: nobody needs 20 buttons on a microwave, but some people love defrost or popcorn or whatever.

Complexity isn't evil, but hiding in it some secondary interest of who sold that complexity likely is (because of Murphy's Law applied to human psychology?).

Also it has a protective corollary: the interested parts in preserving complexity because injecting lets say a much needed and correct new simpler alternative would either reveal the aforementioned dubious interests or reduce the incumbent's authority (power), hence, all the incentives are set to boycott a system improvement from the top.

I've seen this firsthand:

> A common point raised by ML reviewers is that a method is too simple or is made of existing parts.

And this is self-evidently true:

> ...simplicity is a strength, not a weakness. People are much more likely to adopt simple methods, and simple ones are also typically more interpretable and intuitive.

It happens on a lot of different fields. For instance, a lot of investment management firms offer complicated investment strategies with high fees, even if a simpler strategy would do just as well. Quoting Warren Buffett:

> Investors should remember that their scorecard is not computed using Olympic-diving methods: Degree-of-difficulty doesn't count. If you are right about a business whole value is largely dependent on a single key factor that is both easy to understand and enduring, the payoff is the same as if you had correctly analyzed an investment alternative characterized by many constantly shifting and complex variables.[a]

---

[a] http://www.berkshirehathaway.com/letters/1994.html

I built a full-stack JS framework [1] that I thought would be a hit. As best as I can tell, because it lacks the complexity/word salad of existing solutions, it's mostly been ignored despite being (imo) an elegant solution to a long-standing problem.

[1] https://cheatcode.co/joystick

The license is pretty straightforward and fills in the gaps where the others fail to protect OSS creators (leading to headaches like w/ Redis). Perhaps it's too idealistic to think people will just read it and see if it matches their needs?

no, i've already spent the necessary hours of debating to what extent the agpl3 is compatible with cc-by-sa 4, i don't want to invest those hours again in a license that's used by only one project and, if history is any guide, probably contains important mistakes in how it's written and will need to be redrafted after those mistakes are noticed. i don't have a legal department

Assuming the project/tool was interesting and that was a concern, why not just forward it to your legal department (or manager) to get clarification on if it's an option?

And then you have to wait a month and more and they log time on your project budget. Legal department takes that kind of stuff seriously and don't give off the cuff opinions. So now your project is severely delayed you are under budget and the only thing you got from it is that you maybe gets permission to use a new library.

Ooooor... you can just pick one of hundreds of options with a more commonly used licenses that have already been approved by them many years ago.

This is not realistic. You’re asking new users to go out on a limb to even figure out if they can work with your stuff. the casual “hey send an email to legal” suggestion just cost your potential collaborators weeks of time and thousands of dollars before they can even evaluate the product itself

This is an inviting read, and I think would resonate with many. I avoid javascript for the brittle timesuck it can become maintianing the past while shaking one's fist at other legacy systems. I've never known this to be a problem because I avoid systems that do this to my time, unless it's absolutely unavoidable. It makes me much more productive to use tools that work, and continue to work, so I spend more time with problems than rolling a temple to my own veneration. It might work for others, and it doesn't make it right, it might not work for me, and that doesn't make it wrong.

It's OK not to be for everyone, but your people will find whoever you are being.

Maybe try it as the content for your landing page. Lots of one liners that resonate.

My comment was in relation to the philosophy page of your framework. I thought I had included it.

https://docs.cheatcode.co/joystick/philosophy

I hope you do, I'm sure there would be at least an audience of 1000 true fans for this.

Its one of the only javascript frameworks that stood out to me because of that page having a real enough human story.

Feels similar to the individual developer starting a project wondering if any framework is looking out for them to stay productive :)

I generally avoid the javascript brittle maintenance time-sinks but using it is a reality and knowing that there's simple frameworks that can absorb and handle complexity are valid.

Simple solutions are complex to design. Fullstop.

For instance the ‘do not me think’ GUIs are more complex to design than a CRUD GUI pushing all form fields in a form.

Agree with everything said in TFA.

Except maybe toning down the exhortation to use other people's code so much. I totally agree that using existing solutions is very often the simplest solution; I would not want to rewrite PostgreSQL or any crypto libs. But too many dependencies can get messy; there is definitely a line at which writing your own code specifically for this situation is simpler and better than importing a more generic dependency that is much larger and more complex than it needs to be for your use case (because it covers more than just your use case). Or, (e.g. Left Pad), where the dependency is not actually easier than just writing the code yourself. Importing any dependency carries with it some complexity because it means integrating someone else's code into your own, with the ensuing security implications and version problems. It is not always more complex to write your own code.

My general rule of thumb is that if it'll be quicker for me to code a solution to this specific problem than it would be to learn the API for an import and integrate it, then I'll write the code myself.

Compared to other engineering disciplines, it seems like software is one that is most susceptible to veer towards complexity. Is it the ease of iteration? The relative youth of software engineering?

Relates to ease of iteration, but imo the biggest factor is no real responsibility when things breaks and how it is expected for software to break.

"There's no bragging rights to your software, because it's too simple to use", a developer criticized my product. This reduced its viral spread, though managers liked it.

This has been my single major frustration with academia. Papers are getting long and complex (and very often unnecessarily so) and reviewers like rejecting with "not innovative" or "too little work".

I mean there is a great amount of actual work where the complexity is inevitable, say homomorphic encryption or zero-knowledge proofs, but they are based on solid foundations, starting with the definition of group theory with just four axioms and building up and so on, where every definition is either simple or has lots of uses elsewhere. In contrast, in machine learning and operating systems research, people just seem to like to build algorithms from scratch and make it look incredibly complex (whether it actually is complex) and that just makes my life harder just to read the paper. It's getting close to the point where reading the paper takes more cognitive load than conducting the research myself (having to understand 100s of papers to find the one that's useful for my case). When it does, what would be the point of publishing it?

I recognize there is a lot of useful work in academia but it's really hard to enjoy doing it when the results you would be most proud of is not likely to be well recognized.

As I started to think for some time now: you can have a challenge or a solution.

As engineers, we are often tempted to challenge ourselves, straying away from the latter. There is less perceived pride from following simple solutions.

In professional settings, people care only about complexity.

In the informal media world, people care only about simplicity. The most simple narrative wins out every time.

We’re in a world of extremes.

Yes. We feel this pain all the time in the realm of security. Main problem is the incentives are backwards. You would not pay your municipality to dump garbage on your lot, you pay them to take it away. And yet IT shops go for complex gadgets that end up being as vulnerable as the thing they are intended to protect (this has been the case forever, but if you need a recent example, Evil XDR was presented in Black Hat Asia'24).

Complexity signals innovation: an invention that is merely a "workshop improvement" won't get patented. Complexity signals non-obviousness.

Too easy -> easily copied -> and no long-term competitive advantgage. Complexity signals hard.

The solution to a problem can be simple.

But now we want other things. e.g. car=transport, then: speed, efficiency, style, non-polluting, safety, price, a/c, touchscreens, self-driving etc.

The boundless complexity of human desire.

simplicity is the habit of zen, toaists, sufis and franciscans or the school of wirth - the mystics. Minorities each. It's just not appealing to the masses and the proponents don't really care about mass-recognition, either.

But they go on nevertheless, stubborn as they are.

Edit: Oh, and the razor Occam was a franciscan, too.

IMO simplicity was what sold iPhones to the world. People love simplicity, but they need to be sure that they paid for quality simplicity. So simplicity must be accompanied by something that makes it look not cheap.

In technical organizations (all organizations really), simplicity is also a hard sell: you need people in charge with the ability to say "no" to a lot of ideas. And no one wants to be on the receiving end of a "no".

Those who favour simplicity will always be outnumbered, and their position will be untenable unless the entire top management team agrees. Good luck with that.

It is also one the reasons why the BDFL model works so much better: you need the ability to say "no" a lot.

I’ve not found this to be the case.

I’ve argued at work before for us to deliver a simpler subset of a feature, that delivers most of the value sooner, then to assess later whether we actually need the rest of the feature.

This is also why I’m confident about my continued employment in the age of AI: CEOs are always asking how we can deliver faster. They might not be able to afford more software engineers, but they can always use more.

Software developers may embrace complexity for the purpose of commercial benefit and suffer all its disadvantages, not to mention passing on those disadvantages to users.

However non-commercial users, hobbyist programmers, who derive no commercial benefit from complexity are free to reject it and its disadvantages.

For example, I choose on a daily basis to use simpler, noncommercial software that I compile myself. The use of such software is routinely dismissed, discouraged and even attacked by many software developers commenting on HN. Certainly, its use in place of more complex alternatives does not benefit their interests. It does benefit mine. I like (relative) simplicity.

Each is free to do as they please. If one prefers complexity, as many do, then there is no shortage of alternatives to choose from. Complexity is booming.

Complexity is like a Ponzi Scheme. Ponzi Schemes are effective with sales. Midwits love Complexity & love Ponzi Schemes. Midwits drive the markets due to their population being large.

This is a very good analysis and doesn't fall into the trap most commentaries on stuff like this do: moaning about how something is bad without acknowledging any reasons for it, as if people are just arseholes. C.f. Electron, heavy websites, advertising, non-replaceable batteries, etc.

（评论） (comments)

（评论）
(comments)