5 ms·

IMO Tacit knowledge is what we used to call judgement. Judgement is basically knowing a bunch of things but having a good idea of which things are more importa

IMO Tacit knowledge is what we used to call judgement. Judgement is basically knowing a bunch of things but having a good idea of which things are more important than others, and especially knowing which things are worth spending time on any which aren't. It's like when I see someone talking about financial options and they put everything on the board at once: what are puts and calls, what's an iron butterfly and other strategies, do they need to know the payoff diagram, what about black scholes, what are the Greeks, when should I exercise, and so on. They are all things that a professional option trader knows, but when you're a pro you reduce your cognitive load because you know what actually matters and you are not juggling all these concepts at the same time. It's also the source of frustration when interviewing. Say you've written CPP for many years, you're probably not prepared to answer questions on all corners of the language, even though you're an expert in some sense. Someone relatively newer might be better at that task, because they're thinking a lot about everything, including things they haven't decided are unimportant yet.

SilasX 5y ago
“Judgment” and “tacit knowledge” belong in the same epistemic category as “magic!”, or god-of-the-gaps, or “complexity”. They have no explanatory power, they only flag the absence of a complete explanation: specially, the inability at present to break down and reproduce the process that generated the correct behavior. They should not be revered for their superiority, but scrutinized for the true source of power they draw from.
BizarroLand 5y ago
I think judgement may not be the right word. Perhaps discernment would be a better fit. They share similar concepts but judgement is more final, definitive, decisive in nature whereas discernment is comparatively flexible.
deleted 5y ago
[deleted]
sam0x17 5y ago
Likewise, you can be very good at fixing things without knowing what every single tool in your toolbox is even for. In fact, sometimes not knowing is an advantage -- you might use something in a way that was never intended that ends up solving a problem.
- Koshkin 5y ago
  I seem to be one of those, and people often say that things are afraid of me. And I have no idea why, maybe it’s just luck…
88913527 5y ago
I once interviewed for a front-end role and had to google some CSS property name, as I still haven't committed to memory the difference between "align-items" and "justify-content", but I got dinged for that in feedback: grateful to have received feedback, which often isn't the case. It was one of those things I considered unimportant in the grander scheme of FE development.
- thoraway66 5y ago
  Where merit is dictated by how much time you spend ogling others output and expectations. Amazing. I’m sure all those folks have extensive time spent curing cancer and not just writing web apps for profit too. I’m really looking forward to the day 80% of digital experience is just generated on demand by well known algorithms and filling dependency files just so for a machine (source files included as constraints on memory and cpu behavior, just like which deps to allow) is obsoleted dumb work
- dceddia 5y ago
  This is one of those weird little details that pretty much doesn't matter, because you just try both, and you do that every time, and it's fine. Maybe knowing the difference saves you 15 seconds. I had an aha moment a little while ago when I realized "justify-content" works like the "justify" buttons in Google Docs/other word processors -- left/center/right. It's not a perfect parallel, since justify-content changes its meaning if the flex-direction changes, but it matches with the default behavior.
hinkley 5y ago
Judgement or specialty. Oddly, my first specialty was performance optimization. A predisposition met a trouble project and I spent half my time finding ways to speed up code without making it offensive. Then later projects had problems but no mandate, so I got pushback. I got really good at crypto-optimization - changes that improve performance but look like something else (cleanup, bug fixes, feature requests), and found there’s a whole quadrant of code changes that answer both legibility and speed. There is very little magic or intuition based about any of this. It could be in a book. If anyone knows of a book that covers this, I’d love to gift it to people, because as far as I’m aware I’m seen as a weird (semiretired) street preacher on this subject. But I’m just tweaking existing recipes as it were, adding common ingredients in uncommon ways.
- thoughtFrame 5y ago
  I guess Michael Abrash's Graphics Programming Black Book fits the bill, though no amount of literature replaces getting your hands dirty in late 80s-early 90s level hardware+software. However, while you can do this, you're still missing the things you learned by being part of a team (of the kind which there are probably in the low hundreds right now). How much I'd give to be part of Nintendo or Id software or some other era-appropriate team figuring out how to make the early big 3D games like Mario 64 or its contemporaries on the PSX. Of course you can bust out an SDK and try it out but it probably won't be the same. Those teams built up that kind of tacit knowledge like in this video about software texture mapping https://youtube.com/watch?v=xn76r0JxqNM https://youtube.com/watch?v=xn76r0JxqNM
- wikibob 5y ago
  Could you write that book? Or better yet, how about just writing a series of blog posts or a newsletter? Don't waste time on the setup, just register something on substack.com and I'm sure a bunch of folks here will subscribe. It sounds like a fascinating subject.
- xwolfi 5y ago
  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.
carfacts 5y ago
This is why often when setting guidelines around particular behavior, standards that require some judgement may be better than rules that are to be followed blindly without any discretion. Compare the rules around speed limits, don’t drive above 70mph (no judgement, could be too slow or too quick in a given situation) vs the one often observed and followed in reality, drive at a reasonable speed, roughly what others are driving at (use your judgement about what’s safe).
SavantIdiot 5y ago
Riding a bicycle isn't judgement. But judgement is a type of tacit knowledge.
brigandish 5y ago
I'd describe it as wisdom instead, that thing that needs experience and consideration to (hopefully) come to fruition in oneself.
godDLL 5y ago
Tacit knowledge is the difference between making a decision and then acting, vs being free of the need to make a decision and acting right away. As in successfully. Judgement is exactly the opposite of tacit knowledge.
IsopropylHarbor 5y ago
Your comment hit me right in the reality. I’m a uni student currently taking an OOP Cpp course. At times I don’t know what to ask or how to ask it because of the cognitive load. Value of, address at, private member function, pure virtual functions, bah! I’ll get there, eventually.
- 8note 5y ago
  Those sound like idiosyncrasies of CPP that you shouldn't care about, unless you want detailed expertise in CPP. ... Which is fine if you've got an application in mind, but otherwise, they're a distorted view on the concepts to fit a specific implementation. Most of those concepts are all describing, "when do you tell somebody where to point?" and "when do you follow the arrows?"

