> 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.

(author here) bless you for helping out the juniors. There's not nearly a strong enough culture of educating juniors IMO

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.

You sound like someone that I'd like working with.

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.

This is a fun question.

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.

Pick up the Windows machine and place it on top of the Linux machine. The files are now on the Linux machine.

(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.

You'd probably need to put the HD in the other machine.

What is the "scrappy" way to do it?

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.

Or set up SFTP on the Linux machine, and find whatever Windows crapware that's able to connect to it... Filezilla, maybe?

Windows has had OpenSSH's ssh/sftp/scp client binaries built in by default for ~7 years now. You can also do this in reverse by enabling OpenSSH Server on Windows (included feature but not installed or enabled on boot by default) and having the sftp client be the Linux box, which can be easier depending which you have more control of.

Or just... put in a usb thumb drive, move the 50gb on it and call it a day?

I was gonna say nginx, lol. It's smaller and more portable than python afaik

That is the scrappy way :)

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!

Also, engineers who only ever worked with non-user-servicable laptops.

soOo how do you do it ? ;p

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.

> the Windows drive is probably formatted in NTFS so the Linux instance will need drivers to support it

This hasn't been true for decades now, thankfully! Read-only NTFS support has been built into the kernel for a quarter century already (1997, 2.1.74, and a better one in 2002, 2.5.11) - and full read-write support for 4 years now (2021, 5.15).

These days also directly connecting two computers to each other with a network cable (not via a network, directly plugging each end of the same cable to each computer) will establish a connection (I’m pretty sure it also works with USB cables but the “automatic” might then only work between specific operating systems- it’s been a while since I tried).

IIRC last I tried direct Ethernet connecting between a Mac and a Windows pc the other computer appeared as a shared drive and I could simply copy files from it (I probably enabled some sharing option but it was easy to do either way).

>Otherwise, a wired network + SMB/Samba is a fine solution too, though much slower.

Robocopy with the MT flag speeds things up if it's lots of files.

im glad that my answer was an external drive, and is considered correct.

>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.

> 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 :-)

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?

Debugging can be a joy when dealing with a single system. Not so much when dealing with things like microservices where every combination has a possible failure scenario related to that bug. And because of the deployment strategy, you can't easily test that combination in isolation. Also no tests for each service, only full integration tests that takes a while to run.

I know distributed systems can be a pain to reason about, but I think every node should be capable of being tested in isolation, at least to be able to partition errors (either the node, or the distributed nature of the system)

> And because of the deployment strategy, you can't easily test that combination in isolation. Also no tests for each service, only full integration tests that takes a while to run.

That doesn't sound like microservices at all, but a distributed monolith.

I'm so sorry!

> Are all developers like this?

No, there are different types of developers. Some are like this (and so are some sysadmins) but others have strengths in different areas.

