35 ms·

Experts have it easy (2024)

206 points by veqq 1y ago

9dev 1y ago
> Having someone who’s happy to spend time “just talking”, without any specific goal to solve, will go a long way. This is actually something I love doing with our junior developers: Often they have a question every once in a while, or they don't have any questions for too long so I ask them what they're doing currently. Both often leads to me taking a look, and discovering that they're like five miles deep into a dead end without realising it yet, and we spend an hour or two working on their problem together. I love that time, since they usually start asking more and become increasingly confident calling my decisions into question, which in turn leads me to reflect on why I do things the way I do them, and we both end up smarter than we have been before. One other thing I often notice is that when you're good at something, you don't care about looking good doing it. I have no qualms admitting I don't know something, or that I'd also start asking AI, or just throw some at the wall and see what sticks. This tends to build up a lot of trust with the juniors, since they realise I'm also just putting my trousers on one leg at a time. Sure, it can be frustrating sometimes to wait for them to just… get the obvious right in front of them, but that usually comes very quickly. I can wholeheartedly recommend spending time with your juniors!
- supersparrow 1y ago
  Not just juniors. Seniors too! They (we!) are not immune to stomping 5 miles down the wrong path without realising and only seeing the light after talking it through with a peer.
  - npodbielski 1y ago
    Yes, but with seniors sometimes you can say that something is not right or dead end and some people get angry because they think they are more skilled/experienced/knowledgeable than you. Hearing what other people have to say and thinking about your actions in different light is skill on its own.
- ChrisMarshallNY 1y ago
  You sound like someone that I'd like working with.
- beyarkay 1y ago
  (author here) bless you for helping out the juniors. There's not nearly a strong enough culture of educating juniors IMO
- kunzhi 1y ago
  I love developing junior people for all the reasons you outlined. It's both rewarding and fun. I know that I'm supposed to show up at work to deliver value or whatever, but that all pales in comparison to seeing a young person light up because suddenly they can see the path in front of them. And it's a lovely feeling to have instructed someone one day, then come in the following day or week and they've been on a tear with their new knowledge because they were so excited. One of my favorite feelings in life. Given that, it really boggles my mind the backward view most people seem to have of junior folks. There's a logic that says: "well, training somebody up is very expensive, and then once they have the skills, what's to stop them from leaving?" Like...really? You actually want someone to stay low-skill and produce shoddy results? Besides, if the only thing keeping the person around is their lack of skills, that says more about the place of work than the person. Can't say it makes any sense to me but I have accepted it at this point.
- culopatin 1y ago
  I wish I could work under you. We need more 9devs over junior devs and this industry will be a much happier place
deleted 1y ago
[deleted]
pixl97 1y ago
Taking mechanical stuff apart and fixing it is one of these areas. One of the more recent ones I watched is taking apart large wenches on a bulldozer. There is a metal plate with two bolts on it you have to take off. If you don't know what you're doing you take both bolts out and it flies apart losing stuff because there is a spring behind the mechanism. If you know what you're doing you take out one bolt then put in a bolt twice as long before taking out the second bolt, the long bolt catches the mechanism and releases the spring tension keeping all your parts in one place.
- greazy 1y ago
  Would that not be documented by the manufacturer somewhere?
  - cenamus 1y ago
    Of course, but most people don't have the manuals if they're fixing half broken rusty old winches
    - chneu 1y ago
      I was under the impression we were working with large wenches, not winches.
      - jimnotgym 1y ago
        There is no manual for wenches, and all men are novices
  - marcusb 1y ago
    Yes, but service technicians that are paid by the job often find ways to do a job in far less time using a different approach than the manufacturer suggests. An example: I used to own a Saturn S-series. The manufacturer estimate for replacing the alternator was something like 4 hours of labor, and involved removing the power steering pump (which was above the alternator.) It was possible to replace the alternator in about 30 minutes by removing the front passenger wheel and mud shield, and then accessing the alternator directly.
edelbitter 1y ago
> unguided “water-cooler” interaction This meme needs to stop. Knowledge transfer from experts to novices is way too important to be left to chance. And thanks to pre-pivot StackOverflow we even have considerable data on how much better it can be done, at least for white collar industries. Reducing the effort of experts to give advice, and enlarging the audience benefiting from a singular effort to write it down is orders of magnitude better than chance.
- elcritch 1y ago
  What? No, those free form unguided interactions are very useful for most novices. They're not a replacement for more structured knowledge teansfer, but an important compliment. Sure some novices are just natural talents that can pick up complex material from structured content alone. They're few though. > The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. Often there’s an underlying pattern that the novice can pick up through careful observation, even if neither the expert nor the novice can properly articulate this pattern. That explains part of it well. It's also an effect you can observe with graduate students of nobel prize winners tending to be "related" to professors who won nobel prizes or were part of their labs, etc. There's lessons imparted far beyond the structured material which is often available. Things like mindset, culture, and more are shared this way. Remote work is great, but it does limit these free form personal interactions which can be so invaluable. I'm a big fan of the potential for VR and AR to enable these experiences with remote work.
  - elcritch 1y ago
    Chicken "sexing" is a fun example of how expert knowledge can be transferred without either expert or novice being able to explain it: https://www.youtube.com/watch?v=b7OgZdxRnog&t=174 https://www.youtube.com/watch?v=b7OgZdxRnog&t=174
    - nyanpasu64 1y ago
      I've read that birds used to have penises (and paleognaths and waterfowl still have them today), but the Galliformes (including chickens) developed atrophied penises which are difficult to see (hence chick sexing and feeding males to the meat grinder), and the Neoaves lost them entirely. Though https://prumlab.yale.edu/sites/default/files/brennan_etal_2008_independent.pdf https://prumlab.yale.edu/sites/default/files/brennan_etal_20... suggests the exact nature is more variable between birds in lineages that "have" them
