working in a freelance work, I need to migrate a script. I was analyzing a module when I read a variable named "$usec" . So I needed to get deep in the code and check the documentation of the language. At the end I figured out the varible means "micro seconds" Who wrote this code used the letter "u" as greek letter "mu". So I remembered the chapter about how to name variables of the #cleanCode #SoftwareEngieering #coding #software
Maintain clear version documentation, test versions thoroughly, and deprecate old versions gradually.
This practice will ensure that your API users are happy. https://hackernoon.com/code-smell-309-query-parameter-api-versioning #cleancode
‘Future-proofing' often leads to unnecessary complexity. Learn how to work confidently with incomplete knowledge in our hands-on workshop on code simplification. Join us for group exercises, discussions, and practical insights that will transform your approach to software design: https://ddd.academy/keeping-it-simple/ #CleanCode #SoftwareArchitecture
Make your code simpler and more maintainable by removing redundant or unused annotations. https://hackernoon.com/refactoring-033-removing-redundant-or-unused-annotations #cleancode
Interesting Sunday read 
https://github.com/zakirullin/cognitive-load?tab=readme-ov-file
It challenges some “sacred” software practices:
Too many small units (functions/classes/modules/microservices) can be harder to reason about than fewer, larger ones.
Sometimes it’s better to re-implement a few functions than to pull in a whole dependency.
It’s time to look into functional programming with
„Getting Clojure: Build Your Functional Skills One Idea at a Time“
by Russ Olsen.
What’s your functional programming gem that makes you a better generalist?
When machines generate large amounts of code, you need to apply one consistent style to all files. https://hackernoon.com/refactoring-032-apply-consistent-style-rules #cleancode
We don't need more. We need less.
Every week:
A new framework.
A new "layer".
A new AI wrapper.
A new YAML format to abstract what used to be a shell script.
And then we wonder:
"Why is our software hard to debug?"
"Why do our builds break randomly?"
"Why is onboarding a 6-month journey through tribal folklore?"
I once said I write bug-free software that can be finished.
People laughed, especially product people.
Not because it's wrong.
But because they’ve forgotten it's possible.
We build complexity on top of confusion:
A + B becomes C.
C + D becomes E.
Now, E is broken, and we would create a new layer, but nobody knows how A or B worked in the first place. For example HTML/JavaScript, we leave it there and just add layers around it.
Take XML.
Everyone says it's ugly.
But you could validate it automatically, generate diagrams, enforce structure.
Now we're parsing YAML with 7 linters and still can't tell if a space is a bug.
Take Gradle.
You can define catalogues, versioning, and settings, but can't update a dependency without reading 3 blogs and sacrificing a goat.
This is called "developer experience" now?
Take Spring Boot.
I wouldn't trust a Spring Boot or any java Framework powered airplane.
Too many CVEs. Too much magic. Too little control.
We don't need "smarter" tools.
We need dumber, boring, reliable defaults.
Start boring.
Start small.
Then only change the 1% that needs to be fast, clever, or shiny.
You'll rarely even reach that point.
Like everyone says, "Y is more performant and faster than X", but no one reached the limit of X. Why should I care? Meanwhile, we use performant AI.
Real engineering is not chasing hype.
It's understanding the system so deeply that you no longer need most of it.
We've replaced curiosity with cargo cults.
We've replaced learning with LLM prompting.
And somehow, we're surprised when AI loses to a 1980s Atari in a chess game.
At least the Atari understood its own memory.
Simplicity = less maintenance = fewer bugs = happier teams.
We need less. Not more.
#devex #simplicity #softwareengineering #nocodependency#stopthehype #bugfree #springboot #gradle #xml #yamlhell #boringisgood #minimalism #AIhype #infrastructure #cleancode #pragmatism #java #NanoNative
Summer's almost over, energy refilled (wishful thinking), so I'd like to return to writing engineering articles. And I am kicking it off with the most explosive topics of all - Singleton design pattern. 
Is it really as evil as many people claim it is? Or is there more to it other than being a glorified global variable? Let's find out! 
➤ https://medium.com/@nerudaj/is-singleton-design-pattern-truly-evil-11b394c222ba
What are your experiences with the Singleton pattern? What is your stage of "grief" (explained in the article) when it comes to it? Let me know in the comments.
Avoid Magic numbers without explanation. You don't know their source and are very afraid of changing them. https://hackernoon.com/code-smell-02-dont-let-mysterious-numbers-rule-your-code #cleancode
Et voilà le test unitaire complet qui ne fonctionne pas, mais qui existe et qui définit entièrement ce qu'on attend du système :
Et me voilà avec un code compact et expressif, testé et réalisé par itération :
#Dev #Software #TDD #CleanCode
Je n'ai pas encore vraiment écrit de code de comportement réel.
MAIS j'ai déjà un test de comportement de ce que j'attends de mon code à coder, le truc réel à faire.
Et on voit bien que le code "parle" et dit ce qu'il a l'intention de faire et ce qu'il a l'intention de tester.
C'est du code simple et compréhensible.
Comment code-t-on aujourd'hui ? : #TDD #CleanCode
Il s'agit avant tout de "faire parler le code".
Si vous ne comprenez pas l'intention de ce code rien qu'en comprenant son contexte, c'est que ce code est nul.
Live TDD demo: write a failing test, ship the tiniest fix, refactor. You’ll leave knowing the green-red-refactor loop by heart. #TDD #CleanCode
PHP 8.5 adds the pipe operator |> 
Cleaner code Fewer temp vars Inspired by Unix pipes
Small symbol, big impact.
Full article: https://thephp.foundation/blog/2025/07/11/php-85-adds-pipe-operator/
#CleanCode is a lot like #TheBible.
Everyone claims to have read it.
Only a few actually have.
Many misuse its teachings.
New chapter added to the Guile Hacker Handbook
This is a book to learn Guile in a #TestDrivenLearning style 
Check it out 
https://jeko.frama.io
The app tutorial got a new use-case implemented.
Time is not absolute. Your code breaks when you treat it that way. https://hackernoon.com/code-smell-307-naive-time-assumptions-and-how-to-fix-it #cleancode
