hckrnws

It's because if you're building a skyscraper and you decide - oh heck, who needs architects and steel - that's too complex. Let's build this simple and use plastic.

I don't think we're gravitating towards complexity. It's much simpler:

1. We add more functionality to the base of what exists (e.g. HTML). More and more individual features. (e.g. selecting things in the DOM, animations, effects, interactions, tracking state)

2. At some point someone takes all the patterns in the latest wave of functionality and writes a library for them. Library is widely lauded or adopted (see jquery, React).

3. We think of new features building on top what is now the new norm, it's now table stakes. Rinse and repeat.

This is a common pattern in engineering, for example writing new entries to a DB, then at some point going back and compacting.

I'm not entirely clear what the argument being made is. Simple tools are simple, sure.

But there is an awful lot of complexity in otherwise simple things. Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.

I think, often times, people mistake the results of something from the tools that went into it. Such that it can be tempting to think that simple looking creations were made with simple tools. As often, the opposite is the case. It takes complicated tools to build something that looks simple.

Maybe the argument was that you put more effort and work into what you are building than you do that which you use to build it? I think that is largely fair.

That is actually somewhat in focus when discussing a pen versus the "penzilla." For one, building a pen is a surprisingly difficult thing to do. Especially at scale. For two, people rarely want to have a pen for the sake of owning a pen. Instead, you want to write something.

  > something that looks simple.

There's a lot of old sayings that capture this sentiment. "Simplicity is complexity resolved" (Brancusi), "Good design is invisible) (???), "The best craftsman leaves no trace." (Chinese Proverb??).

My favorite is "Sprezzatura"[0]. The act of making something look simple. IME, the mark of a true expert is they make their work look trivial. As if anyone could do it. It's bittersweet that this is the reality, because we seem to have fooled ourselves into thinking things are as simple as it looks ("pun" intended). It's a dangerous trap. Over estimating difficulty will prevent us from trying, but underestimating will make us foolishly spin our wheels. But I think we've built a system where we just normalize wheel spinning. It's true, most wheels are made for spinning. But if they're freely spinning in the air then your car is going nowhere.

[0] https://en.wikipedia.org/wiki/Sprezzatura

Here's semi related talk about simple/complex and easy/hard [1].

[1] "Simple Made Easy" - Rich Hickey (2011) https://news.ycombinator.com/item?id=23905051

Heh, I'm pretty sure Rich Hickey is a fan of React and the Clojure community uses it heavily with Clojurescript.

I think this is not the point of the argument. Power driver solves a problem, but not everyone has that problem. Some jobs just need a drill.

The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").

> The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").

I think this argument isn't valid. The problem that React solves is creating reactive user interfaces. React is trivial to use in it's happy path. The tool's complexity is a red herring because using the tool is trivial and effortless.

To me, this argument is based on specious reasoning. Take for example vending machines. They are trivial to use: pick a product, pay, see it drop and pick up your item. It's dead simple. Does it make any sense to whine that buying items from an automated system is a problem not everyone has, and that the vending machine is far more complex than a seller behind a counter? No. What makes sense is the complexity from the user's perspective, and what effort it requires them to achieve the goals they set forth to achieve. And React makes it trivially easy to put together highly performant reactive web apps.

Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.

> Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.

No, not really. There is more to picking up a tool than some rando's simplistic drive-by judgement. For example, say you have a React SPA managed by a team which built and manage their whole platform, from the CICD pipelines to the hosting solution. All your infrastructure was built around providing a React app and it's backing services. You are then suddenly faced with a need to implement a feature where a user after clicking on a link navigates to a page that just shows static text. Now think. If you implement that page with React then that's a one-point task. Just create a component, fill it with text, post a PR, done. What level of effort does it take you to implement that with another technology? If you go with the simplistic take that plain HTML is better, now you need to set aside time to sort out support for styling, sort out where and how to deploy those assets, work on a process to automate the deployment, etc etc. Now your simplistic drive for simplicity turned into something between a week and a month's worth of work requiring infrastructure changes and adapting deployment strategies, all of this requiring not-so-trivial QA and testing work.

What problems did you solved? Can you describe your system as simpler, and keep a straight face?

The argument is valid and doesn't need over analyzing.

Using react for simple simple things makes it not simple.

But why would I want to use a screwdriver when I could use my power drill? Like sure, the screwdriver works, but it's more effort and slower...

