On Getting to Concious Competence, Cunningham's law & Bike-Shedding, Mistakes are unavoidable!
November 03, 2021
Some of the very important notes (for myself) from the early sections of the book, The Missing README, A Guide for the New Software Engineer by Chris Riccomini and Dmitriy Ryaboy.
Getting to Concious Competence
Martin M. Broadwell defines four stages of competence in Teaching for Learning:
- unconcious imcompetence
- concious incompetence
- concious competence
- unconcious competence.
Specifically, unconcious incompetence means you are unable to perform a task correctly and are unaware of the gap.
Concious incompetence means you are unable to perform a task correctly but are aware of the gap.
Concious competence means you are capable of performing a task with effort.
Finally, unconcious competence means you are capable of performing a task effortlessly.
All engineers start out conciously or unconciously incompetent. Even if you know everything about software engineering (an impossible task), you’re going to have to learn practical skills like those covered in this book. Your goal is to get to concious competence as quickly as possible.
Cunningham’s Law And Bike-Shedding
We advise you to document, conventions, onboarding procedures, and other oral traditions on your team. You will get a lot of comments and corrections. Do not take the comments Personally.
The point is not to write a perfect document but rather to write enough to trigger a discussion that flashes out the details. This is a variation of Cunningham’s law, which states that “the best way to get the right answer on the internt is not to ask a question; it’s to post the wrong answer.”
Be prepared for trivial discussions to become drawn out, a phenomenon called bike-shedding. Bike-shedding is an allegory by C. Northcote Parkinson, describing a committee assigned to review designs for a power plant. The committee approves the plans within minutes, as they are too complex to actually discuss. They then spend 45 minutes discussing the materials for the bike shed next to the plant. Bike-shedding comes up a lot in technical work.
Mistakes are unavoidable (Learn by Doing!)
At one of Chris’s first internships, he was working on a project with a senior engineer. Chris finished some changes and needed to get them deployed. The senior engineer showed him how to check code into the revision control system, CVS. Chris followed the instructions, blindly running through steps that involved branching, tagging, and merging. Afterward, he continued with the rest of his day and went home.
The next morning, Chris strolled in cheerfully and greeted everyone. They did their best to respond in kind, but they were low. When Chris asked what was up, they informed him that he had managed to corrupt the entire CVS repository. All of the company’s code had been lost. They had been up the entire night desperately trying to recover what they could and were eventually able to get most of the code back (except for Chris’s commits and a few others).
Chris was pretty shaken by the whole thing. His manager pulled him aside and told him not to worry: Chris had done the right thing working with the senior engineer.
Mistakes happen. Every engineer has some version of a story like this. Do your best, and try to understand what you’re doing, but know that these things happen.