On Teaching, Learning, and Being Honest With Ourselves

Preamble: I’m not an expert teacher or mentor. I practice all the time to get better. Much of what you are about to read comes from personal failings in this arena, as recently as a week ago. This is an open letter to all who would teach.

I’ve been seeing this sentiment going around in various forms, and it’s troubling me. Somehow we’ve gotten it in our heads that it’s not okay to accept the fact that people are not all at the same level of knowledge and ability. Somewhere along the way it became taboo to talk about people being elite, and people being beginners, and that it was imperative to teach and mentor and task people in a manner appropriate to their level. Somewhere along the way it became not only acceptable but encouraged for anyone to go forth, call himself an expert, and attempt to teach a crowd.

Let me disabuse you of some notions you may have gathered from blogs and mailing lists: people *are* at different levels. There are people that are smarter than you, and me, and everyone else. There are people that are more adept with a particular technical skill. There are beginners. There *is* such a thing as a junior developer, and he does a different job than a senior developer. All of these statements reflect the natural order of things. We are not all the same. That’s a good thing, and if you think it’s not, you are naïve.

Treating and tasking a junior developer the same as a senior is detrimental to productivity and detrimental to the growth of that developer. A novice is a novice no matter how you choose to describe it, and what a novice can do is vastly different than what an expert can do.

Teaching and the Dreyfus Model

If you are unfamiliar with the Dreyfus Model of Skills Acquisition, take a second to go read up on it real quick and then come back.

Ok, now we have a model (and programmers love models) for what each stage of learning looks like. Keep in mind the Dreyfus Model applies atomically to a given skill. You can be an expert in C# and a novice in Ruby. This resonates with everyone right? Ok so stop trying to put everyone in the proficient stage of every skill. It’s not reality. We all fall into different buckets of the Dreyfus Model for every single skill that we practice and we only advance from one to the next linearly. You can’t make a beginner skip steps by pairing him with an expert, and you certainly can’t make him skip steps by forcing expert-level work on him. Beginners need rules and boundaries. They need clearly defined tasks and clear context (in such case as they even care about context, which they typically don’t). Think of Iron Chef vs the line cook at your local chain eatery. The latter needs explicit recipes to make standardized food. The former needs only a table full of random ingredients to create something amazing.

This leads into three discussions: first – not everything can be taught to “beginners” and targeting the “beginner” is a farce. Second – when you attempt to teach, you must properly identify your target audience on the Dreyfus Model and set expectations accordingly. Finally – not everyone is cut out to teach.

Let’s deal with the last one first because it’s the one that will make the most people stop reading, so I want to save you some time. The old saying “those who can, do. Those who can’t, teach” is ingrained with a kernel of truth (no offense to teachers, for whom I have the utmost respect). Remember that the Dreyfus Model is atomic per skill. Teaching a given skill is a skill. If you rank as proficient or better with say, C#, you can talk about it with authority sure, but you do not automatically gain the skill of being able to teach your fellow man. Teaching is not telling. Teaching is a vast array of skills related to communications, psychology, sociology, and technical proficiency with the subject matter. Some would say that at certain levels you can teach a subject without “expert” skill in said subject, as long as you have high skill levels in the other aspects of teaching. I can buy into that, because it’s a bleak world indeed where only experts in a subject can teach it.

Bottom lining it for you – not everyone is cut out to teach. Sorry. If you have a strong desire to be a teacher then don’t worry, because you can practice and gain the skills required (I believe Malcolm Gladwell talks a lot about gaining expertise through practice rather than innate ability in his new book Outliers, which I have not yet read but it is in my near future based on friends’ recommendations). But if you go about teaching with the outlook that simply being proficient in a subject makes you qualified to be a teacher, then you are doing a disservice to those you wish to teach. (And replace “teach” with “mentor” or any other such verb at your leisure, dear reader)

Secondly – Define your audience appropriately and set the appropriate expectations. If you wish to teach something to “beginners”, first define “beginner” in what skill. Most tech books do a pretty decent job of this, particularly the O’Reilly Head-First Series, which explicitly lists in the beginning of each book what you will and won’t get from this if you are at a given level. This is called managing expectations, and it’s important both for the teacher and the student. I recently did a full day workshop on TDD aimed at “beginners” and learned this lesson the hard way. Beginner casts a very wide net when both parties’ expectations aren’t managed appropriately, and you spend much of your time either derailing the subject with questions you assumed were already known, or alienating people because you aren’t answering questions that they came to the table with. We came to the table with a set of stories around website registration, just registration, what we thought was a very small problem domain. In the course of the day we implemented the code for 1 story. The rest of the time was spent explaining concepts that we wrongly assumed were in play, like SOLID principles (among other things). And the vastly different levels of each of the 80 or so attendees meant that we felt the need to get to the lowest common denominator with everything. This means that the smallest subset of the audience was served well, and the rest, while they probably got some value from the event, left having not had their expectations met.

