Exposing my ignorance
I am currently reading (on impeccable advice), Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The book is written as a series of ‘patterns’, a method of analysing and solving problems which is derived from a book I’ve always meant to read but haven’t, A Pattern Language by Christopher Alexander, Sara Ishikawa and Murray Silverstein. There a pattern is a solution to an architectural design pattern, a “best guess as to what arrangement of the physical environment will work to solve the problem presented.” Here the patterns are ‘best guesses’ as to how to solve the problems of becoming a better developer.
Two patterns I’ve been looking at in the last few days are “Expose Your Ignorance” and “Confront Your Ignorance”. The first pattern declares that, as an apprentice you don’t know how to do a lot of things that you are going to have to do. A first instinct (OK, my first instinct) is to hide that ignorance, nod blithely as the person describes the thing you don’t understand and then do a lot of reading and experimenting when you’re back home. ‘Fake it till you make it’.
This can work, but it’s incredibly inefficient. Other people know already, most importantly the people who are asking you complete a task. Just say that you don’t know - that way you open up the opportunity for them to help you where you struggle. Take route A, the shortest path between two points, and ask questions. This quote sums it up:
“Tell people the truth. Let them know that you’re starting to understand what they want and you’re in the process of learning how to give it to them. If you reassure them, reassure them with your ability to learn, not by pretending to know something you don’t. In this way, your reputation will be built upon your learning ability rather than what you already know.”
My quality as a programmer is not defined by what I know, but rather by what I can know. But the hardest person to expose that ignorance to is always yoursel
The corollary to “Exposing Your Ignorance” is “Confronting Your Ignorance”. An old colleague of mine would always say that he’d forgive anything, other than ‘willful ignorance’. There’s little point in declaring your ignorance if you’re not actively addressing those gaps in your knowledge. Asking questions is a start, but oher techniques like pair programming, building example projects, and good old fashioned reading, are there too.
Each pattern has a set of actions associated with it. “Exposing Your Ignorance” asks that you write down five things that you don’t understand about your work and put it where others can see it:
- Can I build a toy app in Java?
- How do I use mocks in Java (London style TDD)?
- How do I implement a ‘hexagonal’ design, and what does that even mean?
- What are generics (in Java and elsewhere)?
- What is the best way for me to structure AngularJS and other JavaScript projects?
- What is functional programming? I mean, really?
- What is an algorithm and how do I measure its efficiency?
- Refactoring. I (think I) know what it means but can I learn some patterns to do it better?
Not exactly five, but I could probably write fifty at the moment. There are lots of other things I don’t know (list as long as my arm). But, you’ve got to start somewhere.
The action for “Confronting Your Ignorance” is to pick one of the things on your list and, well, learn it. Nice and simple - show your ignorance and own your ignorance, and fix your ignorance. That’s a powerful tool.
I’m enjoying the book. I’ll hopefully provide a fuller review at a later date. And also provide an update of which of my ignorances I’ve confronted.