Links
·
RSS Feed
Popular Pages
|
|
Quoting Watts Humphrey, "Developers are caught in a victim's mentality." We never think it's our fault, it's always somebody else's.
-Jared Richardson |
|
Do it right from day one or you never will
-Andy Hunt |
|
I haven't had the chance to read and review any books from the Pragmatic Programmers series. I decided to change that with the book Ship It! - A Practical Guide to Successful Software Projects by ...
-Thomas "Duffbert" Duff |
|
|
|
|
(May 12)
The Dreyfus Model has five stages, and understanding them has helped me decipher so many reactions I've seen, both in software and in life.
The Novice
Our first stage, also known as the beginner, is someone just learning a new skill. When you learn a new programming language or a new tool, you need steps. Most successful programming books provide a number of easy to follow steps (remember 10 print "Hello world"?). These steps help familiarize you with the environment and what things you are supposed to do. If you'd like a refresher in how this works, try teaching an introduction on Java or Junit to people with no experience. It's amazing how many things we take for granted. If you skip steps, students get frustrated and quickly let you know, or just shut down.
The Advanced Beginner
We become familiar when we've seen enough explicit examples that we can start putting them together. We accumulate code snippets that work. We're not positive why they work, but they do. Unfortunately, this stage is still famous for frustration. When things don't work, we still don't have the skills to debug those problems. We need things to work the way we expect them too, but we're building an experiential skillset of what works.
The Competent
This stage is what I call the recipe stage. We can finally get things working and become cut and paste gurus. We've got tons of working solutions at our fingertips. I used to carry around a CD with collections of projects and code snippets. These recipes helped me look very smart and enabled me to quickly "solve" problems and churn out working projects. We've developed enough experience to understand what's likely to go wrong and the debugging skills to solve problems. Most developers hit this stage, achieve a solid level of competence and effectiveness, and they stop learning. They're too busy working overtime and solving problems to continue learning. And why bother? I'm getting stuff done, right? This is the trap… good has become the enemy of better and best. This local optimization prevents so many in our industry from moving to the next stage.
The Proficient
Things finally become smooth. We discover patterns, principles, and values. We start to understand that we don't have a daily meeting because we're "doing Agile", but because the team needs to interact and share information with each other. And sometimes there are more effective ways to do that. We realize that test first isn't about creating a test suite, but about helping us think about the problem we're really solving. We start to use techniques like the "5 Whys" and advice like "keep improving how we deliver value at sustainable pace" finally makes sense. Sadly, as we enter this amazing new world, we often start spending time with others who've already arrived here. We begin using terms like "code smells" that our Competent Stage friends don't understand, and we slowly drift into the bubble of Very Smart People. As we're surrounded by these Very Smart People, we begin to assume everyone is also Very Smart, and we begin to forget how to provide steps to beginners, widening the gap between the stages. As we all know, smart people attract smart people, and incompetent do the same. Birds of a feather do flock after all. So the shops that have the higher-stage teams don't usually hire the lower stage applicants, and vice versa.
The Expert
The expert stage is known for intuition. In the development world, we call these people all sorts of colorful names. Wizards. Code ninjas. Rock stars. These are people who sit down, look over your architecture and tell you it won't scale. They might not effectively verbalize why it won't scale because they don't always think in steps anymore. In fact, it's often easier for them to redo your work themselves than it would be to explain the flaws in the architecture. Naturally, these 10x productivity team members are idolized, leading the ego we often seen in these people. You have a problem? Here's a value. Here's a principle. Here's an idea. You don't understand it? You must be dumb. I know I'm not. (Sound familiar?)
Category: Agile
|
|
|
|
|