Use your knowledge of a particular area of technology or an industry you are familiar with to share a 'secret' that you have - the more surprising the better!
One of the key principles of writing good software is maintaining an appropriate separation of different level of abstraction.
Humans are really good at mixing them in one place when they write code.
This hurts the long term maintainability of the code. Its reader will lack in-the-moment knowledge possessed by writer and will have to constantly switch mental gears.
Making it harder for them to understand the system and making the defect introduction more likely.
Ideally, you want for each function/etc to descend only 1 level of abstraction.
Hence the secret is that every well-designed software module wants to become a DSL for the problem it's solving 🙂.
Unfortunately, from the writer's perspective, it's hard to notice when you start violating this principle.
I believe a relevant improvement in tooling can help developers to be more productive. And improve the communication between different parts of the team by providing them with better vocabulary to discuss the system.
Notes
Initial long version
The Software Industry has by no means settled on what does the "good code" mean in all details. But there are some broad principles that have emerged. One of the key ones being an appropriate separation of different level of abstraction.
Humans are really good at mixing different level of abstraction in one place at the moment when they write the code.
But that hurts the long term maintainability of the code. As the person who is going to read the code will lack the contextual understanding of the broader system and will have to constantly switch mental gears.
Making it harder for them to understand the system and making the defect introduction more likely.
So what you ideally want is for each function/etc to descend only 1 level of abstraction.
If you are to follow this principle to it's logical conclusion what you'll end up with is each module becoming a kind of DSL for the problem it is solving.
Hence the secret is that every well designed software module want to become a DSL 🙂.
Unfortunately, from the writer's perspective it's rather hard to notice when you start violating this principle.
I believe an improvement in tooling on this level can help developers to be more productive. And improve the communication between technical and non technical parts of the team by providing them with the new vocabulary to discuss the problem.
you don't allways go there though as making it explicit /etc implied additional cost
Unfortunately it's rather hard, from writer perspective, to detect when you're violating this principle
good software design wants to become a DSL?
layers of abstraction leading to better undestanding between product people and SDE
readability of the code
explicit internal dsl
look through my ideas?
Something about transaction costs/efficiency of labor allocation?
On costs of remote work