Also it is almost never for "funsies," it is instead usually the "wrong solution" to a very real problem. The current system has bad performance, or doesn't support some new use case that is a major company initiative or whatever. But instead of fixing/augmenting the existing system the (probably multiple accumulated pain points by now) are used to justify an overly complex change. In fact the change probably becomes known internally at the company as some silver bullet that will fix all woes further reinforcing the drive to do it.

Even the best developers get ignored if they try to justify pure-tech-debt fixes. So they learn to include fixing tech-debt as part of a fixing a problem that has some _direct_ business relevance if addressed. This gets clearly observed and taught to the all tiers of developers further obscuring the rationale for architectural changes from more senior management.

Yeah the key thing here is it's just so easy to spin anything as the solution to some problem the company has, and there's always problems around.

"for funsies" probably isn't that far off. Because the process is more like someone gets interested in something at some point. Then at that point +~1-6 months someone raises a problem and some senior dev gets stuck on the idea that the awesome thing they read about can solve it. Then before you know it whatever tool they want to use has more bells and whistles than the average mars lander and does everything short of curing cancer.

There's rarely any good correlation between the problem and the solution. That gap can just be bridged by buzzwords. The true correlation is usually between the solution and whatever the most senior dev on the team thinks is shiniest at the moment.

"The very best developers are capable, and avoid complexity. The next best developers are capable, and love complexity. The worst developers are not capable."

It's not always in one's control to avoid complexity. The simplest solution to a problem in a lot of cases may be 2-3x the lift (simplicity tends to require more work, complexity is easy) and thus blocked by the business. A holistically simpler solution may be blocked politically because a certain team doesn't want to own some functionality etc ...

I would say the best developers can see complexity coming and have a healthy fear of it, the medium devs don't mind complexity and the worst devs can't get anything done without increasing complexity.

> The simplest solution to a problem in a lot of cases may be 2-3x

This is such an important point. For whatever reason it has become ingrained in people's heads that the simplest solution must by reductionist logic be the easiest one. And therefore the easiest solution is the simplest one and it is good to be lazy and just introduce complexity everywhere.

The "right" solution is usually the one that models the underlying complexity of whatever phenomenon the the systems is addressing. If you make it simpler, inevitably you'll grow the system to address those use cases. Sometimes this is good, you don't want to err on the side of an overly-complex system. By this reasoning, I usually find building of evolvability and maintainability the be stronger guiding principles.

This is where the whole "MVP" concept got out of hand. MVP didn't mean an overly-simplified prototype. It meant solve one, narrower, problem well. This also pairs well with PGs "do things that don't scale" advice. You are taking on what others might think of additional complexity, to solve a very targeted problem more effectively from others, because using either deeper analysis or first-principles or whatever, you've actually better modeled the underlying complexity. Then you try to scale given those insights.

It seems like a lot of people are too lazy to simplify things though.

You see this a lot with writing as well. It's very easy to ramble on, it's very hard to concisely convey your point.

Simplifying usually requires other people to do work.

That's much harder than doing less simple work on your own team

> There aren't enough of the very best developers for a company to plan around hiring only those.

I've seen no evidence that companies are even trying to hire developers who "avoid complexity". If anything, the interview processes are designed to select for engineers who bathe in complexity. There are so many interviews which consist of "How would you rewrite from scratch this thing that already exists?"

I'm doing technical interviews.

There is such a shortage of people that know the basics of programming, that selecting for such l33t skills is out of the question.

The hiring process right now is not about selecting the best, it's about selecting those that pass some low bar.

I don't know what your company is, but it may not have a reputation for paying well. I've worked both at well-paying FAANG companies and lots of BasicAverageTech companies, and the candidate flow is night and day different. There is no shortage of people that "know the basics." In fact, there is no shortage of really strong candidates. They are out there, looking around to job hop like everyone else. It's just that they are probably just not applying at your company. Not that you can personally do anything about your company's compensation, but that might explain it.

This is europe, and as far as I can tell all companies here have that problem.

On the other hand, great for us who can code :D.

Since 2014 I only apply for jobs where at least 80% remote is part of the deal, I don't care about the money that much.

So if that isn't part of the deal, I don't even bother.

What do you classify as the basics of programming. for loops and if statements?

My current employers hire +- 1/100 applicants. The vast majority fall off before even getting to a coding test. Of the last 20, most are not fluent with conditional logic and iteration, or cannot use a dictionary in an algorithm. In the most recent interview, an "experienced" React developer could not set properties on a JS object.

When an interview process produces the output 'doesn't know how to do basic things' on a "vast majority" of experienced people who've been doing said things daily for years, the most obvious conclusion is that the interview process is flawed.

Why do you think this occurs? It doesn't make sense that people apply for a programming job without being able to do any programming...

I think it's because they have some success with making wordpress do what they want (after a fashion), or copy and paste some Javscript. That makes them a programmer, without knowing what they don't know, even 10 years later.

Maybe I exagerated, but you can't believe that 50% of candidates have such a low capability.

"How high do you score your C++ skills out of 10?" "9/10" "OK, can you explain what a pointer is?" blank stare... "no idea"

I was genuinely curious what you classed as basic programming.

I would definitely consider pointers pretty fundamental if you're a C++ dev.

It is pretty hard to believe that 50% of candidates don't know what a pointer is. I've barely touched C/C++ and still know what pointers are and how they work.

> I've barely touched C/C++ and still know what pointers are and how they work.

Congratulations you’ve successfully triggered the pedantic interviewer. You will now face six questions on pointers in C++ they just looked up each more trivia based than the last.

Who would pass the technical screen must answer me these questions three, ere the onsite he see.

There is one problem with this: It will get on the nerves of the developers that love simplicity.

I'm one of those, and it really gets on my nerves when systems are overengineerd, or use tech that has more drawbacks than benefits for our specific case.

> So, if you want to hire developers who are at least capable, you have to give them some leeway to make things overcomplicated

This is always a challenge in general - how do people learn the lessons of complexity without creating it and then seeing the effects? I wish there was a better word for it as every person who reads "complexity" says well "duh of course I don't want that" before they then go and manufacture another bucket full of it. Complexity masquerades as simplicity - in the first instance it nearly always solves the immediate problem better than anything else. Recognising the latent complexity of choices is one of the hardest but most important skills to learn.