Over-engineering is under-engineering

> many web developers even pay attention to browser features

What's the point when your business is required to support IE9.

> It would be great if there were more bootcamps that just trained frontend devs on the latest HTML, CSS, and plain Javascript.

Nobody would go there because that's not where the money's at.

>training and best practices <...> the problem of over-under-engineering

That’s what you have to have once you throw a bunch of tools, planks and screws at first graders and let them go. In my 20s I used few local enterprise solutions to help local micro-businesses do their accounting. The base system was obviously dumb and too restrictive to create “apps (tm)”, but it did its job very well. One specific thing about it was that it was infinitely hard (read: know C++/COM and be able to investigate platform issues) to create extensions for it and/or manipulate basic blocks like you can do with web trinity. The result is that no one went that long route of dominating the market with shady solutions that have value from non-tech faces, but are technically crap.

Seeing what some devs could do even in these conditions, I can tell that it was a good state of things for the tasks that platform meant to solve.

I may seem jump on topics on this one, but to not write a poem, look: Perl’s tmtowtdi is highly criticized, but what web allows is a “there are infinite ways to do it” paradigm with no basic blocks or “best practices” like you name it.

Summed up: if you’re writing apps that do edit objects, there is no room for custom element offsets, scroll handlers, sql statements (except select for few cases) and knowledge of http cookies, headers, urls, etc. If you can’t define a datascheme with two clicks, draw a form layout by hand and write final logic after 5 minutes, deploying in half a hour, without caring what platforms/databases/browsers/ languages/frameworks/backups/ maintenance/ides do you choose, then there is no room for business or app logic in your head.

>the latest HTML, CSS, and plain Javascript

Today it is like chasing specifics of plain 80386 assembly — the knowledge that ages faster than you can read on it from zero to top professional experience. If things didn’t get better in a decade, then it is a dead end. Plank, screw and hammer problem never gets old.

I think it does typically mean that in traditional engineering. There's a disconnect because engineering isn't the greatest analogy for software development.

They are fundamentally the same thing.

A bridge built to be twice as strong is measurably better in the sense that it is stronger, yet no better in the sense that it doesn’t achieve its purpose any better. Yet, to make it stronger will involve complicating the design (having a bridge that is twice as strong out of coincidence is just luck - not over engineering).

Comparatively, reimplementing form fields is better in the sense that the experience is more customizable. However, it is no better in the sense that it doesn’t actually help the user fill out a form any easier. Again, the over engineering adds complexity.

In both cases, the added complexity has costs which would have been best avoided altogether.

I think even in software engineering, overengineering can be measurable. For example, let's say an API has an endpoint that responds on average within 10 ms, but it is only called once per hour. Spending resources to decrease that response time, if the latency can be afforded, would be overengineering (or maybe just premature optimization), but you could measure the increase in performance. Also side note, overengineering hardware is often good practice. In the examples you gave (i.e. a bridge), a 2x "factor of safety" could be considered low.

I've adapted to this team anti-pattern by becoming relentlessly skeptical and cynical in my work. I don't let anyone tell me something is "trivial" or "easy" in programming unless I've actually seen it (meaning, with my own eyes, not reading about it on a blog), and protest untested ideas from coworkers vigorously, even if that person is a developer on my team whom I respect. I kind of hate this solution because it makes me automatically resistant to anything new whatsoever, but I hate it less than some of the code I've been forced to write to fill in gaps left by some flavor-of-the-month tech.

The worst thing about reimplementing native controls (and what everyone misses) is that those native controls don't go away. Instead, their behavior becomes undefined as the system grows around the reimplementation.

Also, creating simplicity is usually much harder than creating complexity.

Not just web developers... lots of developers of all kinds. I’ve seen enough cases in desktop and mobile where a nice simple 30 line function was “refactored” into a 2000 line, 6 class, monster object hierarchy Because Design Patterns and because Reusability.

I think the main problem is that once something works it's marked as "Done" and won't get touched anymore. I often over-engineer massively until I really understand the problem and have something working. But then I try to simplify and delete as much as possible. It seems a lot of people skip the last step.

That's not entirely wrong, but I think that engineers fall prey to negativity bias [1] in this area. There are tons of really complex tools that we don't hate on because we barely notice that we're using them. They're either things well-engineered enough that the complexity is mostly hidden (think JQuery equivalents), or less well-built things that we learned so early, or use so frequently, that we rarely notice having to deal with their complexity/poor engineering.

[1] https://en.wikipedia.org/wiki/Negativity_bias

Complex == I don't understand it yet or (even worse) I don't like it and I want to rewrite it.

Simple == I wrote it and I understand it.

How can I escape from this predicament?

It's an awful predicament because the concepts don't stand on their own; they have to lean on me for their meaning.

>To me it's simple. A lot of web developers pretentiously covet complexity because it makes them feel smart to wield it. Plus, they never really learned that engineering is the divination of simplicity from complexity. They don't get over-engineering, because isn't that just more of a good thing?

I think this creeps in on web development in particular because it is so often intensely boring, menial work. When you're a highly educated software engineer that is being paid top dollar to jam out ad-tracking code all day, you end up just making things complex for the fun of it.

It’s better when the punchline comes at the end.

Can some frontend dev explain this? I've had a rough time w/ caching w.r.t. frontends, but my perspective as a backend eng is that I have to fight to get FEs to obey the cache headers I send. Near as I can tell, their preference is to tell their HTTP library to ignore caching entirely, and then implement it themselves, where stuff gets cached for whatever the dev thought it should be. These sorts of implementations are near impossible to invalidate.