The Dreyfus model of skill acquisition was devised in the 80s to characterise the different stages a person will pass through as they become more and more able in a given skill. There are five stages in the model:
The novice is someone with little to no context or knowledge around the skill at hand. Here, we might find a complete newcomer to the world of software development. Somebody has recommended that he spend some time on Codecademy learning to code, because it’s a great skill to have.
The newcomer sits in front of his screen and reads the instructions before him, before slowly typing out his first line of code:
He hits enter and boom! “Hello, world!” is printed on the screen, like magic! Now, suppose you were to come along and ask this newbie to print out each item in a given array of floats. This is a fairly simple task by most standards, but you would likely get a completely blank stare in response.
This is because, as mentioned, the novice has very little context, if any. He can follow very strict instructions without much of a hitch, although even then he is likely to make mistakes. If anything goes wrong or throws an error, the novice is likely to be clueless as to how to proceed, because it is not mentioned in the rules he is following. Assuming you are in the software industry, you might still remember being in a similar situation as a novice.
Let’s look at the novice through the lens of this blog. If the novice were looking for a book to progress his ability, the suitable options would be a lot fewer than for someone with more knowledge. Take Clean Code by Bob Martin, for example. Many would consider it to be a decent entry-level book for learning good habits about writing clean, maintainable code. But from the perspective of our novice, who has written a single line of code, the information is mostly useless. There’s not much good in learning how to name variables effectively or how to organise functions when you don’t know what a function or a variable actually is!
A more suitable alternative, and actually the first-ever book on software I bought myself, would be Python Programming (for the Absolute Beginner). Datedness aside, such a book would be written under the assumption that the reader knows nothing about programming and needs the information they need to get started.
Further along the line, we meet the advanced beginner. Having worked through the “getting started” courses and exercises, she has a grasp of the fundamentals of her programming language of choice. The idea of variables and functions are pretty clear to her now, and she knows when and how to apply most of the basic features of her language.
We can see a difference here between the novice and the advanced beginner. While the novice knew almost nothing about coding and could only achieve things through following strict instructions, the advanced beginner has the knowledge to solve simple problems on her own. When faced with errors that aren’t very similar to those faced in the past, she is likely to struggle with troubleshooting them. This is because though she has a good grasp of the language, she lacks the experience to have built up the intuition that is often used in troubleshooting and debugging.
Likewise, if her first programming language was Python and you ask her to write a small program in Java, then she will initially be flummoxed. Ideas such as static vs dynamic typing, and the need to compile Java vs Python interpretation will trip her up and cause confusion. Many of the rules that she has learnt to apply in Python no longer apply in Java. This is partly because she is still only a novice when it comes to Java, but it’s also because of the lack of context she has around coding in general, and high-level concepts such as typing.
If we were to give a copy of “Clean Code” to the advanced beginner, she is likely to get a lot more out of it than the novice. With background knowledge on basic language features, and having written some code of her own, she has better context to apply the advice given in the book. That’s not to say that she is the best audience for the book. With more experience, she may have more nuanced opinions about the book and would be able to apply the rules selectively when they most make sense.
I consider myself to be somewhere between an advanced beginner and a competent developer (see below), and there are definitely aspects of the advanced beginner that I see in myself. Take the following from “Pragmatic Thinking and Learning”:
They want information fast. For instance, you may feel like this when you’re learning a new language or API and you find yourself scanning through the documentation quickly looking for that one method signature or set of arguments. You don’t want to be bogged down with lengthy theory at this point or spoon-fed the basics yet againAndy Hunt. 2008. Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers). Pragmatic Bookshelf.
Until very recently, this was me to a tee. In some cases it still is. If I’m faced with a problem I’ve never seen before or, truth be told, I don’t fully understand the tool I’m using that caused the problem, then I often use the first stack overflow thread that I find that has a similar sounding title and try out the solution without even reading the asker’s question.
Through personal experience, and working with more experienced colleagues, this is a bad habit I’m slowly getting rid of. This leads nicely into the next stage:
The competent developer has a significant amount more experience behind him than either the advanced beginner or the novice. Unlike those two, he is trusted more by his fellow team members to rely on his intuition to solve problems. He can draw from his experience to approach challenges that he’s never had to approach before, and come out the other side okay. Unlike the other two, the competent developer does not have to rely on a more senior person for assistance at all times.
That’s not to say that the competent developer is completely self-sufficient. He has much broader context in the world of development, but this context can often be overwhelming. Though he’s learnt the rules that govern a whole variety of languages and design principles, it might not always be immediately obvious which apply at a given moment. One of the most important skills for the competent developer to learn is how to manage all of this context and group it into relevant sections. Learning to suitably apply your knowledge is key to progressing beyond competence and fostering a sense of responsibility and ownership in yourself.
Chances are, the competent developer has already read Clean Code and regularly uses the advice within in his daily work. Even so, a book like Clean Code is likely to still be incredibly useful for a competent developer, because it will reinforce the good practices that he follows at work. His larger context will allow him to identify when the rules described in the book are relevant, and when they might not be pragmatic. Even the strictest rules have exceptions, and figuring out what and when those exceptions take place is reliant on experience. The competent developer is now starting to build up that experience.
Ask the competent developer why the advice in Clean Code is important, and he might give you a vague, somewhat satisfactory answer that would miss out a lot of the detail. He is unlikely to be relied upon to train and teach novice and the advanced beginner, although they have plenty to learn from him regardless.
The proficient developer has years of experience under her belt that have helped her build up an intuitive understanding of the world of programming. Unlike the advanced beginner who can only debug problems that are identical to those she’s seen before, or the competent programmer who can figure out how to fix new errors in a piece of code that he’s very familiar with, the proficient developer can encounter a brand-new error and use her wide contextual knowledge of the system and of programming in general to solve it. An example is that she understands the underlying implementation of the language she is using to such a degree that she can fix an issue that would stump anyone less experienced.
The proficient developer is also capable and likely to be teaching more junior developers. A deeper understanding means that she is confident that she can condense key points down to something manageable and understandable for less experienced colleagues.
Where less experiences developers find themselves focused on very small parts of the code or single services, the proficient developer keeps the whole system in mind when making decisions. She is able to contribute frequently in meetings about architectural decisions and can be relied upon as a point of contact between the business and the development team.
A book like Clean Code is likely to be of little significant use to the proficient developer. She learnt most of the lessons from it earlier on in her career and years of practice have ingrained them in her ways of working. Her adherence to the rules is not absolute; they are applied only when appropriate and usually as a result of intuition rather than deliberate planning. She might still take a quick look at the book as a reference for the finer details.
The proficient developer is more likely to benefit from a book on higher-level, architectural, or cutting edge concepts. Since she has developed a decent intuition on tech and software-related topics, books with too much explanation will usually feel unnecessarily detailed.
The expert has surpassed the knowledge of most of his peers and is now pushing at the boundaries of his field. His experience in the industry has allowed him to build up an intuition that he can draw from when working. He can solve problems without necessarily registering why or how he came to the implementation he did; it simply seemed like the right thing to do. He still uses his analytical skills to solve problems which he’s never seen before, but even then his process is propped up by his intuition.
The expert is relied upon as a source of knowledge on his field of expertise; the potential for learning from him is high. He can be consulted with to solve tough problems both within his own company and in outside companies.
When it comes to his topic of expertise, the expert is more likely to be writing the books than he is to be reading them. Having long left his reliance on rules behind, he now tries to distil his own tuition into rules and maxims of their own so that he can share his knowledge with the wider world.
As such, much like the proficient developer, Clean Code is unlikely to be of much use to the expert. He has probably read most of the books, both classic and recent, on his topic. To help advance his career the expert might instead look to books on the topics of teaching or writing to help him disseminate his own knowledge. He is also likely to be more interested in research white papers than most so that he can remain on the bleeding edge of his field.
How is this relevant to the blog?
It isn’t always easy to discern at what point someone should be reading a book in order to maximise what they get out of it. I believe that defining different levels of expertise in this way helps us figure that out. You might rely on someone more senior to recommend a book to you, but are they coming at an answer from their own perspective which might be heavily reliant on intuition, or are they trying to base their recommendation on thee perspective of the less knowledgable, more rule-reliant novice or advanced beginner?
As I mentioned earlier in the post, I consider myself to be somewhere between an advanced beginner and competent in the field of software development. As such, I can’t give a completely accurate opinion of whether a book is right for someone at a higher level.
It is through the lenses of the levels described above that I will be looking at a book when I say who I think it would be most useful for. I will make clear the level at which I currently see myself at the start of every book review. This will hopefully help the reader understand my perspective and relate that to their own in order to assess the relevance of my observations. I may make comments which, to someone more experienced, seem nonsensical or obvious. If that is the case then I would gladly discuss it in the comments.
Ideally, I could use the opinions of people at those points in their careers to help inform my content. If you are interested in contributing your own opinions on a book from the perspective of someone more experienced then feel free to comment or reach out to me and we can collaborate!