Thirdly – “Beginner” may not be a good audience for some concepts that you intend to teach. Again, look to the Dreyfus Model and ask yourself: “Am I able to sum this up into essentially recipes and step-by-step instructions with defined rules?” If the answer is “no”, then “beginner” is not your audience, and you will leave them confused. Looking back to some of the feedback we got from the TDD Firestarter event, this was the case for a lot of people. Presenting TDD/BDD with a lot of “it depends on context” type guidance is not appropriate for beginners. We did those people a disservice and probably confused them to the point where they aren’t going to be testing as a rule any time soon. This is obviously counterproductive in terms of the goal of the event. We even had reports of people being disappointed that our samples were in nUnit rather than MSTest because it didn’t occur to us that an actual beginner may not be able to convert one type of sample to another just based on attribute names. These are the kinds of things that you run into when targeting “beginners” for teaching, and you need to be both aware of them and willing to overcome them if you intend to teach to this group.

Accepting Some Realities

If I had one point to drive home to aspiring teachers of technology it’s: “don’t mismanage your own expectations”. You must understand your audience and the level at which you really intend to teach in order to be successful. And you must understand whether or not you have the requisite skill level to teach that subject matter at that level. I don’t mean at all to discourage budding mentors and teachers, I just want to give you the straight story so that you can more effectively put yourself in that role and not come away disappointed and not leave your students bewildered.

On to the labeling issue. Some people are beginners. Some are experts. It’s okay to call them that. Because it’s honest. I heard recently in a mailing list discussion that some people may take umbrage to being labeled as a beginner. That’s unfortunate but true. However, my experience has been that those people haven’t set their expectations and egos to the level appropriate for being a student. In other words, some people don’t want to be taught, so don’t bother until they are ready, and you will save yourself a lot of stress.

Finally, teaching is a huge burden to bear, and you need to understand this before you take on the responsibility. I know the draw of doing a codecamp talk every other month is a big one, maybe you’ll get some micro-celebrity, maybe you’ll get an MVP award, but you can’t be a hit-and-run guy and be a teacher. I’m not saying don’t do codecamps, because you should, but I’m saying accept the responsibility of the role and tailor your message to the format and the audience. Don’t go to a 1 hour codecamp talk with the intention of teaching TDD+SOLID+IOC+MVC+whatever else. It’s not reality and you won’t be giving your audience anything they can build on. Anyone that can glean a ton of value from a talk that big and that short can get that same value from a blog post. Don’t try to be a hero, don’t try to be sexy, just be honest, teach within your capabilities, and manage expectations appropriately on both sides. Teaching is a rewarding practice, but it takes effort, and you should strive to improve in the teaching skill as relentlessly as you strive to improve your technical skills if you truly want to be a teacher.

One final thought – I know *truly* beginner-level 101 courses and talks aren’t sexy and won’t get you the notoriety, but there is a need for them. Do them. All boats rise with the tide but the water level is lower than we think sometimes. Let’s work together to bring up the baseline.

About Scott Reynolds

