We’re back with our last deep dive into Robert C. Martin’s latest book, Clean Architecture, while Allen suffers from sleep deprivation, Joe shows us his dance moves, and Michael’s mind is blown on how to unit test.
The Coding Blocks podcast has always been about trying to figure out how we can be better programmers.
I was fascinated by the book Outliers a few years ago, and it is quite controversial now though I think the premise is solid: Extraordinary skills require a winning combination of opportunity AND hard work.
I’ve been on a quest to create and foster these two things ever since!
Along the way, I have read a lot of the popular literature about “deliberate practice” and I have tried to distill the information for the field of software engineering.
Here is a collection of blog posts and resources on the subject. Some are still in progress so check back soon. I hope you are able to get something out of it!
What does it mean to be “good”?
- 4 Reasons why the 10X Developer is so Controversial”
- Knowledge vs Skill
- Programming is a skill, and it is hard!
- What does “better” mean to you?
What is deliberate practice?
- TODO: The deliberate practice cycle
- Be Careful with your Side Projects!
- TODO: Flow is great, but it is not practice
How can we apply deliberate practice to programming?
- TODO X for Y vs Soft Skills
- TODO Interviewee example
- TODO How do writers do it?
- Peak: Secrets from the New Science of Expertise
- Outliers: The Story of Success
- Practice Perfect: 42 Rules for Getting Better at Getting Better
- The Power of Habit: Why We Do What We Do in Life and Business
- Grit: The Power of Passion and Perseverance
Most resources are “inline” but here are a few that I liked that weren’t explicitly called out somewhere else
You watched the videos, read the books and now was ready to start S.O.L.I.D.-ifying their code.
Monday morning, you fire up your favorite IDE and prepare to start writing beautiful, singly responsible and properly abstracted software.
But, unbeknownst to you…you had crossed over into the
Twilight Zone real world!
The notion of the “10x Developer” stems from an infamous study that measured and compared the productivity of programmers. The study found that although the programmers had roughly the same amount of experience, (7 years) some programmers were far more productive than others.
In fact, the best programmers averaged more than 10 times the productivity of the worst. Hence, 10x. (note: I said average, debugging time was a ratio of 20:1!)
These radical results have been a source of debate ever since.
I’m very interested in assessing and improving my own skills so I took a deeper look to see what exactly was so hot about this topic.
It boils down to these 4 things:
I recently wrote about the differences between programming knowledge and skill in a previous post. In short: knowledge is what you understand, and skill is what you can do with it.
However, it is not enough to “know” a programming language, you need to be able to make cool stuff with it. Knowing is only half the battle!
So…what advice does the software engineering industry have for programmers who want to advance their skills?
What does it mean to be good at something?
Knowledge is understanding of a subject, skill is your proficiency in the application of that knowledge. By definition, you can’t be skilled at something you don’t understand. But knowledge on its own is only half the battle.
“Programmer” is a vague term. I’m willing to bet that Grace Hopper’s vision of “better? involves a lot more math than mine. The skills and methods of her practice would be a lot different as a result.
Goals change as well so we need to re-evaluate from time to time. If you asked me what being a better programmer meant 10 years ago I thought Design Patterns were *THE PEAK* of programmer evolution.Right now I’m primarily focused on growing maintainable software systems, modeling business processes, and communication.
Either way, it is important that you identify what is important to *you*.
It’s time for another deep dive into Robert C. Martin’s Clean Architecture as Joe puts us on the spot, Allen has a new mission, and Michael shares his Easter eggs.
Michael can’t tell higher from lower, Allen puts his views where he wants them, and Joe snaps it to a Slim Jim as we discuss how to make our architectures scream while discussing Robert C. Martin’s Clean Architecture.
It’s time for another deep dive into Robert C. Martin’s Clean Architecture as Allen warns us about driving in front of him, Joe tries to describe a diagram again, and Michael can’t understand the survey results.