> 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.
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.
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.
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.
But the fact that "move a medium sized file from one machine to another" is still a fun question is also a pretty damning indictment of our industry :P
I would say that the fact that this question is more relevant to actual job performance than ~90% of leet code questions that I have been asked would be an even stronger indictment of the industry.
Gigabit Ethernet is 26 years old and the average home/company network is still at the same level... some new PC motherboards have 2.5G but more often than not switches/routers are still on 1GbE.
Crazy how much CPU/GPU performance and storage speed have improved while other things haven't changed at all in decades.
I have been nerd-sniped into conjuring up a less-traveled-path technique:
Portable Python on the Windows computer. `python -m http.server`. On the Linux computer, something like `wget -mkp` followed by `find … -delete` to get rid of the index files.
(Lots of disks are soldered in nowadays, or the procedure might require multiple M2 slots that the destination mobo might not have. Is your company IT department happy to know their hardware is being disassembled?)
I have not benchmarked to see if this would sustain the 120 Mbps the original scenario would require.
I think sometimes we forget there are plenty of engineers out there whose experience interfacing with a computer begins and ends at the KBM. "Put the HD in the other machine" isn't super obvious to every junior, though I wish it was!
(author here) Thanks! I appreciate your kind words. That scrapiness you talk of is interesting, totally agree that there's something there, and it's interesting to think of how to evaluate if someone has it without spending months working with them.
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.
>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.
This is also what I love about rebuilding some existing architecture that's not working for a business, its doing mostly the second part - the system is working but it - costs too much, is too slow, doesn't realize some goal, etc - and often times a big part of that problem is because the original intent of the author was not expressed properly.
Usually its not enough time and skills to solve the particular problem, but the most satisfying thing is building a new system that expresses the intent of the original author but at 2% of its original resource usage.
(author here) I've always found this advice a bit of a double edged sword. I absolutely agree that it'll develop your career, but I don't really want my day job to become 100% drudgery because I'm the only one who bothers to do it properly.
If the untouched system is just fiendishly complex this can be fun to figure out, but if the untouched system is pure pain to deal with, I think I'd rather risk unemployment.
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.
A lot of ecosystem eschew the debugger from their workflow. The best experience is with Common Lisp (slime) and Smalltalk, where you can inspect the variable from any snippet of code. It's quite nice too in IDEA (java) where you can put a breakpoint and investigate a suspicious behavior of a method.
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.
(author here) Ooooohhh this is a great example, I love it. Software can be so abstract with the footguns sometimes, but physical mechanisms are so much more intuitive
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.
>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.
(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.
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).
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.
(author here) I absolutely agree that knowledge transfer shouldn't be left to chance, and that there should be more consistent processes in place to make sure this happens. But I still think there's something to be gained from experts and novices having a more casual conversation about various topics.
When I was getting started in software, some of the most valuable conversations I had were after a technical meeting, when I could pick a seniors brain on the way out of the room, asking them why XYZ solution was dismissed immediately.
Encouraging frequent and casual conversation between experts & novices is key.
To be fair, almost any form of one-on-one exchange looks really effective when you contrast it with the average badly-moderated, way-too-many-peoples-time-wasted-if-you-ask-questions, no-prepared-agenda, in-person meeting.
One contrast I find more impressive is the valuable advice I received from people.. already dead for years. Skipping possibly helping 2 or 3 additional novices, by instead spending that time on refining a quick reply to one person into a reusable misconception-untangling guide. Useful to 100 more, for years to come.
IMNSHO, if a company is not even encouraging such soft-skills via the easy pickings (like turning their buzzword-infested PR slopstream back into a proper technical weblog), they are not missing a key - they got too many locks confining available expert knowledge.
Not really. It's the same reason formal lectures are so much less valuable than one-on-one mentoring. An expert's value doesn't come from a bundle of facts, but from being able to figure out which facts you need to hear right this second given your current background, and figuring out how to present them so that you in particular can apply them. Having a motivating problem to discuss also helps both parties appropriately engage.
You can reduce the chance element a bit by having dedicated pairing time or something, and writing things down is better than nothing, but if you want to level up your juniors as fast as possible you'll definitely want some of that water cooler time.
(author here) I think there's something to be said for having both (if I allow myself to imagine an unrealistic utopia).
Imagining the distribution of how much benefit novices get out of a scenario, only having the watercooler interactions probably has a high maximum benefit (i.e. there's some expert that loves teaching and puts loads of time into helping novices) but probably also a very low minimum benefit (i.e. there are no experts at the company, or the experts couldn't care less about helping out). So it's the risky scenario, with a high variance.
Only having formal teaching doesn't have nearly as low a minimum (even a lecturer doing the bare minimum is better than no lecturer), but also doesn't have nearly as high a maximum (a high-effort lecturer simply cannot pay attention to each of the 300 students in a lecture hall, no matter how hard they try).
So having the formal teaching raises the minimum, ensuring the worst outcomes are not that bad, and adding in some watercooler interactions raises the maximum, ensuring that high-effort experts are able to converse with interested novices.
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.
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.
(author here) I love the graduate student + nobel laureate reference, I had read that study but totally forgot how relevant it is to the essay. Absolutely it hammers home the point that there's something about just spending casual time with experts in a field that's invaluable to novices, regardless of the skill/talent of the novice.
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.
(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.
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.
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.
Readit News
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!
Hearing what other people have to say and thinking about your actions in different light is skill on its own.
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.
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.
But the fact that "move a medium sized file from one machine to another" is still a fun question is also a pretty damning indictment of our industry :P
Crazy how much CPU/GPU performance and storage speed have improved while other things haven't changed at all in decades.
What is the "scrappy" way to do it?
Portable Python on the Windows computer. `python -m http.server`. On the Linux computer, something like `wget -mkp` followed by `find … -delete` to get rid of the index files.
(Lots of disks are soldered in nowadays, or the procedure might require multiple M2 slots that the destination mobo might not have. Is your company IT department happy to know their hardware is being disassembled?)
I have not benchmarked to see if this would sustain the 120 Mbps the original scenario would require.
I think sometimes we forget there are plenty of engineers out there whose experience interfacing with a computer begins and ends at the KBM. "Put the HD in the other machine" isn't super obvious to every junior, though I wish it was!
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.
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.
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.
Usually its not enough time and skills to solve the particular problem, but the most satisfying thing is building a new system that expresses the intent of the original author but at 2% of its original resource usage.
If the untouched system is just fiendishly complex this can be fun to figure out, but if the untouched system is pure pain to deal with, I think I'd rather risk unemployment.
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.
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.
> 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 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.
> 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.
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.
When I was getting started in software, some of the most valuable conversations I had were after a technical meeting, when I could pick a seniors brain on the way out of the room, asking them why XYZ solution was dismissed immediately.
Encouraging frequent and casual conversation between experts & novices is key.
To be fair, almost any form of one-on-one exchange looks really effective when you contrast it with the average badly-moderated, way-too-many-peoples-time-wasted-if-you-ask-questions, no-prepared-agenda, in-person meeting.
One contrast I find more impressive is the valuable advice I received from people.. already dead for years. Skipping possibly helping 2 or 3 additional novices, by instead spending that time on refining a quick reply to one person into a reusable misconception-untangling guide. Useful to 100 more, for years to come.
IMNSHO, if a company is not even encouraging such soft-skills via the easy pickings (like turning their buzzword-infested PR slopstream back into a proper technical weblog), they are not missing a key - they got too many locks confining available expert knowledge.
You can reduce the chance element a bit by having dedicated pairing time or something, and writing things down is better than nothing, but if you want to level up your juniors as fast as possible you'll definitely want some of that water cooler time.
Imagining the distribution of how much benefit novices get out of a scenario, only having the watercooler interactions probably has a high maximum benefit (i.e. there's some expert that loves teaching and puts loads of time into helping novices) but probably also a very low minimum benefit (i.e. there are no experts at the company, or the experts couldn't care less about helping out). So it's the risky scenario, with a high variance.
Only having formal teaching doesn't have nearly as low a minimum (even a lecturer doing the bare minimum is better than no lecturer), but also doesn't have nearly as high a maximum (a high-effort lecturer simply cannot pay attention to each of the 300 students in a lecture hall, no matter how hard they try).
So having the formal teaching raises the minimum, ensuring the worst outcomes are not that bad, and adding in some watercooler interactions raises the maximum, ensuring that high-effort experts are able to converse with interested novices.
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.
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.