Beginners helping experts

“In the beginner’s mind, there are many possibilities. In the expert’s mind, there are few.”

— Shunryo Suzuki

The trick being, how can an expert help a beginner, given they know all the false paths. And how can the expert encourage the beginner to help them find new ideas, knowing all the paths they’ve followed in the past?

The distinguishing quality of beginner-ness is that every rock turned over has something surprising or interesting under it. It’s all rabbit holes to fall down or rakes to step on.

When there are no time constraints present, it’s fine to explore these ideas, some of which may not be fruitful. Or, to figure out exactly why the result was surprising and not intended.

When time is of the essence, being a beginner is sometimes pretty dang stressful. Doubly so when the path to productivity is littered with novelty.

Ergo, Make Failure A (Safe) Option.

I feel lucky that I was able to learn a lot about software development in high school and college. Mostly, self-directed; I used Linux during college, spent a lot of time compiling Enlightenment and tinkering with up-and-coming languages you may have heard of, namely Python and Ruby (and to some extent, Lisp and ML).

Beginners today are thrown straight into narrowly guided tutorials and online courses. Then they’re dropped into the wilds of innumerable Unix minutiae, source control, relational databases, multi-paradigm programming languages, styling in browsers, and agile methods. I realized I was firmly in the “expert developer” camp when I could spot all the rabbit holes and rakes-in-leaves three moves ahead. I deftly maneuvered in the dark, knowing by feel where the potential problems were and how to avoid them.

It’s difficult to impart that knowledge to beginners. It’s not principles, it’s compounded experience. Worse, beginners find themselves amidst a hustle culture of “ship a side project alongside your day job and somehow do that whilst traveling the world”. Or, become a “content creator”. Most importantly, I knew a side-hustle and creator¹ lifestyle were not for me.

I’m certain beginners can help me find new and interesting angles. But it’s difficult to thread the needle between listening for insight and skipping ahead to what I know will work. It’s tempting to say, “I see where you’re going, but there are hazards ahead and here’s all the ways your approach could stymy us.” For one, failing is a pretty dang effective way to learn! For another, “don’t do that, I’ll tell you why later” is a pretty lousy way to acquire knowledge.

One lesson I’ve learned from beginners is that probably we should design systems without reliance on understanding the full depth and breadth of the computing world. Folks don’t have the time or energy to get Very Good at ./configure; make; make install² like I did in college.

Beginners are pretty good at working incrementally. They have to, lest they get lost in all the stepping on rakes and learning of minute! Many experienced developers have forgotten how to build incrementally. They glimpse the glass castles in the sky and plow ahead to realizing them, only to find themselves stepping on different kinds of rakes hidden in the leaves.

Expert mistake number one: try to skip past all the beginner’s insights. That is, the beginner’s mind.

Teammates new to software development and new teammates on the team, accidentally or intentionally, can both reveal useful information about your team, process, and software. Information that is otherwise difficult to come by. There are things everyone is accustomed, and thus blind, to that a beginner can tell you straight away.

I have to remind myself that this is a critical moment. Don’t skip straight to “onboarding them onto the team’s culture” by explaining the history and the why-or-why-not. I should listen to the insight, evaluate the idea, and bias to act on it if I can.

A group of experts can make great things. But a group of experts with a beginner alongside can assimilate new ideas and make great and interesting things.