Tacit knowledge is more important than deliberate practice

And this is that makes practice deliberate and not just repeating things over and over.

Yeah, I can't tell if being the kind of person to whom this feels like bullshit is a character flaw, but it bears no resemblance to the way I learned programming or the way anyone I work with programs. Everything I know is an explicit best practice I learned somewhere and wrote down, and everything people do by instinct is stuff like creating global variables everywhere. To be fair I'm only five years in professionally.

I think you acquire much tacit knowledge by doing explicit practice. You practice and get better even though you don't really know why. The knowledge you gain then is not explicit, it is tacit.

Of course if you have a great mentor so much better. But this reminds me of the medieval guild system. You had to be an apprentice, you had to be an intern for many years. The thing is, highly skilled people could make their main goal to teach others. But economically it makes more sense for them to use that skill themselves.

Therefore we can speculate that a lot of tacit knowledge remains tacit because those who posses it don't want to share it, without good compensation, like having an apprentice who works for them for many years.

That's the funniest thing I've read in a while. Thank you! That is classic.

I somehow became specialist at that randomly (like you, random troubled project thrown at me at the odd chance I d find someth as a cheap new joiner turned into a lucky break and a predisposition for enjoying hunting these) and I start now to see patterns and be helpful in all troubled projects Im thrown at as a joker... to a point I lead a performance optimization mini team now...

If I were to teach, which I kinda do as a leader of the team, I d just give a few shortcut: 99% of perf issues are stupid and discoverable by profiling (which nobody does somehow, the most experienced the least likely the dev will use a profiler and the most likely he ll have 50 wrong migration ideas to make everything better with a huge budget), once you compressed all leaves of code you can find on a hot path, look at why this hot path even exist, chances are it shouldnt even be called as often, if you did that and are still too slow, redesign, multi thread more, remove business need, expand the hardware.

You start also getting an instinct on scale: a troubled team behind by half an hour on a settlement process with an exchange, so big deal, told me they wanted to move the cloud to spin up hundreds of big server with a new scalable design that would take a year to develop with 0 skill in the team yet. How many operation do they need to do in the alloted time ? 30k, with a database on the back. Well, I havent looked yet, but this sounds to me like we can try something before the mega migration lol because 30k units of work is not much and databases tend to be misused (I once fixed a million statement sent by hibernate on a SOAP call, so...) but as you see I try not to give an explanation, it s just an instinct, because prejudice is what kills perf optimization: we'll have to profile each step.

One thing I try to teach is: never migrate to a new library while calling the slow code legacy: you'll end up either failing exactly the same way or fake-suceeding on a small sample and leave the actual failure to the next team who'll call your code legacy before moving to the next fancy fad framework of the year and start the cycle of disaster over again.