There is, of course, Hello GNU World: https://www.gnu.org/software/hello/manual/hello.html

with versioning and diffs: https://ftp.gnu.org/gnu/hello/

I'm guessing the WebASM Privacy browser equiv must be: Hello Brave GNU World

That "Hello World Enterprise Edition" looks dangerously under-engineered - I could understand it! Far better to follow the best practices demonstrated in the Fizz Buzz Enterprise Edition...

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I don't know all the reasons individual developers would want a more complicated piece of software. Might be to show off, yes, or to learn about a new technology to the detriment of those developers that come after and the Ops people who will have to maintain it. Or they genuinely believe complicated is better.

But the one thing that ultimately adds a lot of unneeded complexity to basically every software project at my work are requirements. That kind of requirement that nobody thought of when the project kicked off. And this kind of requirement that a few months later everyone realizes nobody actually needed. And that you possibly remove after a while. But in the meantime this feature influenced your entire data model or worse.

This is the point where your previously fun work turns into a slog for the duration of said project. Well at least we can still have fun with our hobby projects!

When I look back, I see my "overengineering everything" era as a phase, a live lesson to be learnt. I overengineered a couple of things massively because I didn't know what lied ahead and that helped me, but then I learnt that it's harmful as the "default mode of programming".

As I understood how performance worked, what's maintainability and minimalism (as a general concept), the code I write became minimal and simpler.

Currently I'm working in a mode which can be called "overgrow and extend". I start with the most simplistic code which satisfies the design and my requirements, then refactor any part which cracks under the design to satisfy the requirements without being hacky. This philosophy works like a charm for me. Coupled with my "needless comments", getting back into context and extending/maintaining the code is easier than ever.

I even started to finish and deploy my personal projects. It's that effective for me.

Now I'm learning live documentation, which allows me to write the documentation of the things I'm working on simultaneously. When things finish I also have a workable documentation as a result.

You are of course right that developers have to learn to keep things simple and that skill comes from overengineering stuff. Maybe I have been overly negative on my original comment. As long as it's just a "phase" the long-term benefits of going through that phase should be much higher than the short-term costs to your org.

Good on you for having success with your personal projects!

> it has better extendability and is more generic

Those are noble goals; I think the problem arises when devs forget that "change the code" and "replace with something else" are perfectly valid options. Adding a plugin interface and override hooks, just in case they might be needed, for an internal library, then it's a classic case of YAGNI. When an implementation is so configurable that passing it a config is more effort than writing a bespoke implementation, then it may be an example of the "inner platform effect".

I wrote about this sort of thing on StackExchange a few years ago https://softwareengineering.stackexchange.com/a/382229/11211...

Scalable Hello World with a dynamic server pool size policy, a comprehensive health check so you can restart your instances in case of failure, performance observability, and centralized logging!