Experts have it easy (2024)

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.

What is the "scrappy" way to do it?

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

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.

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.

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

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.

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

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.

Which may or may not be the full expertise.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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