coderintherye 1y ago
>Don’t study the “common” things, but go all-in on the niche pockets. The common things are common enough that you’ll learn them through osmosis regardless of what your main activity is. But the niche things require active study, and ignoring the niches is how you remain a novice. I'd add, work on the niche things that no one else wants to work on but need to be done. That's how I quickly advanced in my career, becoming knowledgeable about systems no one else wanted to touch.
- eterm 1y ago
  I very much agree to get to work tackling the things no-one else enjoys, especially if you find you enjoy it. I learned fairly early on that I enjoy debugging and fixing bugs far more than I enjoy greenfield development. This seems to be less common than yearning for fresh projects to work on, but it also makes me valuable to have on a team. Debugging is an absolute joy, it's like a two-layer puzzle. There's the immediate puzzle of "What's causing this errant behaviour", in which you mechanically dissect the code. You figure out the state the program needs to be in to trip the reported fault. This can be easy or difficult. There's also a secondary puzzle of, "What was the programmer# who wrote this thinking?". This is the enjoyable part. The root cause isn't "Here on line 53, we were multiplying Foo by Bar when we should have been Scrobbling Foo". The root cause is that someone thought that's what needed to happen ( and with PRs, someone else signed it off ). That secondary aspect is fascinating, because it can shine a light on misunderstandings about the product or the API. It'll also lead to reflection and introspection because occassionally you must stop to think, "What if they were right?". Every bug in a program is a learning opportunity. It's an opporunity to expand the understanding of the system, an opportunity to fix procedures or approaches to writing code so it doesn't slip through next time. One of the sad things about the march of AI, is that there's no longer any of that psychology or learning. The answer to, "Why was it written this way?" becomes, "Because the LLM said so". # That programmer might be your past self, but as they say, "the past is a foreign country", and it can sometimes be harder to put yourself in your past mindset than someone elses.
  - flysand7 1y ago
    100%, debugging is an absolute joy, especially with niche systems-level kinda of bugs that simply can not be debugged with simple printf's. I had a friend once asking me to help debug a weird issue over discord. We went through some obvious things like are there any other threads running or is there something obviously wrong with the code. We didn't find anything so we went on to the best part -- trying to figure out the root cause from the panic. Checked the pointer values, wrote them down, checked where the TLS is, wrote that down to. At that point I forgot how Windows had TLS arranged, so I pulled up some docs, while the other guy fiddled around with the debugger. I found the TLS layout, and the debugger we used didn't have any kind of TLS debugging enabled, so we had to pull up PE spec to do some calculations on where the addresses could end up and sure enough the answer came -- we had a TLS corruption. Turns out he used a C bindings library that had a typo that overwrote the TLS and was messing with his variables. Debugging is such a joy when it feels like Sherlock Holmes movies. (*) For anyone who thinks might be misreading this, TLS means thread-local storage, not transport layer security. I'm sure I've had my share of wrong search results because of this too.
MichaelRo 1y ago
As a "senior" (expert) software developer you got a slight edge over a junior as long as you work in the same domain of expertise. As soon as you change project, you're at loss. General intelligence helps but can't make up for domain-specific expertise. Example: move from accounting software to map navigation software. Clueless. Move from map navigation software to financial software. Within financial software move from quantitative pricing to exchange interfacing. Clueless. Sure, you mostly get away with it but inevitably problems will arise that you have no idea what's causing them or even that they are a problem, so you spend days and weeks chasing what the expert figures out in minutes. That's why I prefer to keep the domain when changing jobs because it adds up to being just a software developer.
- philipswood 1y ago
  The edge is not slight. And usually in a new domain you're usually not completely clueless. There is value in growing a truly deep expertise by spending a lot of time in one domain, but a lot of the deeper skills do transfer (or partially transfer) and having mastered a few domains tend to give you deeper meta-skills.
- harrall 1y ago
  While that is true, you also end up learning foundational concepts which are frequently common between fields. You get a major head start when learning. For example, when learning electrical engineering, you might be forced to get good at vector calculus, and then when you move over to mapping software or physical chemistry, it turns out you use the same vector calculus. The application of vector calculus might vary but it sure takes way longer to learn vector calculus than to learn how to apply it differently. Vector calculus probably isn’t the best example but you get what I mean. I just find juniors learn new things so slowly. Hell, when I look back at my university days, it took me a long time to learn anything compared to now.
- xlii 1y ago
  I disagree, because in high specialty domains you even cannot reuse knowledge as it might be proprietary. On the other hand patterns are universal. You sit in a meeting where someone raises problem of „database slow, we have 50M of log entries, we need to delete them” and all the familiarity bells already ring. The open domain knowledge IMO is something that can be extracted from LLMs. Ask LLM for disk-based data cache and it will happily provide. But it won’t ask how many writers or readers you have. For me even imagining this scenario makes my spidey sense tingling.
kubb 1y ago
Ever been an expert who had to work on a codebase created by a novice? They invent the weirdest things. I know I used to do that too 10 years ago.
xlii 1y ago
I find the article interesting and well written. There might be some theory crafting but it resonates with my personal experience, especially this: > The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. I really like spending time with novices, especially if they are truly interested in the domain. It’s symbiotic because it also challenges my own opinions and judgements and the boost often is for everyone. It’s not surprising though that it is hard to explain rationale. How one can fit 2 years of pain in a sentence, a paragraph or even day long story? Direct interaction allows to shorten distance because it aligns on exact personal level. We find the efficient channels of communication based on prior experience, so it’s not building one filar from ground up to have a bridge, but instead use the almost-same-level and build upon it on both sides.
- beyarkay 1y ago
  (author here) Thanks! this was my first anything published to the internet, glad to see it's been received so well. > I really like spending time with novices From reading the various comments about this essay, it seems like there's a pretty sharp divide, some people love spending time with novices, others despise the activity.
  - 12_throw_away 1y ago
    It depends on the novice IME. Some listen and try to follow my advice (good), some listen and ask probing questions (great), some ask such great questions that I end up learning from _them_ (amazing) ... and some nod politely then go back to copy-and-pasting from stackoverflow and chatgpt (makes me want to die).
- pixl97 1y ago
  >How one can fit 2 years of pain in a sentence, a paragraph or even day long story? I like to call it thinking in compressed binary objects. It's like a bunch of concepts I execute without actually thinking about because I do them so often.
nonrandomstring 1y ago
Essay touches on an important point that I also discovered along my research journey; Much of the knowledge of experts is ineffable [0]. And so here's the problem with present "AI". It contains no ineffable knowledge, because that knowledge is never symbolically expressed and cannot be inferred from what is expressed. In fact the "official" narrative often disguises the real knowledge. This is what the analytical elicitation stage of expert systems [1] was supposed to address (a now mature but presently unfashionable branch of "AI"). [0] https://en.wikipedia.org/wiki/Ineffability https://en.wikipedia.org/wiki/Ineffability [1] https://en.wikipedia.org/wiki/Expert_system https://en.wikipedia.org/wiki/Expert_system
teodorlu 1y ago
Any idea where to find the "Hard" and "Expert aesthetics" articles mentioned in the article? The links are giving me 404s. https://boydkane.com/hard https://boydkane.com/hard https://boydkane.com/expert_aesthetics https://boydkane.com/expert_aesthetics
- beyarkay 1y ago
  (author here) Apologies, I've (maybe mistakenly) put dead links for various essays that are works-in-progress, in order to figure out what to prioritize. I know it's annoying, but it does give me very good signal about what people want to read. For example, 2% of people clicked the essay `/hard`, but only 1% of people have clicked on the essay for `/expert_aesthetics`. So I'm frantically trying to finish `/hard` before a streamer reads the main essay tomorrow. If I can ask for constructive critique, how annoyed are you? The metrics are really useful to me, but I don't want to be an arsehole <3
  - teodorlu 1y ago
    Not annoyed. But curious! I agree that mentoring is hard, and I want to read your take. I wonder if we agree on expert aesthetics or not. You write: > Experts tend to have an aesthetic preference towards technically challenging work rather than simple-but-interesting work, and I’ve written more about this phenomenon here: expert aesthetics. When I read the passage the first time, I thought you meant "experts prefer to work on hard problems in order to arrive at simple solutions". But that's not what you're saying!
    - beyarkay 1y ago
      > I agree that mentoring is hard, and I want to read your take. Thanks for the vote of confidence (: I'm kicking myself for not figuring out a mailing list before this essay went viral, but I'll cross-post the essay on my substack (https://beyarkay.substack.com/ https://beyarkay.substack.com/) when it comes out, so you can sign up there to get an email. > I wonder if we agree on expert aesthetics or not. You write: So I'm coining "expert aesthetics" as a relatively unused phrase that I can put my own connotations onto. There'll be more in the essay (; but at a high level, I've observed that, as someone becomes an expert in a field, their sense for what's "beautiful" in that field changes, and _generally_ it starts to focus on things that are technically challenging. That is, experts (IME) tend to find technically difficult things _aesthetically_ beautiful, even though novices might not care one bit about the technical skill required. Examples might help: Wine connoisseurs preferring wine from specific regions or made using specific techniques, while casual drinkers just want something that tastes good. Fashion designers preferring something that's different from last year and riffs off of the current styles, while the general public just want the same old same old. Painters taking delight in still lifes that perfectly capture the reflection of light through a wine glass, while most people just want a pretty sunset or portrait for their wall. This is all still in flux, but that's the gist of what I'm calling "expert aesthetics".
jonathanstrange 1y ago
It's weird that the author contrasts experts with novices. There should be layers upon layers of expertise in between those two options. What happened to the people who do solid work in their field with varying levels of experience without being necessarily experts? Are they irrelevant?
- phkahler 1y ago
  They are effective at solving mazes. They have enough tools to solve most of them, but not as efficiently as they could. They leave more broken branches and string around because they didn't understand an abstraction and tried to break it down in detail to cover every conceivable scenario.
- beyarkay 1y ago
  (author here) I agree, although I only realised this after the essay hit the internet. I think keeping things simple probably helped with the overall argument, but polarising things into "experts" and "novices" isn't a good abstraction to work with. I now think it's more accurate to think that someone is an expert relative to someone else, and only for a specific field. But that'll have to be another essay (:
hindsightRegret 1y ago
One counterpoint I have to this article. Considering expert vs. novice problem-solving: Within their domain, experts leverage highly efficient models. Outside? Rigidity often impedes adaptation. Their ingrained patterns, assets in familiar territory, become cognitive liabilities in the unfamiliar. The novice's counter-intuitive strength lies in a lack of assumptions, fostering the openness to explore without ego.
- hindsightRegret 1y ago
  If the expert has good T skill shape and beginner's mindset for new scenarios - this does not applly.
- lawn 1y ago
  I'd say this is an example of over-fitting, where the expert is too focused on their particular domain.
  - skydhash 1y ago
    But sometimes, there's just not enough variance between the domains. Any NIH attitude is more likely to veer into complicated systems than finding the next best abstractions.
- beyarkay 1y ago
  (author here) I agree that novices have an advantage in that they have few assumptions: > Something you can do independently (and possibly it’s best done without expert supervision), is exploration of the field. You know nothing, and have no biases about what may or may not be useful. Any time you come across something that feels like it has some depth to it, such as a well-written essay series or a deep technical dive, you need to invest heavily into it. As a novice, your one advantage is that everything is new and nobody expects you to be fast. Because of this, you can afford to spend the time to learn as much as possible. I'm not sure that it's correct to characterise an expert by the lack of this though. I think it's correlated, but not all experts are so rigid.
ribcage 1y ago
[dead]
giorgioz 1y ago
This is why for young people is useful to pick a new field where there are no experts yet. I was very lucky to graduate Computer Science just when the iPhone/Android came out. I had two years experience in Android programming where literally no-one could have more than 2 years experience. If I had tried to make it work in C++/Java I would have find myself competing with people with 10 or 30 years of experience. Right now I would recommend young people to go deep into LLM. Do stuff that have never being done before and everyone is a novice!
- tough 1y ago
  I mean most of the papers already come from pretty young folks!
  - giorgioz 1y ago
    Exacty! They chose to go into a new field rather than persuing archeology and restoration.
  - giorgioz 1y ago
    A dear friend of mine from Greece decided to study archeology and did a Phd in LITERALLY Byzantine iconography of penises. Now at 37 he works as workman in a factory producing food. He seemed happy before and he seems happy now. There are many ways to read into this real life events. I'm still struggling to understand it. A part of me sees it as a cautionary tale of pursuing outdated fields. Another parts of me wonders if maybe my friend is happy and everything else doesn't matter. Another part of me wonders if too much unconditional happiness might lead you in dead end alleys. Another part of me wonders if that is false and believing that is preventing me to be happier. Life is chaos.
pards 1y ago
> sometimes you [novice] just need to be able to show them [expert] what you’re doing without any specific question in mind > the vast majority of learning comes from a novice watching how the expert plies their skills, and not from direct questions and answers This succinctly describes why pair programming can be valuable when used judiciously. I've seen large institutions hold long, boring "knowledge transfer" sessions where the expert explains the codebase to a group of novices but these are largely ineffective without practical experience. Pair programming for a few weeks during the transition period (novice drives, expert advises) can be a more effective method to bring a novice up to speed. It works in remote environments, too, but does require synchronous time.
- beyarkay 1y ago
  (author here) If you haven't watched the Factorio head developer's bug-fix videos on youtube, you really should. They're a goldmine of insight. Also the second video is a very strong case in favour of peer-programming. > novice drives, expert advises I've not heard this explicitly recommended, but it's so clearly the best way to do things if learning is the goal.
markus_zhang 1y ago
A quick track from juniors to experts is to convince someone to let you build something big from scratch. It is going to be messy and likely difficult to maintain. But you gain immense experience from that project, so much that you can be a semi expert (and an expert in that specific domain) in just a couple of years. That was how tons of young people who trampolined to senior in just a few years, bagging a lot of experience in the CVs.
- lawn 1y ago
  Especially if it's integrated with a large legacy app or codebase. You'll get so many valuable lessons.
  - markus_zhang 1y ago
    Yeah. Alas such opportunites are pretty much luck based.
joenot443 1y ago
This is a really good article. There's a quality in strong developers which is difficult to select for in an interview but wildly valuable once they're up and running; maybe the best word is "scrappiness". When I interview juniors or interns, one of the questions I like to ask is something like this- "You've got two computer, one Linux one Windows. There's 50gb of files on the Windows machine which need to be moved to the Linux one, but you've only got 1h to do so. What's your strategy?" Anyone with some experience knows it's a bit of a silly question - there are a tonne of unknowns and countless "correct" answers, but that's just the rub - it's not about the academically optimal answer, but about coming up with an answer that would probably work, given the constraints I'd be arbitrarily throwing at them. It's about realizing that the vast majority of decisions we make in software engineering have costs and tradeoffs, and being able to discuss them with a colleague is 10x more valuable than graph traversal. More than anything, I try to select for people that I know spent a good chunk of their formative years behind the computer, just like many of us did. The maze-traversal skills you learn as a child installing Ubuntu on your parents' computer stay with you forever. Given the option, I'd take the self-taught-indie-dev-state-college-grad over the honor-roll-ivy-league-leetcoder any day.
- qiine 1y ago
  soOo how do you do it ? ;p
  - joenot443 1y ago
    Well, the answer I love them to start with is asking if they're single-bay computers and if not, why they can't just turn off both machines and stick the HDDs in the same box :) It's also a great signal if they can follow this up by noting that the Windows drive is probably formatted in NTFS so the Linux instance will need drivers to support it. Otherwise, a wired network + SMB/Samba is a fine solution too, though much slower. Even if they just suggest using an external SSD I'd be relatively happy. More than anything, this kind of question is to see what happens when a junior's asked to do something they haven't done before. Any answer but "I don't know" is a good start.
    - 1y ago
gitremote 1y ago
> This explains the difficulty of training new employees when all your experts are working remotely, as remote work practically eliminates any sort of casual unguided “water-cooler” interaction. In software development remote work, the novice can learn from the expert by screen sharing how they're working on a problem, sometimes called a working session. The expert can point out more efficient ways of working, like installing a tool, or whether they are using the wrong approach altogether.
- beyarkay 1y ago
  (author here) I'm not sure I agree. I certainly think that screen sharing is better than nothing, but remote screen sharing is a strict subset of what you can do while in-person. Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus. I can't describe how many times I've been saved days of work because a senior casually asked what problem I was working on as we both waited in line for a coffee, and they were able to point me in the right direction. As described in the essay, the novice doesn't know when to ask for help. There are other, tangential, reasons to prefer remote work over in-person, but I don't think there's any reason why remote work would be better at educating novices.
  - skydhash 1y ago
    In person interactions is better, but we have a good amount of open-source projects that do fine with remote interactions. The issue with remote interactions is with processes. Instead of having tooling to promote adhoc interactions, most teams will get into some kind of rigid structures because the tooling is imposed from high. I loathe having slack because it quickly becomes full of noise. There should be friction from having another department chiming in. Having announcements in #general and #random have a cognitive load. I like email, because you can have filters and deal with things when it's suitable to do so. Slack is no where close to that.
  - xboxnolifes 1y ago
    > Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus. I haven't yet tried this, but I've wondered for a while if it could be a good thing to just be visibly in voice chat while working if you aren't in a deep focus mode. Make it easy for someone to jump on and have converdation. I've seen people do it and call it open office and it be at specific times, but I'm thinking even more casual than that.
beyarkay 1y ago
(author here) Okay I know this is how the internet works, but I posted my essay here a month ago (https://news.ycombinator.com/item?id=43664345 https://news.ycombinator.com/item?id=43664345) and it died a silent death. Excited to read the comments! But damn the internet is unintelligible sometimes.
- lisper 1y ago
  A new submission on HN typically has 20-30 minutes on the New page before it drops off the bottom. It is pretty much luck of the draw whether or not anyone notices it during that time window.
  - ChrisMarshallNY 1y ago
    Also depends on what's happening, that day. I had an article spend several hours at #1, but it was "second-chanced," and also St. Patrick's Day, so I guess most of the downvoters and competition were off doin' the Pukin' O' th' Green.
deleted 1y ago
[deleted]
kunzhi 1y ago
Nice article, I really enjoyed reading it. I have to give an obligatory shout-out to the Dreyfus Model of learning which I find is often relevant. Keying off that, I caught myself while reading this section: > The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. Often there’s an underlying pattern that the novice can pick up through careful observation, even if neither the expert nor the novice can properly articulate this pattern. I'm 20 years into my programming career at this point and for a long time I really believed this was true and in a sense the "final" stage of mastery. However, I think there is a stage (possibly stages?) of mastery beyond the level of expertness where most answers come quickly through intuition. I think it boils down to "practitioner vs educator" -- some people are amazing practitioners and unquestionably expert at what they do. But, when you ask them to explain themselves, they run into that "I know it's right, but I don't know how" situation. I think the reason for this is that the person is not a great educator, which is a separate skill. Similarly, I've met many great educators who didn't perform well when asked to execute under real-world conditions. This has led me to believe that the combination of "great practitioner and great educator" is one of the rarest breeds out there. The few people I've met with this ability I would not call even 10x engineers but 100x or even 1000x.

206 points by veqq 1y ago

9dev 1y ago

> Having someone who’s happy to spend time “just talking”, without any specific goal to solve, will go a long way. This is actually something I love doing with our junior developers: Often they have a question every once in a while, or they don't have any questions for too long so I ask them what they're doing currently. Both often leads to me taking a look, and discovering that they're like five miles deep into a dead end without realising it yet, and we spend an hour or two working on their problem together. I love that time, since they usually start asking more and become increasingly confident calling my decisions into question, which in turn leads me to reflect on why I do things the way I do them, and we both end up smarter than we have been before. One other thing I often notice is that when you're good at something, you don't care about looking good doing it. I have no qualms admitting I don't know something, or that I'd also start asking AI, or just throw some at the wall and see what sticks. This tends to build up a lot of trust with the juniors, since they realise I'm also just putting my trousers on one leg at a time. Sure, it can be frustrating sometimes to wait for them to just… get the obvious right in front of them, but that usually comes very quickly. I can wholeheartedly recommend spending time with your juniors!

supersparrow 1y ago
Not just juniors. Seniors too! They (we!) are not immune to stomping 5 miles down the wrong path without realising and only seeing the light after talking it through with a peer.
- npodbielski 1y ago
  Yes, but with seniors sometimes you can say that something is not right or dead end and some people get angry because they think they are more skilled/experienced/knowledgeable than you. Hearing what other people have to say and thinking about your actions in different light is skill on its own.
ChrisMarshallNY 1y ago
You sound like someone that I'd like working with.
beyarkay 1y ago
(author here) bless you for helping out the juniors. There's not nearly a strong enough culture of educating juniors IMO
kunzhi 1y ago
I love developing junior people for all the reasons you outlined. It's both rewarding and fun. I know that I'm supposed to show up at work to deliver value or whatever, but that all pales in comparison to seeing a young person light up because suddenly they can see the path in front of them. And it's a lovely feeling to have instructed someone one day, then come in the following day or week and they've been on a tear with their new knowledge because they were so excited. One of my favorite feelings in life. Given that, it really boggles my mind the backward view most people seem to have of junior folks. There's a logic that says: "well, training somebody up is very expensive, and then once they have the skills, what's to stop them from leaving?" Like...really? You actually want someone to stay low-skill and produce shoddy results? Besides, if the only thing keeping the person around is their lack of skills, that says more about the place of work than the person. Can't say it makes any sense to me but I have accepted it at this point.
culopatin 1y ago
I wish I could work under you. We need more 9devs over junior devs and this industry will be a much happier place

deleted 1y ago

[deleted]

pixl97 1y ago

Taking mechanical stuff apart and fixing it is one of these areas. One of the more recent ones I watched is taking apart large wenches on a bulldozer. There is a metal plate with two bolts on it you have to take off. If you don't know what you're doing you take both bolts out and it flies apart losing stuff because there is a spring behind the mechanism. If you know what you're doing you take out one bolt then put in a bolt twice as long before taking out the second bolt, the long bolt catches the mechanism and releases the spring tension keeping all your parts in one place.

greazy 1y ago
Would that not be documented by the manufacturer somewhere?
- cenamus 1y ago
  Of course, but most people don't have the manuals if they're fixing half broken rusty old winches
  - chneu 1y ago
    I was under the impression we were working with large wenches, not winches.
    - jimnotgym 1y ago
      There is no manual for wenches, and all men are novices
- marcusb 1y ago
  Yes, but service technicians that are paid by the job often find ways to do a job in far less time using a different approach than the manufacturer suggests. An example: I used to own a Saturn S-series. The manufacturer estimate for replacing the alternator was something like 4 hours of labor, and involved removing the power steering pump (which was above the alternator.) It was possible to replace the alternator in about 30 minutes by removing the front passenger wheel and mud shield, and then accessing the alternator directly.

edelbitter 1y ago

> unguided “water-cooler” interaction This meme needs to stop. Knowledge transfer from experts to novices is way too important to be left to chance. And thanks to pre-pivot StackOverflow we even have considerable data on how much better it can be done, at least for white collar industries. Reducing the effort of experts to give advice, and enlarging the audience benefiting from a singular effort to write it down is orders of magnitude better than chance.

elcritch 1y ago
What? No, those free form unguided interactions are very useful for most novices. They're not a replacement for more structured knowledge teansfer, but an important compliment. Sure some novices are just natural talents that can pick up complex material from structured content alone. They're few though. > The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. Often there’s an underlying pattern that the novice can pick up through careful observation, even if neither the expert nor the novice can properly articulate this pattern. That explains part of it well. It's also an effect you can observe with graduate students of nobel prize winners tending to be "related" to professors who won nobel prizes or were part of their labs, etc. There's lessons imparted far beyond the structured material which is often available. Things like mindset, culture, and more are shared this way. Remote work is great, but it does limit these free form personal interactions which can be so invaluable. I'm a big fan of the potential for VR and AR to enable these experiences with remote work.
- elcritch 1y ago
  Chicken "sexing" is a fun example of how expert knowledge can be transferred without either expert or novice being able to explain it: https://www.youtube.com/watch?v=b7OgZdxRnog&t=174 https://www.youtube.com/watch?v=b7OgZdxRnog&t=174
  - nyanpasu64 1y ago
    I've read that birds used to have penises (and paleognaths and waterfowl still have them today), but the Galliformes (including chickens) developed atrophied penises which are difficult to see (hence chick sexing and feeding males to the meat grinder), and the Neoaves lost them entirely. Though https://prumlab.yale.edu/sites/default/files/brennan_etal_2008_independent.pdf https://prumlab.yale.edu/sites/default/files/brennan_etal_20... suggests the exact nature is more variable between birds in lineages that "have" them

coderintherye 1y ago

>Don’t study the “common” things, but go all-in on the niche pockets. The common things are common enough that you’ll learn them through osmosis regardless of what your main activity is. But the niche things require active study, and ignoring the niches is how you remain a novice. I'd add, work on the niche things that no one else wants to work on but need to be done. That's how I quickly advanced in my career, becoming knowledgeable about systems no one else wanted to touch.

eterm 1y ago
I very much agree to get to work tackling the things no-one else enjoys, especially if you find you enjoy it. I learned fairly early on that I enjoy debugging and fixing bugs far more than I enjoy greenfield development. This seems to be less common than yearning for fresh projects to work on, but it also makes me valuable to have on a team. Debugging is an absolute joy, it's like a two-layer puzzle. There's the immediate puzzle of "What's causing this errant behaviour", in which you mechanically dissect the code. You figure out the state the program needs to be in to trip the reported fault. This can be easy or difficult. There's also a secondary puzzle of, "What was the programmer# who wrote this thinking?". This is the enjoyable part. The root cause isn't "Here on line 53, we were multiplying Foo by Bar when we should have been Scrobbling Foo". The root cause is that someone thought that's what needed to happen ( and with PRs, someone else signed it off ). That secondary aspect is fascinating, because it can shine a light on misunderstandings about the product or the API. It'll also lead to reflection and introspection because occassionally you must stop to think, "What if they were right?". Every bug in a program is a learning opportunity. It's an opporunity to expand the understanding of the system, an opportunity to fix procedures or approaches to writing code so it doesn't slip through next time. One of the sad things about the march of AI, is that there's no longer any of that psychology or learning. The answer to, "Why was it written this way?" becomes, "Because the LLM said so". # That programmer might be your past self, but as they say, "the past is a foreign country", and it can sometimes be harder to put yourself in your past mindset than someone elses.
- flysand7 1y ago
  100%, debugging is an absolute joy, especially with niche systems-level kinda of bugs that simply can not be debugged with simple printf's. I had a friend once asking me to help debug a weird issue over discord. We went through some obvious things like are there any other threads running or is there something obviously wrong with the code. We didn't find anything so we went on to the best part -- trying to figure out the root cause from the panic. Checked the pointer values, wrote them down, checked where the TLS is, wrote that down to. At that point I forgot how Windows had TLS arranged, so I pulled up some docs, while the other guy fiddled around with the debugger. I found the TLS layout, and the debugger we used didn't have any kind of TLS debugging enabled, so we had to pull up PE spec to do some calculations on where the addresses could end up and sure enough the answer came -- we had a TLS corruption. Turns out he used a C bindings library that had a typo that overwrote the TLS and was messing with his variables. Debugging is such a joy when it feels like Sherlock Holmes movies. (*) For anyone who thinks might be misreading this, TLS means thread-local storage, not transport layer security. I'm sure I've had my share of wrong search results because of this too.

MichaelRo 1y ago

As a "senior" (expert) software developer you got a slight edge over a junior as long as you work in the same domain of expertise. As soon as you change project, you're at loss. General intelligence helps but can't make up for domain-specific expertise. Example: move from accounting software to map navigation software. Clueless. Move from map navigation software to financial software. Within financial software move from quantitative pricing to exchange interfacing. Clueless. Sure, you mostly get away with it but inevitably problems will arise that you have no idea what's causing them or even that they are a problem, so you spend days and weeks chasing what the expert figures out in minutes. That's why I prefer to keep the domain when changing jobs because it adds up to being just a software developer.

philipswood 1y ago
The edge is not slight. And usually in a new domain you're usually not completely clueless. There is value in growing a truly deep expertise by spending a lot of time in one domain, but a lot of the deeper skills do transfer (or partially transfer) and having mastered a few domains tend to give you deeper meta-skills.
harrall 1y ago
While that is true, you also end up learning foundational concepts which are frequently common between fields. You get a major head start when learning. For example, when learning electrical engineering, you might be forced to get good at vector calculus, and then when you move over to mapping software or physical chemistry, it turns out you use the same vector calculus. The application of vector calculus might vary but it sure takes way longer to learn vector calculus than to learn how to apply it differently. Vector calculus probably isn’t the best example but you get what I mean. I just find juniors learn new things so slowly. Hell, when I look back at my university days, it took me a long time to learn anything compared to now.
xlii 1y ago
I disagree, because in high specialty domains you even cannot reuse knowledge as it might be proprietary. On the other hand patterns are universal. You sit in a meeting where someone raises problem of „database slow, we have 50M of log entries, we need to delete them” and all the familiarity bells already ring. The open domain knowledge IMO is something that can be extracted from LLMs. Ask LLM for disk-based data cache and it will happily provide. But it won’t ask how many writers or readers you have. For me even imagining this scenario makes my spidey sense tingling.

kubb 1y ago

Ever been an expert who had to work on a codebase created by a novice? They invent the weirdest things. I know I used to do that too 10 years ago.

xlii 1y ago

I find the article interesting and well written. There might be some theory crafting but it resonates with my personal experience, especially this: > The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. I really like spending time with novices, especially if they are truly interested in the domain. It’s symbiotic because it also challenges my own opinions and judgements and the boost often is for everyone. It’s not surprising though that it is hard to explain rationale. How one can fit 2 years of pain in a sentence, a paragraph or even day long story? Direct interaction allows to shorten distance because it aligns on exact personal level. We find the efficient channels of communication based on prior experience, so it’s not building one filar from ground up to have a bridge, but instead use the almost-same-level and build upon it on both sides.

beyarkay 1y ago
(author here) Thanks! this was my first anything published to the internet, glad to see it's been received so well. > I really like spending time with novices From reading the various comments about this essay, it seems like there's a pretty sharp divide, some people love spending time with novices, others despise the activity.
- 12_throw_away 1y ago
  It depends on the novice IME. Some listen and try to follow my advice (good), some listen and ask probing questions (great), some ask such great questions that I end up learning from _them_ (amazing) ... and some nod politely then go back to copy-and-pasting from stackoverflow and chatgpt (makes me want to die).
pixl97 1y ago
>How one can fit 2 years of pain in a sentence, a paragraph or even day long story? I like to call it thinking in compressed binary objects. It's like a bunch of concepts I execute without actually thinking about because I do them so often.

nonrandomstring 1y ago

Essay touches on an important point that I also discovered along my research journey; Much of the knowledge of experts is ineffable [0]. And so here's the problem with present "AI". It contains no ineffable knowledge, because that knowledge is never symbolically expressed and cannot be inferred from what is expressed. In fact the "official" narrative often disguises the real knowledge. This is what the analytical elicitation stage of expert systems [1] was supposed to address (a now mature but presently unfashionable branch of "AI"). [0] https://en.wikipedia.org/wiki/Ineffability https://en.wikipedia.org/wiki/Ineffability [1] https://en.wikipedia.org/wiki/Expert_system https://en.wikipedia.org/wiki/Expert_system

teodorlu 1y ago

Any idea where to find the "Hard" and "Expert aesthetics" articles mentioned in the article? The links are giving me 404s. https://boydkane.com/hard https://boydkane.com/hard https://boydkane.com/expert_aesthetics https://boydkane.com/expert_aesthetics

beyarkay 1y ago
(author here) Apologies, I've (maybe mistakenly) put dead links for various essays that are works-in-progress, in order to figure out what to prioritize. I know it's annoying, but it does give me very good signal about what people want to read. For example, 2% of people clicked the essay `/hard`, but only 1% of people have clicked on the essay for `/expert_aesthetics`. So I'm frantically trying to finish `/hard` before a streamer reads the main essay tomorrow. If I can ask for constructive critique, how annoyed are you? The metrics are really useful to me, but I don't want to be an arsehole <3
- teodorlu 1y ago
  Not annoyed. But curious! I agree that mentoring is hard, and I want to read your take. I wonder if we agree on expert aesthetics or not. You write: > Experts tend to have an aesthetic preference towards technically challenging work rather than simple-but-interesting work, and I’ve written more about this phenomenon here: expert aesthetics. When I read the passage the first time, I thought you meant "experts prefer to work on hard problems in order to arrive at simple solutions". But that's not what you're saying!
  - beyarkay 1y ago
    > I agree that mentoring is hard, and I want to read your take. Thanks for the vote of confidence (: I'm kicking myself for not figuring out a mailing list before this essay went viral, but I'll cross-post the essay on my substack (https://beyarkay.substack.com/ https://beyarkay.substack.com/) when it comes out, so you can sign up there to get an email. > I wonder if we agree on expert aesthetics or not. You write: So I'm coining "expert aesthetics" as a relatively unused phrase that I can put my own connotations onto. There'll be more in the essay (; but at a high level, I've observed that, as someone becomes an expert in a field, their sense for what's "beautiful" in that field changes, and _generally_ it starts to focus on things that are technically challenging. That is, experts (IME) tend to find technically difficult things _aesthetically_ beautiful, even though novices might not care one bit about the technical skill required. Examples might help: Wine connoisseurs preferring wine from specific regions or made using specific techniques, while casual drinkers just want something that tastes good. Fashion designers preferring something that's different from last year and riffs off of the current styles, while the general public just want the same old same old. Painters taking delight in still lifes that perfectly capture the reflection of light through a wine glass, while most people just want a pretty sunset or portrait for their wall. This is all still in flux, but that's the gist of what I'm calling "expert aesthetics".

jonathanstrange 1y ago

It's weird that the author contrasts experts with novices. There should be layers upon layers of expertise in between those two options. What happened to the people who do solid work in their field with varying levels of experience without being necessarily experts? Are they irrelevant?

phkahler 1y ago
They are effective at solving mazes. They have enough tools to solve most of them, but not as efficiently as they could. They leave more broken branches and string around because they didn't understand an abstraction and tried to break it down in detail to cover every conceivable scenario.
beyarkay 1y ago
(author here) I agree, although I only realised this after the essay hit the internet. I think keeping things simple probably helped with the overall argument, but polarising things into "experts" and "novices" isn't a good abstraction to work with. I now think it's more accurate to think that someone is an expert relative to someone else, and only for a specific field. But that'll have to be another essay (:

hindsightRegret 1y ago

One counterpoint I have to this article. Considering expert vs. novice problem-solving: Within their domain, experts leverage highly efficient models. Outside? Rigidity often impedes adaptation. Their ingrained patterns, assets in familiar territory, become cognitive liabilities in the unfamiliar. The novice's counter-intuitive strength lies in a lack of assumptions, fostering the openness to explore without ego.

hindsightRegret 1y ago
If the expert has good T skill shape and beginner's mindset for new scenarios - this does not applly.
lawn 1y ago
I'd say this is an example of over-fitting, where the expert is too focused on their particular domain.
- skydhash 1y ago
  But sometimes, there's just not enough variance between the domains. Any NIH attitude is more likely to veer into complicated systems than finding the next best abstractions.
beyarkay 1y ago
(author here) I agree that novices have an advantage in that they have few assumptions: > Something you can do independently (and possibly it’s best done without expert supervision), is exploration of the field. You know nothing, and have no biases about what may or may not be useful. Any time you come across something that feels like it has some depth to it, such as a well-written essay series or a deep technical dive, you need to invest heavily into it. As a novice, your one advantage is that everything is new and nobody expects you to be fast. Because of this, you can afford to spend the time to learn as much as possible. I'm not sure that it's correct to characterise an expert by the lack of this though. I think it's correlated, but not all experts are so rigid.

ribcage 1y ago

[dead]

giorgioz 1y ago

This is why for young people is useful to pick a new field where there are no experts yet. I was very lucky to graduate Computer Science just when the iPhone/Android came out. I had two years experience in Android programming where literally no-one could have more than 2 years experience. If I had tried to make it work in C++/Java I would have find myself competing with people with 10 or 30 years of experience. Right now I would recommend young people to go deep into LLM. Do stuff that have never being done before and everyone is a novice!

tough 1y ago
I mean most of the papers already come from pretty young folks!
- giorgioz 1y ago
  Exacty! They chose to go into a new field rather than persuing archeology and restoration.
- giorgioz 1y ago
  A dear friend of mine from Greece decided to study archeology and did a Phd in LITERALLY Byzantine iconography of penises. Now at 37 he works as workman in a factory producing food. He seemed happy before and he seems happy now. There are many ways to read into this real life events. I'm still struggling to understand it. A part of me sees it as a cautionary tale of pursuing outdated fields. Another parts of me wonders if maybe my friend is happy and everything else doesn't matter. Another part of me wonders if too much unconditional happiness might lead you in dead end alleys. Another part of me wonders if that is false and believing that is preventing me to be happier. Life is chaos.

pards 1y ago

> sometimes you [novice] just need to be able to show them [expert] what you’re doing without any specific question in mind > the vast majority of learning comes from a novice watching how the expert plies their skills, and not from direct questions and answers This succinctly describes why pair programming can be valuable when used judiciously. I've seen large institutions hold long, boring "knowledge transfer" sessions where the expert explains the codebase to a group of novices but these are largely ineffective without practical experience. Pair programming for a few weeks during the transition period (novice drives, expert advises) can be a more effective method to bring a novice up to speed. It works in remote environments, too, but does require synchronous time.

beyarkay 1y ago
(author here) If you haven't watched the Factorio head developer's bug-fix videos on youtube, you really should. They're a goldmine of insight. Also the second video is a very strong case in favour of peer-programming. > novice drives, expert advises I've not heard this explicitly recommended, but it's so clearly the best way to do things if learning is the goal.

markus_zhang 1y ago

A quick track from juniors to experts is to convince someone to let you build something big from scratch. It is going to be messy and likely difficult to maintain. But you gain immense experience from that project, so much that you can be a semi expert (and an expert in that specific domain) in just a couple of years. That was how tons of young people who trampolined to senior in just a few years, bagging a lot of experience in the CVs.

lawn 1y ago
Especially if it's integrated with a large legacy app or codebase. You'll get so many valuable lessons.
- markus_zhang 1y ago
  Yeah. Alas such opportunites are pretty much luck based.

joenot443 1y ago

This is a really good article. There's a quality in strong developers which is difficult to select for in an interview but wildly valuable once they're up and running; maybe the best word is "scrappiness". When I interview juniors or interns, one of the questions I like to ask is something like this- "You've got two computer, one Linux one Windows. There's 50gb of files on the Windows machine which need to be moved to the Linux one, but you've only got 1h to do so. What's your strategy?" Anyone with some experience knows it's a bit of a silly question - there are a tonne of unknowns and countless "correct" answers, but that's just the rub - it's not about the academically optimal answer, but about coming up with an answer that would probably work, given the constraints I'd be arbitrarily throwing at them. It's about realizing that the vast majority of decisions we make in software engineering have costs and tradeoffs, and being able to discuss them with a colleague is 10x more valuable than graph traversal. More than anything, I try to select for people that I know spent a good chunk of their formative years behind the computer, just like many of us did. The maze-traversal skills you learn as a child installing Ubuntu on your parents' computer stay with you forever. Given the option, I'd take the self-taught-indie-dev-state-college-grad over the honor-roll-ivy-league-leetcoder any day.

qiine 1y ago
soOo how do you do it ? ;p
- joenot443 1y ago
  Well, the answer I love them to start with is asking if they're single-bay computers and if not, why they can't just turn off both machines and stick the HDDs in the same box :) It's also a great signal if they can follow this up by noting that the Windows drive is probably formatted in NTFS so the Linux instance will need drivers to support it. Otherwise, a wired network + SMB/Samba is a fine solution too, though much slower. Even if they just suggest using an external SSD I'd be relatively happy. More than anything, this kind of question is to see what happens when a junior's asked to do something they haven't done before. Any answer but "I don't know" is a good start.
  - 1y ago

gitremote 1y ago

> This explains the difficulty of training new employees when all your experts are working remotely, as remote work practically eliminates any sort of casual unguided “water-cooler” interaction. In software development remote work, the novice can learn from the expert by screen sharing how they're working on a problem, sometimes called a working session. The expert can point out more efficient ways of working, like installing a tool, or whether they are using the wrong approach altogether.

beyarkay 1y ago
(author here) I'm not sure I agree. I certainly think that screen sharing is better than nothing, but remote screen sharing is a strict subset of what you can do while in-person. Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus. I can't describe how many times I've been saved days of work because a senior casually asked what problem I was working on as we both waited in line for a coffee, and they were able to point me in the right direction. As described in the essay, the novice doesn't know when to ask for help. There are other, tangential, reasons to prefer remote work over in-person, but I don't think there's any reason why remote work would be better at educating novices.
- skydhash 1y ago
  In person interactions is better, but we have a good amount of open-source projects that do fine with remote interactions. The issue with remote interactions is with processes. Instead of having tooling to promote adhoc interactions, most teams will get into some kind of rigid structures because the tooling is imposed from high. I loathe having slack because it quickly becomes full of noise. There should be friction from having another department chiming in. Having announcements in #general and #random have a cognitive load. I like email, because you can have filters and deal with things when it's suitable to do so. Slack is no where close to that.
- xboxnolifes 1y ago
  > Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus. I haven't yet tried this, but I've wondered for a while if it could be a good thing to just be visibly in voice chat while working if you aren't in a deep focus mode. Make it easy for someone to jump on and have converdation. I've seen people do it and call it open office and it be at specific times, but I'm thinking even more casual than that.

beyarkay 1y ago

(author here) Okay I know this is how the internet works, but I posted my essay here a month ago (https://news.ycombinator.com/item?id=43664345 https://news.ycombinator.com/item?id=43664345) and it died a silent death. Excited to read the comments! But damn the internet is unintelligible sometimes.

lisper 1y ago
A new submission on HN typically has 20-30 minutes on the New page before it drops off the bottom. It is pretty much luck of the draw whether or not anyone notices it during that time window.
- ChrisMarshallNY 1y ago
  Also depends on what's happening, that day. I had an article spend several hours at #1, but it was "second-chanced," and also St. Patrick's Day, so I guess most of the downvoters and competition were off doin' the Pukin' O' th' Green.

deleted 1y ago

[deleted]

kunzhi 1y ago

Nice article, I really enjoyed reading it. I have to give an obligatory shout-out to the Dreyfus Model of learning which I find is often relevant. Keying off that, I caught myself while reading this section: > The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. Often there’s an underlying pattern that the novice can pick up through careful observation, even if neither the expert nor the novice can properly articulate this pattern. I'm 20 years into my programming career at this point and for a long time I really believed this was true and in a sense the "final" stage of mastery. However, I think there is a stage (possibly stages?) of mastery beyond the level of expertness where most answers come quickly through intuition. I think it boils down to "practitioner vs educator" -- some people are amazing practitioners and unquestionably expert at what they do. But, when you ask them to explain themselves, they run into that "I know it's right, but I don't know how" situation. I think the reason for this is that the person is not a great educator, which is a separate skill. Similarly, I've met many great educators who didn't perform well when asked to execute under real-world conditions. This has led me to believe that the combination of "great practitioner and great educator" is one of the rarest breeds out there. The few people I've met with this ability I would not call even 10x engineers but 100x or even 1000x.