mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#softwareCraftsmanship

0 Beiträge0 Beteiligte0 Beiträge heute

Technical Excellence: Lost. Like Atlantis. But with more AI JavaScript.

Once upon a time, engineers knew things. Not Googled things. Crafted things. We automated builds, wrote real tests, treated code like it could explode if mishandled, which it did, and we were proud when it didn't. It was elegant. Precise. Shameful if the customer found a bug. Now? It's fashionable to push broken features into production and call it MVP.

Nowadays, we want to engineer. But we don't get the space for applying our knowledge. Every training is useless when you can't apply it.

"Senior Developers" parade around with 10 years of experience by repeating the same year 10 times. They chant Clean Architecture but build everything in main(). They talk about TDD, then mock their way into oblivion. They don’t refactor, as it's not in the ticket. They don’t simplify, they just make it work. They wait for ticket assignments like robots awaiting firmware updates.
Worse: nobody creates anymore. They consume tools. No one understands the layers. No one asks why.

Agility? Without engineering excellence, it's just theatre. You can't move fast if you don't know how your engine works.

Want to be agile? Build engineers who:
* Understand architecture beyond drawing hexagons.
* Write tests that assert behaviour, not just lines executed.
* Know the cost of a dependency.
* Automate not for fun, but for resilience.
* Take responsibility before being told to.
* Stop chasing tools & Start understanding systems.
* Build things that work, not just compile.

Technical excellence is not a luxury. It's the foundation. And without it, you're not building software. You're just decorating the Titanic.

Agility without engineering is chaos in a hoodie.

True Engineering Isn't about using tools.

It's in the questions.

Too often, I see "engineering" reduced to assembling frameworks like IKEA furniture, follow the docs, trust the tool, ship it. But real engineering begins where the documentation ends.

Do you know what that smart-syntax language is doing under the hood?
Do you know how your beloved build tool behaves when it comes to automations and generic CI/CD pipelines?
Do you know what your "schema-less" database sacrifices when concurrency climbs?
Do you know how many runtime hacks exist to make your "native" build work seamlessly?
Do you know how your framework manages threads… or fails to?

Many don't. And that's the problem.

We've built castles on sand because the sand came with good tutorials. Engineering isn't about how much you can plug in. It's about how much you understand, especially the parts no one talks about.

If you're not asking, "What isn’t being said?"
You're not engineering. You're just believing and praying.
AI is a perfect example of many people which hype it but don't understand it.
You have incidents, bugs, complexity, legacy and need time for maintenance or migrations? Then you build your system wrong. Technology should help and not hinder us. We need to focus on simplicity, not on overengineering.