SilasX 5y ago

“Judgment” and “tacit knowledge” belong in the same epistemic category as “magic!”, or god-of-the-gaps, or “complexity”. They have no explanatory power, they only flag the absence of a complete explanation: specially, the inability at present to break down and reproduce the process that generated the correct behavior. They should not be revered for their superiority, but scrutinized for the true source of power they draw from.

BizarroLand 5y ago

I think judgement may not be the right word. Perhaps discernment would be a better fit. They share similar concepts but judgement is more final, definitive, decisive in nature whereas discernment is comparatively flexible.

deleted 5y ago

[deleted]

sam0x17 5y ago

Likewise, you can be very good at fixing things without knowing what every single tool in your toolbox is even for. In fact, sometimes not knowing is an advantage -- you might use something in a way that was never intended that ends up solving a problem.

Koshkin 5y ago
I seem to be one of those, and people often say that things are afraid of me. And I have no idea why, maybe it’s just luck…

88913527 5y ago

I once interviewed for a front-end role and had to google some CSS property name, as I still haven't committed to memory the difference between "align-items" and "justify-content", but I got dinged for that in feedback: grateful to have received feedback, which often isn't the case. It was one of those things I considered unimportant in the grander scheme of FE development.

thoraway66 5y ago
Where merit is dictated by how much time you spend ogling others output and expectations. Amazing. I’m sure all those folks have extensive time spent curing cancer and not just writing web apps for profit too. I’m really looking forward to the day 80% of digital experience is just generated on demand by well known algorithms and filling dependency files just so for a machine (source files included as constraints on memory and cpu behavior, just like which deps to allow) is obsoleted dumb work
dceddia 5y ago
This is one of those weird little details that pretty much doesn't matter, because you just try both, and you do that every time, and it's fine. Maybe knowing the difference saves you 15 seconds. I had an aha moment a little while ago when I realized "justify-content" works like the "justify" buttons in Google Docs/other word processors -- left/center/right. It's not a perfect parallel, since justify-content changes its meaning if the flex-direction changes, but it matches with the default behavior.

hinkley 5y ago

Judgement or specialty. Oddly, my first specialty was performance optimization. A predisposition met a trouble project and I spent half my time finding ways to speed up code without making it offensive. Then later projects had problems but no mandate, so I got pushback. I got really good at crypto-optimization - changes that improve performance but look like something else (cleanup, bug fixes, feature requests), and found there’s a whole quadrant of code changes that answer both legibility and speed. There is very little magic or intuition based about any of this. It could be in a book. If anyone knows of a book that covers this, I’d love to gift it to people, because as far as I’m aware I’m seen as a weird (semiretired) street preacher on this subject. But I’m just tweaking existing recipes as it were, adding common ingredients in uncommon ways.

thoughtFrame 5y ago
I guess Michael Abrash's Graphics Programming Black Book fits the bill, though no amount of literature replaces getting your hands dirty in late 80s-early 90s level hardware+software. However, while you can do this, you're still missing the things you learned by being part of a team (of the kind which there are probably in the low hundreds right now). How much I'd give to be part of Nintendo or Id software or some other era-appropriate team figuring out how to make the early big 3D games like Mario 64 or its contemporaries on the PSX. Of course you can bust out an SDK and try it out but it probably won't be the same. Those teams built up that kind of tacit knowledge like in this video about software texture mapping https://youtube.com/watch?v=xn76r0JxqNM https://youtube.com/watch?v=xn76r0JxqNM
wikibob 5y ago
Could you write that book? Or better yet, how about just writing a series of blog posts or a newsletter? Don't waste time on the setup, just register something on substack.com and I'm sure a bunch of folks here will subscribe. It sounds like a fascinating subject.
xwolfi 5y ago
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.

carfacts 5y ago

This is why often when setting guidelines around particular behavior, standards that require some judgement may be better than rules that are to be followed blindly without any discretion. Compare the rules around speed limits, don’t drive above 70mph (no judgement, could be too slow or too quick in a given situation) vs the one often observed and followed in reality, drive at a reasonable speed, roughly what others are driving at (use your judgement about what’s safe).

SavantIdiot 5y ago

Riding a bicycle isn't judgement. But judgement is a type of tacit knowledge.

brigandish 5y ago

I'd describe it as wisdom instead, that thing that needs experience and consideration to (hopefully) come to fruition in oneself.

godDLL 5y ago

Tacit knowledge is the difference between making a decision and then acting, vs being free of the need to make a decision and acting right away. As in successfully. Judgement is exactly the opposite of tacit knowledge.

IsopropylHarbor 5y ago

Your comment hit me right in the reality. I’m a uni student currently taking an OOP Cpp course. At times I don’t know what to ask or how to ask it because of the cognitive load. Value of, address at, private member function, pure virtual functions, bah! I’ll get there, eventually.

8note 5y ago
Those sound like idiosyncrasies of CPP that you shouldn't care about, unless you want detailed expertise in CPP. ... Which is fine if you've got an application in mind, but otherwise, they're a distorted view on the concepts to fit a specific implementation. Most of those concepts are all describing, "when do you tell somebody where to point?" and "when do you follow the arrows?"