Scott C. Reynolds is a developer with over a decade of experience creating enterprise solutions, primarily in healthcare and biotechnology. He is passionate about the art and craft of applying software solutions to business problems. He is a frequent speaker and participant of community events nationwide.
This entry was posted in community, mentoring, teaching. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to On Teaching, Learning, and Being Honest With Ourselves

  1. Cruz says:

    Very refreshing point of view. And I second your sentiment that there is a need for beginner-level instruction.

    Along the lines of beginner vs expert vs other label:

    I know of a very skilled classical pianist who decided to learn trumpet once. He had all the advanced knowledge of music theory, performance art, discipline., etc. But, he was truly a beginner when it came to learning the mechanics of making music with a trumpet. He even had to learn how to tune an instrument for the first time.

    In this case the expert became a beginner and it humbled him. He admits it was tough for a while. But, he says it made him a better person because it reminded him of what others feel like when they come to that huge piano keyboard for the first time.

    I think software professionals would do well to remember we all have strengths and weaknesses, things we know well and things we could use some assistance with. If we remember this, and internalize that reality, we might have more patience with those who don’t have the level of mastery, talent or skill we have in a particular subject. We might also remember that very person who doesn’t know much about SOLID might know a whole bunch about something else that we could learn from. And if we have a mentor’s heart, a teachable spirit and practice genuine humility, our lives and our profession will be that much richer for it.

    IMHO. :D

  2. Brad mead says:

    > Some people are beginners. Some are experts.

    I would like to see the Alt.Net community explore the other spaces of this continuum as many contexts provide neither extreme; even with consideration of Dreyfus and the skill under “learn”. What precepts will best govern skill refinement in a group of non-beginners and non-experts? On a day-to-day basis I imagine there is a swell of these contexts where advancing the state-of-the-art is short-circuited because a non-expert is unable to gain traction for pursuit of a skill; easily dismissed as a non-authority. You don’t necessarily need to be an expert to understand the value of a principle or tool.

    Objective (authoritative) sources of information seem a start. Like Scott B’s, Chad M’s, Rod P’s recent posts on TDD/Repeatability/SOLID and Hanselminutes w/Uncle Bob (SOLID) & Hanselminutes Scott Bellware. Those are excellent IMHO for making the case, that regardless of immediate expert availability, incremental and judicious pursuit of a skill has a high probability of enhancing design, maintenance prospects and quality.

    We may not be TDD experts but a collection of TDD noobs, TDD mediums and so on; but our organization might still cry out for an infusion of professionalism and TDD can be a vehicle upon with that professionalism is borne. However, without an expert (and assuming no immediate avenue to one), should we just give up on TDD/SOLID/REPEATABILITY/UBIQUITY/TRANSPARENCY? Or is there a path where objections to skill acquisition/method introduction can be navigated with humility, cooperation and a conscious/relentless attention to reason and exploration; as opposed to ego.

    Perhaps what I have rambled on about is not much teaching but championing.

  3. smaclell says:

    Thank you for sharing, I too really enjoyed this post. It really helped to drill home what worked and did not work with my last “mentoring” opportunity. Thank you for sharing.

    - Scott

  4. @Brad

    I’m not sure exactly where you are going there, but I’ll attempt to break it down as best I can.

    Yes, there are points between beginner and expert, that’s both implied here and noted in the Dreyfus model. Different techniques are used to teach a person at each level, and different degrees of skill can be acquired at that level.

    One does not, in fact, need an immediate expert around to pursue learning. I think I made that abundantly clear, but if not, I’ll restate it here.

    As to “authoritative” sources, yes, that’s an excellent place from which to pursue further learning, providing the authoritative source is an actual authority versus a perceived one (see guidance via Oxite).

  5. Brad Mead says:

    @ Scott
    >I’m not sure exactly where you are going there

    Yes I’m only beginning to understand myself :-)

    I think I have confused teaching with justifying.

    Trying to encourage others to engage a newly minted (at a personal level) idea of professionalism (TDD/SOLID) is easy when the desire is there. Expectations align; disparities in Dreyfus position are more easily acknowledged and less intimidating.

    When there is no desire then your “…some people don’t want to be taught, so don’t bother until they are ready”. This is what I have been grappling with. The dissonance produced when I am unable to convince someone of the value of TDD (Testing in general) leaves me searching for a silver bullet of justification. But then I must admit some people don’t want to be taught the value of TDD.

    Most of what you outline above applies and my answer lies in identifying the right thing to teach (i.e The VALUE of SOLID/Repeatability/TDD not the disciplines themselves); and only for those open to the suggestion.

    What remains is maintaining sanity on collaborative efforts with those who are ambivalent or hostile to practices I value greatly and mitigating the friction such a disparity often produces.

  6. @Brad ok I get you

    Some people don’t want to learn new things, at least not right now. Save yourself the stress and don’t try to force the issue. I should do a followup on this. There are ways to break down that barrier if you are determined, but you have to take the right tack and you have to be prepared to be turned away. It happens. You can’t save everyone.

    You are right about working the value angle. Nobody is going to care about SOLID (for example) for the sake of SOLID. There has to be a reason.

  7. DoniG says:

    Self-identifying your level is always difficult. For any given area of study, 50% of us will be below average, but 95% of individuals will say they are above average.

  8. Very nice post Scott! Teaching IS difficult. You have to know a lot about didactics and methodology to be a good teacher.
    As long as you are not a teacher at an ordinary school, you always have students with very different background and level of proficiency. You just can’t avoid this. Even if you publish your expectations beforehand.