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

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?

soOo how do you do it ? ;p

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.

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

I miss programming languages that fit this model. I remember learning how Dictionary/Map hashing by just putting

d := Dictionary new. d at: 13 put: 42. d at: 5 put: 7. d at: 13 put: 57.

in a workspace and hitting ‘debug it’.

Modern programming ecosystems make this type of learn by discovery/exploration so much harder.

Would that not be documented by the manufacturer somewhere?

(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

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

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.

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

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.

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.

It’s not either/or. No formal process or knowledge management system is so efficient that people won’t from time to time lack the context they need to make good decisions. Informal conversations made possible by seniors making themselves available and present makes up at least part of the shortfall. Moreover, informal conversations can benefit both parties. How many bad strategic decisions are made for want of on-the-ground context?

It’s a well-studied problem. See my recent book “Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation”. Or if you prefer original sources to modern takes, note that Stafford Beer followed up Brain of the Firm with Heart of Enterprise. Between the two books, the most significant change in his Viable System Model was to address this issue.

What? No, those free form unguided interactions are very useful for most novices. They're not a replacement for more structured knowledge teansfer, but an important compliment. Sure some novices are just natural talents that can pick up complex material from structured content alone. They're few though.

> The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts. Often there’s an underlying pattern that the novice can pick up through careful observation, even if neither the expert nor the novice can properly articulate this pattern.

That explains part of it well. It's also an effect you can observe with graduate students of nobel prize winners tending to be "related" to professors who won nobel prizes or were part of their labs, etc. There's lessons imparted far beyond the structured material which is often available.

Things like mindset, culture, and more are shared this way.

Remote work is great, but it does limit these free form personal interactions which can be so invaluable. I'm a big fan of the potential for VR and AR to enable these experiences with remote work.

I mean most of the papers already come from pretty young folks!

Especially if it's integrated with a large legacy app or codebase. You'll get so many valuable lessons.

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.

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

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

(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

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

I disagree, because in high specialty domains you even cannot reuse knowledge as it might be proprietary.

On the other hand patterns are universal. You sit in a meeting where someone raises problem of „database slow, we have 50M of log entries, we need to delete them” and all the familiarity bells already ring.

The open domain knowledge IMO is something that can be extracted from LLMs. Ask LLM for disk-based data cache and it will happily provide. But it won’t ask how many writers or readers you have. For me even imagining this scenario makes my spidey sense tingling.

While that is true, you also end up learning foundational concepts which are frequently common between fields. You get a major head start when learning.

For example, when learning electrical engineering, you might be forced to get good at vector calculus, and then when you move over to mapping software or physical chemistry, it turns out you use the same vector calculus.

The application of vector calculus might vary but it sure takes way longer to learn vector calculus than to learn how to apply it differently.

Vector calculus probably isn’t the best example but you get what I mean. I just find juniors learn new things so slowly. Hell, when I look back at my university days, it took me a long time to learn anything compared to now.

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.