My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
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:
  1. 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.
  2. 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

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner