> 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!
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.
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.
>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.
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.
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.
Also love debugging, it's puzzle, pattern matching, evidence gathering, poking around, experimenting, it's using tools, diving into documentation, learning more than whats required to write it and learning about humans and machines and why and how we make mistakes and forgiving these mistakes and fixing the errors. That feeling when spending lots of time to write just one line of code to close that one pesky bug.
Are all developers like this? Is there something I should look for when looking for a job that can help me get more of a career with more of this joy in it?
(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) and it died a silent death. Excited to read the comments! But damn the internet is unintelligible sometimes.
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.
> 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.
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.
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.
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.
If you only do structured knowledge transfer you get to transfer whatever the expert thinks they should pass on and at best also what the novice thinks they should learn.
It’s not either/or. No formal process or knowledge management system is so efficient that people won’t from time to time lack the context they need to make good decisions. Informal conversations made possible by seniors making themselves available and present makes up at least part of the shortfall. Moreover, informal conversations can benefit both parties. How many bad strategic decisions are made for want of on-the-ground context?
It’s a well-studied problem. See my recent book “Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation”. Or if you prefer original sources to modern takes, note that Stafford Beer followed up Brain of the Firm with Heart of Enterprise. Between the two books, the most significant change in his Viable System Model was to address this issue.
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.
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_20... suggests the exact nature is more variable between birds in lineages that "have" them
You don't need to wait for AR/VR. For computer work the real space of interaction is currently the screen. Unstructured pair programming for two remotes with a shared screen and audio and chat is a way more effective interaction than most things you could do together at the office.
Even better if both of you have two screens - so besides the shared space, you have a separate work area where you can Google things, ask the AI, spelunk the codebase for related relevant features or try one-liners.
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.
> 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.
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.
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!
(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
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?
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.
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").
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.
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.
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.
Disagree. A lot of experience comes from a long career of changing projects and domains. You keep on encountering the same issues and problems in different contexts. I've been doing that for thirty years or so. Getting productive in new projects quickly is a good skill to have. It requires being efficient and mastering new things.
This is also the number one skill you will learn by getting a good education. Education can come in many forms. Some people never go to university for this and are self taught. It's easier than ever to teach yourself whatever you want to learn. In the end it's not about the stuff you learn but about learning to learn stuff. And having learned a lot of stuff, makes learning a new thing relatively straightforward. It's more of the same.
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.
> 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!
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.
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.
>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.
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.
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.
Also love debugging, it's puzzle, pattern matching, evidence gathering, poking around, experimenting, it's using tools, diving into documentation, learning more than whats required to write it and learning about humans and machines and why and how we make mistakes and forgiving these mistakes and fixing the errors. That feeling when spending lots of time to write just one line of code to close that one pesky bug.
Are all developers like this? Is there something I should look for when looking for a job that can help me get more of a career with more of this joy in it?
> niche systems-level kinda of bugs that simply can not be debugged with simple printf's
Funny, printfs are the only thing that works for me for debugging niche systems-level bugs :-)
(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) and it died a silent death. Excited to read the comments! But damn the internet is unintelligible sometimes.
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.
> 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.
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.
I miss programming languages that fit this model. I remember learning how Dictionary/Map hashing by just putting
d := Dictionary new. d at: 13 put: 42. d at: 5 put: 7. d at: 13 put: 57.
in a workspace and hitting ‘debug it’.
Modern programming ecosystems make this type of learn by discovery/exploration so much harder.
Would that not be documented by the manufacturer somewhere?
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.
Of course, but most people don't have the manuals if they're fixing half broken rusty old winches
I was under the impression we were working with large wenches, not winches.
There is no manual for wenches, and all men are novices
> 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.
If you only do structured knowledge transfer you get to transfer whatever the expert thinks they should pass on and at best also what the novice thinks they should learn.
Which may or may not be the full expertise.
A good documenter is the novice who just learned. (Maybe the expert should vet it for accuracy)
Stack overflow is questions asked by novices. That’s the point
Stack overflow is "closed due to being a duplicate" and "closed due to not containing ready to copy paste code".
It’s not either/or. No formal process or knowledge management system is so efficient that people won’t from time to time lack the context they need to make good decisions. Informal conversations made possible by seniors making themselves available and present makes up at least part of the shortfall. Moreover, informal conversations can benefit both parties. How many bad strategic decisions are made for want of on-the-ground context?
It’s a well-studied problem. See my recent book “Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation”. Or if you prefer original sources to modern takes, note that Stafford Beer followed up Brain of the Firm with Heart of Enterprise. Between the two books, the most significant change in his Viable System Model was to address this issue.
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.
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
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_20... suggests the exact nature is more variable between birds in lineages that "have" them
You don't need to wait for AR/VR. For computer work the real space of interaction is currently the screen. Unstructured pair programming for two remotes with a shared screen and audio and chat is a way more effective interaction than most things you could do together at the office.
Even better if both of you have two screens - so besides the shared space, you have a separate work area where you can Google things, ask the AI, spelunk the codebase for related relevant features or try one-liners.
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.
If the expert has good T skill shape and beginner's mindset for new scenarios - this does not applly.
I'd say this is an example of over-fitting, where the expert is too focused on their particular domain.
> 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.
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.
Especially if it's integrated with a large legacy app or codebase. You'll get so many valuable lessons.
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!
I mean most of the papers already come from pretty young folks!
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/expert_aesthetics
(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
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.
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?
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.
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
[1] https://en.wikipedia.org/wiki/Expert_system
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.
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.
What's the problem with 50M log entries and deletion, and a disk-based cache?
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.
Disagree. A lot of experience comes from a long career of changing projects and domains. You keep on encountering the same issues and problems in different contexts. I've been doing that for thirty years or so. Getting productive in new projects quickly is a good skill to have. It requires being efficient and mastering new things.
This is also the number one skill you will learn by getting a good education. Education can come in many forms. Some people never go to university for this and are self taught. It's easier than ever to teach yourself whatever you want to learn. In the end it's not about the stuff you learn but about learning to learn stuff. And having learned a lot of stuff, makes learning a new thing relatively straightforward. It's more of the same.
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.
[dead]