Although computer science is a young field of study, it is rife with examples of good and bad
ways to do things. This week's advice from
MJWTI
instructs us to focus on the past - learn from the successes and failures of those who came before
us.
Chad includes a quote from a Jazz musician that illustrates the concept of how we
learn to become masters quite well:
Imitate. Assimilate. Innovate.
We saw a longer version of that in a quote from Ron Jeffries in last week's post about
getting good at the process of software development:
My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?
Similarly, part of
code practice
involves studying other people's code.
Doing so is good to teach you new tricks and things to avoid. But as
Chad also mentions, it also exposes you to projects you might not have otherwise known about -
giving you the option in the future to reuse it instead of writing your own version if your
application requires it.
Two books I bought a few years ago might have been a good start to doing this type of thing:
Mmurtl V1.0: How to Develop Your Own 32 bit OS and
Linux Core Kernel Commentary.
Sadly, I never did read them, and no telling where they are at now.
But not having those books won't stop me from reading source code - I plan to start that as
part of my weekly practice sessions. It fits so well with one of the things I'm most
interested in - improving the design of my own applications.
You can say you don't run into trouble and therefore, your design is good, but how would you know until
you've gone back to it after not looking at it for a year? You need something to compare it
to, and I'm not convinced a UML diagram will suffice.
On top of that, if I'm lucky
I'll gain some insight into
my questions about how people go about designing algorithms.
(Do you have answers?)
In the end, Chad gives two action items to follow up on:
-
Pick a project to read, make notes, and "outline the good and the bad." Use that
experience to publish a critique of
the project and it's code.
-
Start a study group to dissect and learn from code.
I'd like to start reading other source code, but I'm not sure when I'll publish a critique of
it. On top of that, one of the things I'd like to do in the code dojo is dissect other people's code, even
if I already find it helpful to analyze our own.
When you look at code, do you do it with a critical eye?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
I think that is why I enjoy participating in code reviews so much, for the learning aspect of it. I think they help strengthen your existing knowledge while exposing you to new ideas, different techniques and other developers approaches to solving problems.
Wouldn't it be cool if there were a service where people could volunteer their time to review code from those brave enough to post it?
Posted by
JAlpino
on Nov 30, 2007 at 12:59 PM UTC - 5 hrs
You know, I never thought of it quite that way before. That's a good way to look at it.
About the service you mention - funnily enough we were talking about doing that in a new version of the JUnit website (to be clear, I'm not affiliated with them, but I did attend a workshop to add functionality to the site where we spoke about it).
No worries on the double post- I'll remove it in a bit.
Posted by
Sammy Larbi
on Nov 30, 2007 at 01:23 PM UTC - 5 hrs