Actually there's lots of times I want to use my hand driven driver rather than a motorized one.

I agree with the other comment mentioning analogies have their limits. Are we going to pick them apart just so we can avoid listening? Communication is lossy. Are we having a conversation or just trying to win a game of our own design?

I add that because how I interpreted taeric's point of a drill and a driver is just a variation of "apples and oranges." You can concentrate on how they're both round fruit or you can recognize there's differences. I mean walk into any machine shop or go to your uncle that likes to make things and have them explain why they have so many wrenches of the same size but in different styles. Often the subtle differences are the most important part. Hell, how many people even know what those numbers do on the power drill? Making use of them really ups your game. Same with adjusting the power level on your microwave. Yet I rarely see people use these things which are highly effective and help avoid many common mistakes.

Sometimes torque is a bad thing.

Analogies have their limits. That being said, there is always a learning curve. Imagine a situation you want your 5 year old to assist you, but you don't want to teach them how to safely use a power drill.

Yeah for sure. Sometimes my drill is not charged and it's easier to grab a screwdriver and give it a few quick turns (https://benton.codes/blackberry), or maybe I can't fit the drill in some space.

But normally I'll use the drill even though it's overkill, because I got other stuff to do :P

Right, my point was more that thinking you can guess the simplicity of a solution based on the complexity of the tools used to build it is a bit misleading. If only because most simple tools are far more complicated than that allows.

Similarly, I would argue that using complex tools to build something generally results in less complicated outcomes. Our computers are basically evidence of that.

> Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.

I would assume the power drill was created first if you include human powered drills, screws came much later than pretty much every other kind of simple machine, and until machine tools were invented, screws as fasteners didn’t really exist outside of specialized applications. They were used for presses and applying force.

John Henry was competing against a steam powered rock drill in the folk tale about him.

If you define power tools as tools driven by electric motors, I would still guess that the drill came before the driver, as rivets seem to be more popular in the steam engine to electric transition period than bolts or screws were.

Slightly confusing things is the fact that a modern drill is almost always a driver too, unless it’s a specific kind of drill like a hammer drill or core drill. Confusing things even more, there are drill bits that are meant to be used with an impact driver, a tool that is used to tighten or loosen fasteners.

As for which is simpler, drill vs (impact) driver, it’s hard to say. A drill has a clutch, and an impact driver has a spring mechanism that applies rotational force when the motor is at its limit. I’d say both are fairly complex, the impact driver is probably a bit more complex than a drill.

I’m curious about the development and history of power tools but it can be difficult to find information about it.

Your progression of "confusing things" happening several times is exactly what I was hoping to elicit. And is why I think it is a bit of a red herring to ask which is simpler.

Love this kind of comment, where one commenter poses a thought experiment about something I'm unfamiliar with, another commenter explains it in full seriousness.

[dead]

[dead]

> Build pyramids if you must, but build them like the Egyptians did: with a clear purpose

For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids? Maybe the rest of this will fall into place for me when I understand that.

Reliable secure high-persistence storage.

eg: The Stone Tape https://en.wikipedia.org/wiki/The_Stone_Tape

some side effects may occur

IIRC, their society depended on it. During peacetime, it was a major economic engine paid for from the royal treasury, with the work starting as soon as a new pharaoh ascended the throne, and the labor provided steady work when agricultural activity stopped due to Nile flooding. Of course, it's only in hindsight with our modern understanding of economics that we can see how such an activity at face value not important to any basic survival need was in fact a key piece of the economic fabric.

Aka, it was a jobs program.

To build a tomb. Not a shrine, not a place of worship, not a functional structure. Not something that could be repaired or repurposed. A tomb and nothing else.

A purposeless pyramid would get bogged down with plumbing and fountains and extra passageways and observation decks and on and on and on. It would have been impossible to build.

> For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids?

For them to be able to properly descend to and navigate the afterlife of course. This is why society today is so broken, all we get for our afterlife is a shitty urn and some bland sandwiches.

Ah yes, because we are all Pharoah

You think you're getting into the afterlife in a measly $2000 casket? Nah, the dead pharaohs had to ride in style.

React piles concepts into your mental backpack: rendering models, hooks, state libraries, routing, and a build pipeline. ... The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework

Yeah, except that a sprinkle becomes a dusting, and then a dusting becomes a coating, and then a coating becomes a clog of dust bunnies, and it's often hard to tell when you need to stop and do it a better way when the business side is pressuring you with deadlines for changes on "what already works".

