Posts Tagged ‘learning’

Dreyfus model of skill acquisition

I just finished reading Pragmatic Thinking and Learning, by Andy Hunt, as part of my 2018 Tech Reading Challenge. (It fits in the category, “a book about an abstract concept.”) In lieu of a full review, I’m sharing some key takeaways from chapter 2, “Journey from Novice to Expert.”

The Dreyfus model of skill acquisition is a tool to help you understand  how you are doing in a new skill. It can apply to any skill area, such as cooking, writing, bowling, or software development. It comes from a paper by the Dreyfus brothers, published in 1980. In it, they identify five stages of skill development. I’ll stick these at the bottom of the article (It’s a bunch of bulleted lists) and talk about some of my takeaways.

Problems

The Dreyfus model helps us understand a few different common problems in the world of professional software development.

First is a tendency to over-rate our own abilities. This can happen when we don’t know what we don’t know. This is known as the Dunning-Kruger effect.

Second is when we decide to stop learning, and yet think that expert status has been achieved. This has been described as the expert beginner, and Erik Dietrich has a set of articles about it over at his blog.

The Dreyfus model does not address how large or small a skill is scoped, but it seems you can break this up into small pieces. For example, the skill of unit testing is separate from the skill of refactoring, or from designing for test. In The Art of Unit Testing, Roy Osherove lists these as separate skills.

No one size fits all

My big takeaway from the 5 stages is that it can help explain why I am uncomfortable in different problem solving situations. For example, if I’m being asked to fit into a strict set of rules, and yet solve a problem that is very familiar to me, I can chafe a little. The rules are more suited to a novice, and I’m feeling more confident. On the flip side, if I have junior developers on the team, it is a good thing to have conventions, standards, and some guidelines for them to follow. And if I’m pursuing a senior engineer role, it’s my job to create the guidelines.

Movements target certain skill levels

The different stages help us identify how movements can target different skill levels with different attributes. For example, Agile could be viewed as a set of rules, rituals, and ceremonies, which would appeal to the advanced beginner, or it could be viewed as a way to learn and correct past performance, which is something a proficient stage person can do.

A great example of this is applying design patterns. An advanced beginner sees the potential for patterns everywhere! And the end up with something like EnterpriseFizzBuzz.

Conclusion: Check out the book

I recommend picking up a copy of Pragmatic Thinking and Learning, by Andy Hunt. I didn’t even cover all of chapter 2—there’s a great case study on how the model was applied to the nursing profession, and the author ties this to software development. The rest of the book has some great tips for learning and problem solving. I highly recommend it.

The five stages

Novice

  • they need a recipe
  • don’t know what they don’t know
  • prefer walkthroughs, in person if possible

Advanced beginner

  • start to break away from the fixed rule set
  • learn new tasks as the need arises
  • can use advice in a similar context
  • want information fast, but not the big picture
  • no broad-based conceptual understanding of the task set
  • solo learning is more possible

Competent

  • Troubleshooting skills
  • “They can mentor the novices and don’t annoy the experts overly much”
  • informal leadership role
  • more deliberate planning
  • Still can’t apply agile methods to the full extent (!)

Proficient

  • can correct previous poor task performance
  • learn from the experience of others
  • apply maxims (Don’t Repeat Yourself)
  • know what they don’t know

Expert

  • work from intuition
  • unconscious competence (can’t explain why)
  • can take context into account
  • very rare!

2018 Tech Reading Challenge

Many of us are challenging ourselves to grow in the new year. One area of growth I strive for is in my career as a software developer. To that end, I’m sharing my 2018 reading challenge. I hope you will find it stretches your technical ability.

How it works

  • Choose a reading goal early in the year and set your pace accordingly.
    • The beginner reading challenge is 1 book a quarter.
    • The advanced reading challenge is 1 book a month with 2 months off.
  • Choose the books and read them in any order, checking them off as you complete them.
  • Post about your progress on Twitter using the hashtag #2018TechReadingChallenge. (Cross-post on Slack too)

Ideas

  • Define your definition of “read,” since some technical books are pretty dry if you try to read them from cover to cover.
  • Ignore the categories and use #2018TechReadingChallenge about any software development book you read this year.

2018 Reading challenge (beginner—4 books)

  • A book about unit testing
  • A book about a framework, tool, or language
  • A book recommended by a coworker
  • A book published in 2018

2018 Reading challenge (advanced—10 books)

  • All the books in the beginner list plus:
  • A book about leadership
  • A book about an abstract concept
  • A book about software architecture
  • A book about agile
  • A book from the 80s
  • A book with an animal on the cover

 

Learning in the midst of information overload

We live in a world where we are easily inundated by information. Our news feeds constantly update, providing an endlessly scrolling list of tidbits. There are always more Youtube videos, more podcasts, and more articles in our feed readers.

My own story roughly matches this. In the past I tried to cull my list of subscriptions: follow the right people on Twitter and unfollow the ones who tweeted too much. I tried to save time by only clicking on the interesting headlines. Ultimately I found that I still couldn’t keep up, and I was afraid of missing out on what I wasn’t clicking on.

The main mistake is “trying to keep up” in the first place—or having this passive, feed reading behavior be your only way of learning new things. Reading Twitter is a good way to keep up, but it shouldn’t be the only professional development that you do. Sure, it might help you discuss the latest ideas with your coworkers at lunch, but it’s also not going to go very deep for actually improving your professional skills.

Active Learning

Stop Passive Learning. Start Active Learning,” by Andrea Angela was the original impetus for me to write this blog post. The main point of the blog post is to stop endlessly consuming news feeds, because it leaves you constantly feeling behind. Then you have free time, and this allows you to choose a topic to learn, and then look for resources around that topic.

I like that Angela acknowledges that we won’t always have the mental capacity to do “active learning,” and that it is at those times that he turns back to his news feeds in a more passive approach.

Another blog, “Improve Your Self-Improvement” has a similar idea. Don’t just learn something and then set it aside. Share what you learned with others.

Ratio of producing to consuming

After I read about active learning I immediately remembered John Sonmez’s video about the 70-30 rule. This rule talks about the ratio of consuming to producing. Spend 70% of your time producing and 30% of your time consuming. Producing is making value for others, and consuming is just a passive activity where you are looking to be entertained or “informed” but you aren’t actually using that information.

When I think about the 70-30 rule I think of several contexts where I am producing and consuming.

At work, I probably do follow this ratio. In the work context, I would associate producing with tasks like coding, debugging, documentation, and giving demos. I would associate consuming with things like reading my email, checking out the work news feed, and reading the all-company announcements and stuff.

The other context is my after-work work, a term borrowed from “Improve your Self-Improvement” meaning professional development or personal development that is career-related that you do on your own time. In this context, I am striving to move more toward the 70-30 ratio. Some producing tasks include writing blog posts (yay, doing that right now), or taking notes, or coding on a side project. Some consuming tasks include watching Pluralsight, reading my RSS feeds, or other articles I come across on Twitter.

In conclusion, I want to be more proactive, and come up with my own ideas, rather than trying to react and digest others’ ideas all the time. I want to have my own opinions about what is important to keep up with in the tech industry, rather than just assuming that the newest thing is important to me.