This Week, Last Week, Next Week…

Excuse any typos, but this is a seat of my pants post… I finished up one job last week, which led to time to refactor this proof of concept class while revising other work. Exterior demoes of these proofs get reactions akin to saying, “Wow!” But I feel like Oz, saying “pay no attention to the duct tape and zip ties holding up the curtain!”

When I say “proof of concept” I usually mean, if you look at the underlying code you realize the magic is in the amount of code smell (aka Bad Practices used) — which happens when I just sit down with an idea and just write something that works and best practices aren’t at the forefront. An analogy of this would be an artist sketching a picture quickly to just practice the art and exercise their perception-hand-eye-coordination. Another dev would see this stream-of-consciousness sketch-style coding, and think “that’s crap!” because trying to modify it would be a huge pain. And I couldn’t disagree, because modifying would be a huge job in comparison to writing new code.

However, It is times like these I like to reread this: http://stilldrinking.org/programming-sucks to remind myself that when I mentioned how I hate working with “crappy” code or incomplete documentation. 

Any time I do toss a stone at some crappy code, I get some snarky “this is where the magic happens” comeback, and sometimes even that venn diagram showing my comfort zone outside it. Yeah, guys… I get it. I realize that we are all guilty of it because of workload or time constraints — no one is perfect. There is only so much one can do in one session, even if that session is a solid 13 hours (which I have done before). So, I can either throw stones or TRY to develop better sketch practices with each sketch. This is what I have been doing the past week. I will write a class with comments, DI, patterns, etc. Then look back and see where the comments/structure broke down or when things got vague or messier. Things are improving, but they aren’t where I would like them to be.

But, does it really matter if my on-the-fly code is written poorly as long as it doesn’t crash? Probably not to anyone that might use it, but oddly I can’t get a voice out of my head that says this is wrong. If I want to see better examples from others, I should practice what I preach, and only release the refactored stuff, and things that don’t set off any code reflection warnings. Last week I only had the energy to write 3 base classes, each one had at least 2 or 3 code smell warnings. This week I refactored and got fewer warnings, but then the limits of the docs smacked me in the face, and things broke. I suppose this is part of the growing pains of learning how to use new tools. And then I bang on the problem until I either revert to a smell-but-working version or figure out what the documentation meant. This is when I re-read this: http://stilldrinking.org/programming-sucks so I don’t feel so bad about why I am not getting it.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s