> 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 · 15m 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.
xlii · 33m 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.
coderintherye · 4h 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 · 23m 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.
pixl97 · 5h 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.
travisgriggs · 1h ago
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.
greazy · 4h ago
Would that not be documented by the manufacturer somewhere?
cenamus · 1h ago
Of course, but most people don't have the manuals if they're fixing half broken rusty old winches
chneu · 59m ago
I was under the impression we were working with large wenches, not winches.
jimnotgym · 38m ago
There is no manual for wenches, and all men are novices
edelbitter · 5h 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.
nottorp · 1h ago
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.
asplake · 1h ago
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.
elcritch · 3h 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 · 3h ago
Chicken "sexing" is a fun example of how expert knowledge can be transferred without either expert or novice being able to explain it:
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.
kubb · 1h 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.
MichaelRo · 3h 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.
xlii · 1h 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.
harrall · 2h 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.
philipswood · 3h 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.
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!
> 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.
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 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.
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.
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.
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.
Which may or may not be the full expertise.
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.
> 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.
https://www.youtube.com/watch?v=b7OgZdxRnog&t=174
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.
They invent the weirdest things. I know I used to do that too 10 years ago.
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.
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.
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.