The whole reason frameworks exist is to _reduce_ the mental backpack by using something that has solved the same problems in the same orderly way.

I'd argue the whole point of React is to enable the modularization of components written in Javascript.

I realized as soon as 1997 that if I wrote some component in Javascript I wanted to stick into a web page I might want to stick two or three of those into a web page and to do that I have to keep the state for those separate, be able to reference the form elements (didn't have access to DOM elements!) with a unique name, etc.

React goes past that and lets you nest components into other components. In some point that's "managing complexity" and not "introducing complexity", except for the fact that when you can easily incorporate 35 third party components into your application that is 35 components each of which introduces its own complexity of one kind or another -- some of the complexity of "modern Javascript" is the complexity of the build system and the framework, but the build system and framework system let you build bigger systems that have bigger problems.

Software is a Jeavons paradox. When you use a library (time efficiency) you are compelled to add more features (complexity)

It insists upon itself.

I'm glad they at least had the bravery to provide a concrete example of what they mean by "complexity". Clearly their example of "React = complex" vs "JavaScript = simple" is actually a fairly controversial take. Does "simple" mean "better", if not, I think we should be chasing the latter.

I'm not even sure it's a controversial take, more of react devs (don't worry, myself included) feeling called out and getting defensive instead of trying to understand something simple.

I like my colleague Simon Morris's observation about software complexity:

> Software has a Peter Principle. If a piece of code is comprehensible, someone will extend it, so they can apply it to their own problem. If it’s incomprehensible, they’ll write their own code instead. Code tends to be extended to its level of incomprehensibility.

> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed

Is it simple though? From my experience, apps written with "sprinkles" tend to become very complex very quickly. Unless the author means something else by "complexity".

I see a coming soon page one time that had a background image, a logo in the middle and 5 lines of text. That was the entire thing. Wondering why it took so long to load I view the source. 30 js files, 5 css, a hundred html tags with 10 classes each.

Wondering the same visiting a web shop I found a seemingly infinite amount of js. Digging a bit deeper I ended up getting lost in some enormous library for rendering unicode smiles with data uri's. It seemed like a good idea as each page was already making many hundreds of requests. If they add 100 smiles to a product description it probably never loads.

In my experience you can avoid things getting very complex by just refusing to add new "features". If that is out of your control it isn't your fault. Build them the pyramid!

Gravitating toward complexity is inexorable because simpler systems are prerequisites of more complex systems. We see the same thing in evolution--it's not inherently directed, except in this sense of prerequisites. Systems can go from complex to simple (e.g., viruses), but complex systems cannot leap into existence -- see https://www.tedcloak.com/uploads/4/5/3/7/45374411/gregory_-_... -- they appear over time, via accretion. Scientific knowledge largely works the same way -- there are prerequisites. e.g., Einstein's concepts were seeded by the Lorentz equations, and of course Newtonian physics.

Of course biologically evolved systems don't occur unless there's some fitness function they satisfy. Well, complex software also provides desired functionality--sometimes the desire is just a result of marketing, but often it's due to real needs.

That an entire population wide brush ya got there. Not true at all. In many many cases, an initial implementation that is supposed to be figuring out the problem is never revised, just shipped. All these "complex code bases" are premature code that will never see maturity, just patches by an ever increasing population that understands the problem less.

Bikes used to be fairly standardized to where you could do most builds and maintenance at home . Now there are hundreds of subcategories , parts are bespoke to the bike , and standards have all been obliterated. Duty cycles are very short . Brakes , BB , headsets , bars , axles , cassettes , freewheels each have half a dozen formats . Bikes are practically disposable. Costs are up over 10 years and quality on many aspects has declined .

There are hundreds of boutique brands and almost none are making any money. No one sensibly pays msrp you can find bikes 60% off easily.

When you think about productivity , in terms of how much utility can be produced by one person, it’s obviously declining . We have more tools, but the bulk of the effort has gone into getting attention rather than providing utility . Even the product development is more about marketing than utility

Lots of engineering disciplines enjoy complexity. It is challenging, and doing challenging things feels like an accomplishment, or demonstration of skill. I think software gets away with higher levels of complexity than I typically see in other engineer disciplines because it has a lower negative impact from the perspective of the business or the end customer. In auto manufacturing, for instance, complexity not only increases r&d costs, it also increases performance unit costs, and typically reduces reliability and maintenance costs (both of which are usually visible to end users). In software, complexity may appear to reduce r&d costs by reusing code in suboptimal ways, but the end effect is marginal slower, marginally higher binary size, and higher maintenance costs, but the end user doesn’t really ever see the direct maintenance cost, just a subscription price or support contract.

Imagine reusing an entire physical assembly for only one of its functions (eg a microwave to get a clock) this is the sort of thing we do in software all the time, but would immediately fall apart in other disciplines.

We can't see software.

You can see if a motherboard has twice the necessary components, or if a robot arm just looks wrong, but if your algorithm to process 1000 records takes a thousand times longer than it should (but still finishes in 100 milliseconds) no one notices.

Until it has to process stuff in real-time that is.

A robot arm is exactly the place you see software acting up. If your algorithm is consistently slow it's fine, the moment it's inconsistent things dont line up and problems happen.

While I don't doubt that trying to "show off" or "job security" is a reason, I think another big one is because too many developers have no knowledge of the low-level basics to even consider that things could be simpler, having only been exposed to overengineered code and indoctrinated in the belief of abstractions as the ultimate panacea. To relate to the example of React and JS in the article, there are likely many web developers now who have never written a single plain HTML page and always started with the minimum React SPA, so they don't realise the former is even possible.

I think complexity used to sell (real architects used abstract factory factories). Today, simplicity sells and while far better I think it can lead people to do dumb things sometimes. There isn't any problem with simplicity of course but rather what people define simplicity to mean. Sometimes it means things like "let's write our own database", because it is "simpler".

Right now, "simple" is meant to translate as "good" for the reader and whatever writer wants it to mean. I'm glad, at least, that the article provides an example (React vs plain Javascript). I don't know for sure but I suspect there are at least some valid arguments for using React vs just grabbing dom elements in Javascript.

Elsewhere on HN https://iaziz786.com/blog/boring-work-needs-tension/

Complexity adds tension.

Bored Software developers add complexity to make their jobs more interesting is my take.

To be a good engineer you had to be stubborn in the early days of your career, you had to have tenacity and persistence to understand and solve the problems you saw. Unfortunately that filter selects for people who are prone to going too far into the detail, who get a satisfaction from conquering complexity rather than avoiding it. Given the lack of big picture thinking, they readily fall into herd-like behavior. Given the ego payoff for the complexity, it is very difficult for them to accept criticisms about their process or lack of perception.

Status and the appearance of being smart.

I have a bee in my bonnet about this software complexity issue. Perhaps it takes large amounts of humility to accept that your job is fairly mundane, and only needs simple code to get the job done? I mean: who wants to turn spanners on a Toyota when you can imagine you're working for NASA, and introduce fascinating new paradigms to your work, that ultimately add complexity. I suspect that's why i've joined so many teams that have tied themselves up in knots of un-grok-able indirection. Another theory I have is that people encounter bad code, and misdiagnose it, identifying the (wrong) solution as needing a big complex architecture.

I think it’s actually easier to make code more complex than it is to identify simple elegant solutions that will continue to work as the code expands.

Gotta pad your CV/promo packet somehow.

It's pure dopamine, from the process, for me. "Eureka!" is a hell of a drug.

There you go. Instead: compression, efficiency and speed are better traits of intelligence in software engineers building these systems and being aware of trade-offs.

Rather than building rube goldberg contraptions and not only it is difficult to refactor them but can kill the entire business if the maintenance costs continue to increase.

If you really want to work with the most pretentious, attention-seeking, optics-loving people, work in robotics. God dammit, how I love the field, but most people there are insufferable.

Weird take: rather the opposite in my team. We look for the simpler solutions due to maintenance burden. Also, we actually deal with very complex tech; virtualization. Our whole premise is to create tooling for convenience, which therefore involves abstractions.

Some complexity in that case is needed, but its aim is to provide a cleaner/simpler access, which is often opinionated, limited to the purpose we have: deployment of development tools for containers.

If you want to experiment, show off as the article implies, start a hobby project.

Edit: removed some fat-fingered typos when I wrote this on a phone

This is a perennial problem, see The Mythical Man Month

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Or if you wan to have more fun read Systemantics

https://en.wikipedia.org/wiki/Systemantics

Technological complexity is often like a warm blanket you can wrap yourself in to avoid the realities of the customer.

Many businesses are built in such a way that you have little hope of directly contacting your customer, but that doesn't mean you can't try. The desire for complexity often disappears like magic when a developer gets to experience a client expressing happiness over the end results of their "clunky" tech stack.

Not sure in what context I need to answer this question, but thought is its the complexity created artificially when work culture, work politics, people and their thoughts collide together and resulting in a multi dimentional complex environment

I think people don't realize how complex simplicity actually is. FFS, we've all see Conway's Game of Life, right? We all solve hard complex problems by solving simple ones, right? Yet, we have a hard time recognizing that simplicity is complex.

The truth is that simplicity is difficult to implement and even more difficult to maintain. It's easy to oversimplify, as all you need is to not be aware of some complexity. Given that there's infinite depth to things, it's always going to be easier to be missing information than to have enough. But then simplicity is difficult to maintain. Because each time we touch something the same process happens, causing things to compound. If you're 99% "good enough" (a pretty high and unlikely number) then 10 times and you're at 90%[0]. Often a small mistake can lead to big problems. If things run without much slack, then things break. Entropy is a bitch.

The way I think about it is the inverse of how we problem solve. We solve big problems by breaking them down into small problems. Their composition solves the big problem. Consequently, any big problem is composed of many small problems. So I don't understand why we are so dismissive of the little things. The difficulty is figuring out which little problems meaningfully contribute to big problems and which little problems have little impact or are contributing to a different big problem. So when we use dumb thought terminating cliches like "don't let perfection be the enemy of good" we're ignoring the reality of the issue here. If someone believes perfection exists, yes, fix that. But only really junior people think that. Far more often it is a disagreement about what is "good enough" and so the cliche just prevents having a conversation to figure out what that is. No one is omniscient, so why not hash this out?

I think we gravitate to complexity because simplicity is not simple.

[0] This is oversimplified. I'm intending this for communication rather than specifics. Obviously how things compound matters. The numbers are made up but the math isn't. You'll have to read between the lines to determine the complexity that exists for a given situation. I can't be 100% accurate, so let's work together to communicate as best as we can.

"Simplicity is the most difficult of all concepts" -Brian Herbert

"I would have written you a shorter letter but I did not have time"

Simple things quite often require the mastery of understanding a domain. Complex stuff is easy to write.

Original HN title: Why do software developers love complexity

When you're 6 procedure calls deep in a model you started from some abstraction on the problem which has hit "well ACKchewally.." variances from the model, it's high cost to go back to top and invent the top level abstraction again, to be only 5 levels deep when you hit the next one.

Putting a late stage "yea I know, but this one time..." hack in, is logistically simpler.

TL;DR we're not addicted to complexity, we're addicted to the abstraction we started with, even when it turns out not to be as good as we thought.

This rings almost true for me - but “addiction” makes it seem like some sort of personal failing, whereas I think the cost of that backtracking and the probability of finding another Balrog in the woodpile later makes it seem like a perfectly reasonable choice.

Source: been there, done that.

Yea, addiction is the wrong word, its hyperbole.

It is perfectly reasonable under the constraint of J Pierpoint Morgan's dictum:

"I don't want it perfect, I want it by Thursday"

If you don't over-engineer how will you ever have job security?

It's very simple: Job security.

To convice their managers that only they understand the horrific code they wrote the software in.

Answer: simplicity may not scale.

A lot of it is smaller companies trying to ape bigger ones.

Your 1-10 person team probably does not to use the same tech facebook or google are using, most of the time.

We reward people that deal in complexity.

I'm not a very clever person, and I keep things pretty simple, so when I explain something to someone, they can generally get a grip on it pretty quickly.

To them it's been such a small jump they think, that person doesn't deserve much of a reward, heck I could have done it.

Whereas when someone talks about the complexity, people think, wow, there's no way that I could have done that, let's pay that person LOTS to keep them

Just have a text config file that comes in a variety of preconfigured flavors ("x mode", "y mode"...) and then also offer a "make your own config" option too.

Most of the time, if I'm working in blender for example, I want some really sane prepopulated shader values and one size fits all rig values for sofas vs chairs, but sometimes I want to go crazy and make chairs out of glass and slime, etc.

I think for some complexity is a look at me and how smart I am type thing the author talks about.

But simplicity also requieres a lot of effort. Complexity is a side effect of laziness and not putting effort in. Common in corporate programming.

Why do some folks love assuming walking backwards to the past is the only reasonable path?

> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).

Having grown up doing webdev at its emergence, those were not glorious years.

Even as a solo developer or part of a small team, it was hard as hell to have a perfect mental image of the app at all times, to understand all the combinatorial possibilities of what state your app is in now and what state you want to head to next.

Trying to forever update retained state is hard as hell, full of incredible opportunity for memory leaks, and created some super weird behaviors.

Even more so, "just write the basic code" doesn't scale. It's not a system that an org can follow. Folks will come and go, each going totally different directions. I don't know how to stress how immature and insane this sounds.

But folks love trashing that which is popular. To declare oneself the only sane mind amid a sea of madness.

I really do hope we see some post-React eras dawn, see more, that this isn't it, on and on. But I respect like hell the switch from a retained mode form of webdev to an immediate mode one. It doesn't just skip by so many really bad failure modes, it's often far far faster than the poor incomplete hacked out vanilla.js solution your org ended up with. I want us to change to move to not be stuck here. But to see where we are as unnecessary complexity, to invent fantastic degrading tales about the weak souls of men for getting us here: this is truly the behavior imo of lowlifes, of those spreading propoganda to spread the thinnest false confidence of hatred and disdain against the world.

Things are complex and that's ok. We are learning. The way out in onwards not idolizing a concocted naive pastoralized past.

You're right that immediate mode is great and makes life so much easier but for most use cases, React is very much a "retained mode" framework. If all of the valuable state in your app has its source of truth on the server (majority of apps), then retaining any of it in React state soup is unnecessary complexity.

People like to bring up how terrible it was to do vanilla.js in the old days but completely ignore that we are not, in fact, still in the old days. Native browser APIs are so much more powerful now and a ton of the pain that React was made to solve is even now handled declaratively with some simple HTML and CSS. No hacked out JS required.

Yes the 90s and 00s were rough for js, especially because of where JS and browsers were at, and also our collective knowledge.

However also it was much nicer in many ways -- we weren't trying to make insane single-page-apps like today.

The irony is that we have all of these powerful frameworks, but somehow they seem to mostly make worse/slower websites than this silly 0-javascript orange site we're on right now.

This comment is on point, so all I'll add is this:

> The way out is onwards not idolizing a concocted naive pastoralized past.

Ah, the noble JavaScript savage of 1999 - so in tune with his environment, his nose twitching in perplexed confusion as the unfamiliar scent of DHTML wafts past.

Unconcerned with a future that he cannot possibly imagine, he launches Dreamweaver and begins coding, secure in the knowledge that the more things change, the more they stay the same.

It plays the same role as feelings to common folk. In other words, most people out there live for feelings: they seek good tastes, smells, comfort and so on. That's their purpose in life. More sophisticated folks collect art or watch opera for the same reason. Brain-heavy individuals enjoy well arranged complexity instead, it provides the sense of mental comfort. All of this stems from our ability to perceive harmony, although in all these examples our ability is glued to lowly things of this world.

[dead]

They seek validation for accomplishing tasks in devious and circuitous ways, and to feel in control of something since they never had that anywhere else.

It's just a misfire on foresight. People writing code try to make the computer do most of the work. When they miscalculate the axes along which the machine must evolve it looks like unnecessary complexity. The structure of human interaction dictates the rest: no engineer fitting a piece into a port built for it in software thinks the designer of the software a genius - he thinks himself the genius for having fit it to the port; but every engineer who doesn't find the port thinks the designer an imbecile.

Maybe when you're a junior, you like watching "the lights flash and the wheels spin" as Steve Summit used to say, but as you get older, more complexity is more stuff you have to audit, maintain, keep in your head as you extend the system, etc. And that's stuff you have less time and patience for. So you are drawn to solutions that are as simple as you can get away with. Especially since systems that did quite a lot with vastly fewer resources are still within your living memory. If you grew up with an Amiga, and your younger colleagues all started with like Windows XP or something, you remember being productive in an environment that they can't even fathom using.

I know this sounds all very "old man yells at cloud". What can I say. Grug dev only telling fireside stories learned from bitter experience chasing shiny rock.

[dead]

Two words…

Job. Security.

You see, if only you knows how it works, how could they get rid of you? /s (obviously /s)