CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

An infallible mechanism to measure your growth as a developer

Unfortunately, I think the best barometer to measure your growth as a developer is looking at your old code and cringing.  This morning I needed a little enhancement to a web page, and rather than writing something new or looking for something to download, I went and pulled out an old script I'd written 4+ years ago.  It's perfectly functional and worked on the first try, but I made the mistake of looking closely at the code and almost wanted to puke.

I've almost always gone through a wave of "man, I wish I'd done that differently" headshaking after significant projects.  I've never been able to look at a completed system six months later and not see ways that it could have been built better or simpler.  If your code from a year ago looks good to you, you might just have peaked as a developer.



Comments

johnwood said:

You're right that's a great metric. If that code's in production it's probably worth spending a fraction of your week going back to that old, dusty code and rewriting functions here and there to take advantage of your new perspective and skills as a developer.
# July 20, 2006 11:48 AM

Willie said:

I do the same, but I do notice that I've been getting better.  Code from 6 months ago isn't AS ugly as it was years ago.  Peaked?  I doubt that, there's always something new to learn it seems.
# July 20, 2006 11:50 AM

BigJimInDC said:

Personally, one of the things that has kept me in the industry the past 15+ years is nearly every day realizing more and more things that I don't know but feel that I should know or know that if I did know them the results I produce would be better or my life would be easier or both.  In other words, considering the huge size of knowledge contained within our industry, anyone who thinks for a second that they know enough that they don't need to keep learning has stopped growing.
# July 20, 2006 12:36 PM

Greg said:

This brings up another good point when looking at your current code, its easy to be overly critical of code. That code you wrote four years ago you thought was good, and the customer probably loved it.

This also scares me whenever I go to another field. Since I look at my five year old work and cringe, does a Doctor do the same thing?
# July 20, 2006 12:40 PM

AggieEric said:

Why is this "unfortunate?"  Any true craftsman is this way.  My father-in-law is a furniture builder in his spare time.  And, his current works are much better than he pieces from five years back.

Oh, and starting to change that legacy code just to make it look better is quite a slippery slope to step on.  That is, unless you want to start by getting it under proper tests first - asuming it is easily tested.  I know my 5+ year-old projects are not.

I've been puting off fixing some bugs in an old project because I don't even want to see that nasty code.
# July 20, 2006 10:16 PM

Joel Rumerman said:

"This also scares me whenever I go to another field. Since I look at my five year old work and cringe, does a Doctor do the same thing?"

-- skills and techniques are constantly changing and improving. It's why a lot of professions have continual education requirements to maintain certifications. I hope today's doctor has better techniques than the doctor of five years ago. It doesn't mean that the older technique was wrong, however.
# July 21, 2006 3:44 AM

Jason Haley said:

# July 25, 2006 11:34 PM

K. Scott Allen said:

# August 9, 2006 10:50 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

Our Sponsors

Proudly Partnered With


This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP