This can be solved by making docs public, but also by having people respond with a link to the docs. So Slack can still be a good interface to Q&A, as long as a single answer is documented.
Some workplace relies on self-documenting code, some would require technical specs to be written in an internal wiki, some uses function/class/module headers.
It is inevitable that someone would ask how should I read the documentation, and any question on slack should be treated as a chance for improvement and better UX for devs.
Repeated questions from different people is a sign of the lack of improvement in the same area.
My usual go-to method to partially solve this issue is to challenge newcomers to write the question they asked and the answer for it, including how to write it, or make change to an existing one, so that other newcomers will find it easier to onboard.
20 years ago, Spolsky wrote a blog post about how good documentation need not be unreadably dry and soulless. [0] From which:
> Rule 1: Be Funny
> Yep, rule number one in tricking people into reading your spec is to make the experience enjoyable.
[...]
> if you work in a company where people will respect you less because your specs are breezy, funny, and enjoyable to read, then go find another company to work for, because life is just too damn short to spend your daylight hours in such a stern and miserable place.
I'm not sure I'd go quite that far - it seems a bit much to leave an otherwise agreeable position just because they insist on humourless documentation - but I think he makes some important points.
[0] https://www.joelonsoftware.com/2000/10/15/painless-functiona...
At the risk of taking things too literally: that's quite an exaggeration. Even the most cautiously written code (short of formal verification) often turns out have serious bugs.
Linus's law (curiously apparently written by ESR) famously states that given enough eyeballs, all bugs are shallow. This implies that the typical initial value of 2 eyeballs is inadequate, but even Linus's law doesn't seem to go far enough. Sneaky bugs can hide for years in mature codebases.
> If you take say SOLID which sounds kind of reasonable, the Single Responsibility Principle in an OCD way can only be met by unary functions. Everything else must be doing more than "one thing".
I don't see where this is coming from. Multiplication is an operation over two operands but it's clearly 'doing one thing', to the extent that this is even meaningful.
Thanks for the article. I think the most difficult issue to solve is the meetings one, especially now that so much work is being done remotely. It's easy to have inconclusive meetings in engineering because you can just handwave your way through a project that drags on for too long and any non-technical stakeholders will have no choice but to put up with it. Also, engineering is complex and it's easy to over-commit and end up with really tough problems to solve.
One thing I'd like to add is that a "meeting" should minimize the number of active participants. If a "meeting" has more than 4 people it should be considered a presentation. It's a waste of to be in a meeting and trying to follow a conversation that you aren't involved in. If there is information in that conversation that others need to hear, it should be documented in some way.
This is something I battle at every job. Every meeting should include as a documented outcome: who owns this gap we just identified?
I'm not quite sure what to make of those criteria. If you want a platform for writing DSLs, I believe Racket Lisp is impressively flexible, but it's a somewhat exotic language.
For flexibility and conciseness, functional languages are the obvious place to look.
In reality, software engineering is about solving problems, business problems, process problems, machine problems, etc. using code in software as a tool.
The 80/20 rule applies here. 80% of time is spent analyzing and developing solutions, 20% of time is spent writing code and developing software.
Too many people focus on the code part, when they should be focusing on problem solving part.
