Absolute truths I unlearned as junior developer (2019)

I've been a manager for a while and don't do much day to day hands on keyboard coding. I'm still able to help, sometimes quite a bit, but it depends on what the problem is.

If someone on the team is struggling with the gnarly domain specific application logic portions, I will usually direct them to a more senior teammate. I'm more likely to add confusion than reduce it. I'm not in those weeds enough to know how things are changing on a day to day basis. I understand the broad strokes, the roadmap, and where the senior devs are taking things. But I might not be able to tell a dev what the gotchas of their idea really are.

Where I find myself most effective is when I can leverage my experience as a developer in general. I can help them with pros and cons of technology X vs Y, pattern A vs B. I can point out things they might not have been aware of in terms of peculiarities of the tech stack and how it might change things - for instance bugs that are only clear if one understands the details of that standard library call. How to diagnose and debug a problem in an effective manner. How to research a problem.

tl;dr I can and do still talk code and help out my team. But the further one gets from being able to rely on my general experience instead of being embroiled in their day to day back and forth, the less effective I am at it

Streamers in these categories come and go.

On Twitch you can find the developers of the zig and jai programming languages, the developers of Factorio, top competitors from codeforces, and all sort of interesting projects.

Ocassionally there are university professors, security researchers, etc.

In my experience, this is the norm, not the exception. Especially in certain areas like 'web development'. Everybody talks about tests and nods sagely in their direction--but I've rarely encountered some kind of meaningful test harness.

I have read tests for this kind of reason, but usually in codebases without static types. I consider static types mostly a form of machine-verifiable and tool-friendly documentation.

No, it's not. This is the equivalent of saying "if your writing sucks, just use more words". Anyone reading an overly terse, jumbled mess can tell you that's not the silver bullet. Somehow, that is the solution we go for whenever management is involved, until they figure out "oh crap maybe boggling our ICs with bureaucracy is in fact a bad idea". Layering on more communication is not a net positive by default, not even in a world where time isn't a factor.

Heck, we both know most people have neither the mental capacity nor the note-taking diligence to keep up with this all. The system is already showing signs of oversaturation with how many go "what did we discuss again last meeting?"

>But "if you are bad at X, just do X better" is meaningless advice

Several others have already given examples. If you don't have information, stop making 30m-2h meetings when everyone already knows the answer is "we have to do more research", followed by actions such as "make a few quick prototypes and test with the client" or "have the front-facing people ask more questions". Use audio, visual, video media to communicate what becomes terse in words. Use less words and less meetings overall, where possible.

Start thinking about what truly adds value and what is a horrible proxy with near-zero evidence behind it. The default attitude is "never delete until evidence proves otherwise". Anyone looking at Brook's Law can understand how this goes wrong.

I shouldn't even have to explain this. I'm a consumer of the culture, not a producer. The fact ICs have to tell management types how to do their job better is ridiculous: that's management's job to begin with, optimizing communicational processes. I don't expect clients to tell me more than "the product is slow" either, even if I'll take any bit of information they can provide me.