Pragmatic Learning

I am not always as pragmatic as I should be. This is mainly due to the fact that I’m a moron.

I was reading this post by Scott Hanselman (his voice is so soothing… almost dreamy…) and I realized that I am not terribly good at being pragmatic. I fall into a pretty big trap I think a lot of us nerdy folk fall into: trying to do things right the first time.

Mr. Hanselman was discussing how his past experienced with Win16/Win32/WinForms/Etc. (Thunking? WTF is thunking? I’m pretty sure I don’t want to know.) clouded his conceptions of how to develop a WPF application. He is well versed in the best practices of those older technologies, but WPF is a pretty new animal, and a lot of those assumptions will not carry over. We have to be willing to accept that fact, otherwise we become an obstacle to our own growth (I love Raganwald).

Hanselman started the WPF project with two goals: get it working, and make it clean. He had a revelation, and reading about his revelation caused a revelation by proxy in myself. Getting it working is the more important goal. Making it clean is the secondary goal.

When you have experience with a technology or technique, I believe these goals can be accomplished simultaneously and with no extra cost; however, when learning a new technology, it is hard to make it clean without knowing the best practices for that given technology. Best practices are hard to learn except through experience. You can read blogs all day and talk to people and debate the pro’s and con’s of different approaches, but really until you get in there and actually taste the code, you won’t be qualified to make a judgement one way or the other for your particular application.

That’s the trap I fall into. When starting a new bit o’ code, I read about how it should be done and spend an inordinate amount of time trying to do it right, when really I should just get it working.

Before you jump down my throat with, "Omgponies! The design! The design!", let me clarify a bit. Making it clean is still a goal. After you get it working, you have to revisit it and make it clean.

Maybe you were lucky and did it right the first time. However, for those of us on Earth, we more than likely noticed friction points while writing our code: places where the code resisted our will. We must subjugate these code modules so that they do our bidding without giving us any lip. We must teach them a lesson through the art of Refactoring as handed down from up on high by Martin Fowler (PBH).

So my new mantra: "I can’t do it right the first time, but it’s ok, because I can fix it later."

Oh and caveat emptor: if you don’t have ReSharper, you can’t reasonably fix it later.

This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>