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

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.

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.

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

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

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

Complexity adds tension.

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

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.

Job. Security.

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

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.

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.

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.

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

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

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

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.

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.

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.