(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.

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.

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.

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.

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

Manufacturer like to say things like 'use the repressor tool #4325' which is no longer produced and costs a small fortune, rather than a $5 bolt.

(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).

(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.

> 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.

(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.

> after a technical meeting .. I could

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.

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)

(author here) Absolutely agree. Another commenter mentioned that sometimes the best mentor is someone slightly better than you, and not some seasoned veteran. You want someone knowledgeable enough to give good (and correct) advice, but not so knowledgeable that they struggle to be comprehensible.

Also, a novice is more ready to learn a lesson on the way back from a dead end than while barreling down towards it.

(author here) This is an interesting point. I hadn't considered it, but I agree. Or maybe to be more specific, I think the novice has some prior that their idea will work, and hearing an expert's disagreement will update their prior somewhat. If the novice has a high respect for the expert, that update will be large enough. But sometimes the novice just has to experience the pain firsthand in order to truly appreciate why something is a bad idea.

Advice while struggling is the key. I mentor a few friends, but if I'm giving directions, it is kept vague so that the task is still done by themselves. A proper review is only done after they tried or completed the tasks. This way, they already know the scope of the problem so the solution is way more understandable.

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".

You are forgetting the most important ingredient to what makes stack overflow what it is: the SEO that ensures closed threads always make it to the top of Google results.

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.

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.

(author here) it's a pity that there's no way to emulate an office's "just peer around your screen and ask your colleague" dynamic. Having your video camera always on is too creepy, and constantly being in a voice call with your peers still feels a bit weird.

Certainly more effective at short term GTD, but less so at sharing intangibles or lowering the barrier to more general or spontaneous communication.

(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.

I'm reading a book that's partly inspired by academia settings and one thing that jumped to me is the papers vs lab interactions in learning. All the things that you need to know is already in the papers, but the link between the concepts is rarely explained and that's what gives you the solution for a given problem.

The MDN is a very comprehensive documentation for all things about programming a web application. But for a given task, the subset of docs you want and the link between them is not on MDN, it's found in the experience you have in dealing with similar things. And that's what you can give junior, the recipe for all the ingredients they need for a solution.

Letting them try first is for them to get to know the ingredients and kinda the general steps. By the time you tell them the recipes, they can just focus on the precise steps and measurements.

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!

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.

Yeah. Alas such opportunites are pretty much luck based.

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.

(author here) I agree that novices have an advantage in that they have few assumptions:

> Something you can do independently (and possibly it’s best done without expert supervision), is exploration of the field. You know nothing, and have no biases about what may or may not be useful. Any time you come across something that feels like it has some depth to it, such as a well-written essay series or a deep technical dive, you need to invest heavily into it. As a novice, your one advantage is that everything is new and nobody expects you to be fast. Because of this, you can afford to spend the time to learn as much as possible.

I'm not sure that it's correct to characterise an expert by the lack of this though. I think it's correlated, but not all experts are so rigid.

I'd say this is an example of over-fitting, where the expert is too focused on their particular domain.

But sometimes, there's just not enough variance between the domains. Any NIH attitude is more likely to veer into complicated systems than finding the next best abstractions.

> 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.

(author here) If you haven't watched the Factorio head developer's bug-fix videos on youtube, you really should. They're a goldmine of insight. Also the second video is a very strong case in favour of peer-programming.

> novice drives, expert advises

I've not heard this explicitly recommended, but it's so clearly the best way to do things if learning is the goal.

> 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.

(author here) I'm not sure I agree. I certainly think that screen sharing is better than nothing, but remote screen sharing is a strict subset of what you can do while in-person. Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus.

I can't describe how many times I've been saved days of work because a senior casually asked what problem I was working on as we both waited in line for a coffee, and they were able to point me in the right direction. As described in the essay, the novice doesn't know when to ask for help.

There are other, tangential, reasons to prefer remote work over in-person, but I don't think there's any reason why remote work would be better at educating novices.

> Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus.

You've outed yourself as a young person here, because young people have this social fear of messaging senior engineers. Messaging at work doesn't need to be synchronous like in personal communication. Messaging at work matures into optional asynchronous communication for efficiency. See the No Hello (https://nohello.net) protocol.

There is actually a lower bar for quickly bugging a colleague over messaging than walking over to their desk. It's actually impolite to shoulder surf and skim your colleague's email inbox to determine if what they're doing is important. For senior and above levels, reading emails can be more urgent than having an IDE open. There can be production issues, environment issues, vendor tickets, and emails from senior management that are communicated over email. Or they can be submitting an HR form that has their personal details.

Before 2020, software developers in open office environments naturally gravitated to messaging over talking in person, because having no office or cubicle walls means if you're talking out loud at someone's desk, you're bothering others sitting nearby. Sometimes this happens anyway, and it can be hard for some people to read code or emails while listening to colleagues talking right next to them.

> There are other, tangential, reasons to prefer remote work over in-person, but I don't think there's any reason why remote work would be better at educating novices.

There is minor degradation in educating novices, like maybe it's 2% to 5% worse, but in open office work environments, the majority of communication is messaging and emails anyway due to lack of privacy and sound-proofing. Screensharing is easier to see than huddling at someone's desk, and quieter for your colleagues next to you who wouldn't hear all sides of the conversation when you're using headphones.

> Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus.

Odd. Even when working in office, I messaged colleagues, because it is less disruptive than walking up to their desk to interrupt them. They can manage when they are available to respond, asynchronously or synchronously. You need to follow the No Hello (https://nohello.net) protocol, though.

In person interactions is better, but we have a good amount of open-source projects that do fine with remote interactions. The issue with remote interactions is with processes. Instead of having tooling to promote adhoc interactions, most teams will get into some kind of rigid structures because the tooling is imposed from high.

I loathe having slack because it quickly becomes full of noise. There should be friction from having another department chiming in. Having announcements in #general and #random have a cognitive load. I like email, because you can have filters and deal with things when it's suitable to do so. Slack is no where close to that.

> Working remotely means there's some higher bar for quickly bugging a colleague, since you have no idea if they're casually reading their emails or if they're in deep focus.

I haven't yet tried this, but I've wondered for a while if it could be a good thing to just be visibly in voice chat while working if you aren't in a deep focus mode. Make it easy for someone to jump on and have converdation.

I've seen people do it and call it open office and it be at specific times, but I'm thinking even more casual than that.

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.

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

Not annoyed. But curious!

I agree that mentoring is hard, and I want to read your take.

I wonder if we agree on expert aesthetics or not. You write:

> Experts tend to have an aesthetic preference towards technically challenging work rather than simple-but-interesting work, and I’ve written more about this phenomenon here: expert aesthetics.

When I read the passage the first time, I thought you meant "experts prefer to work on hard problems in order to arrive at simple solutions". But that's not what you're saying!

> I agree that mentoring is hard, and I want to read your take.

Thanks for the vote of confidence (: I'm kicking myself for not figuring out a mailing list before this essay went viral, but I'll cross-post the essay on my substack (https://beyarkay.substack.com/) when it comes out, so you can sign up there to get an email.

> I wonder if we agree on expert aesthetics or not. You write:

So I'm coining "expert aesthetics" as a relatively unused phrase that I can put my own connotations onto. There'll be more in the essay (; but at a high level, I've observed that, as someone becomes an expert in a field, their sense for what's "beautiful" in that field changes, and _generally_ it starts to focus on things that are technically challenging. That is, experts (IME) tend to find technically difficult things _aesthetically_ beautiful, even though novices might not care one bit about the technical skill required.

Examples might help: Wine connoisseurs preferring wine from specific regions or made using specific techniques, while casual drinkers just want something that tastes good. Fashion designers preferring something that's different from last year and riffs off of the current styles, while the general public just want the same old same old. Painters taking delight in still lifes that perfectly capture the reflection of light through a wine glass, while most people just want a pretty sunset or portrait for their wall.

This is all still in flux, but that's the gist of what I'm calling "expert aesthetics".

> Work in progress (or 404)

I think it would be a lot politer if the target page was clearer. As it is, I could be 'voting' on a draft or it could just be plain broken and the intended page somewhere else.

Personally, I think it would make more sense to just put up what you have explicitly noted as drafts etc, and count the 'votes' that way.

Thanks for the feedback, I'm just using a static site generator so have limited flexibility, but I'll see what I can do to make it clear that something is a WIP vs a true 404.

PS: I love your writing, thank you so much for putting it out there (:

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

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.

(author here) I agree, although I only realised this after the essay hit the internet. I think keeping things simple probably helped with the overall argument, but polarising things into "experts" and "novices" isn't a good abstraction to work with.

I now think it's more accurate to think that someone is an expert relative to someone else, and only for a specific field. But that'll have to be another essay (:

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.

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.

I don't agree. Domain-specific expertise is valuable (even essential) but can be learned, and usually rather more easily than learning to become an expert software engineer.

I've worked in a number of almost completely disparate domains over my career, each one needed maybe a year or so to become reasonably knowledgeable on, but it's not the same as resetting back to a complete software novice each time.

Also, the people who have been deeply embedded into a domain for a long time tend to overestimate how much it takes. I've seen exactly this with your example of financial software; yes there is domain knowledge but the clear industry lesson has been that it's far easier for software engineers to learn that than for the domain experts to learn software engineering.

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.

Domains are often not very deep, as a lot of people need to understand them.

I've seen smart people quickly figure things out and propose upgrades in a matter of weeks, on points lifelong experts overlooked, or were too lazy to dig.

Reminds me of a company that was looking for people good in both the domain and software, to bridge the experts/devs gap (which is often a bottleneck, information flow between brains being slow and unreliable). They found out that it was much easier to teach the domain to devs, than to teach software to domain experts, i.e. that software was the hard skill.