21–30 of 130 posts
> 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.
>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, becom…
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.
> 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 de…
This is what the analytical elicitation stage of expert systems [1] was supposed to address (a now mature but presently unfashionable branch of "AI").
> 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 o…
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.
The links are giving me 404s.
https://boydkane.com/hard https://boydkane.com/expert_aesthetics
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 f…
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.
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?