POST

Refactor

I have spent the duration of my adolescent and adult life (lives?) programming many different things with many different results. I’ve tried planning out everything. I’ve tried not planning at all. Often the results are not all that dissimilar in terms of the number of issues that arise. Surely you need some planning; that’s not what I’m talking about. I’m referring more to the fact that only liars will tell you that they’re right all the time, or that the path they’re on can’t turn out to be the wrong path.

If you’re being honest with yourself you know that there’s no accounting for every contingency, and often you won’t discover a hole in your logic or design until much, much further along in a project. If you can accept that, then you can begin to look at your own work objectively. If you’re looking at your own work objectively, you can see that there will most definitely be problems at some point in any project. The magnitude and extent of those problems isn’t particularly important.

I feel pretty comfortable saying that software engineers don’t usually address these potential problems in particularly healthy ways in regards to their engineering, emotions, or otherwise. Have you ever gotten defensive about a decision you made that turned out to be, well, less than incredible? How many times did you build out an elaborate system to address an edge case that turned out to not really be a problem at all? In that same project, did something else bite you in the ass? Well you and me both pally. In fact we have lots of company… nearly everyone we’ve ever worked with in fact.

So really the only solid advice that I think one can give or follow is as such:

  1. Learn to type fast
  2. Don’t be afraid to refactor things when necessary.

#1 is dead easy. Be embarrassed if you don’t have a good reason for not typing well if you’re a programmer. It’s really not that difficult and it’s far more comfortable to type all day when you’re not hunting and pecking. I’ve learned how to type twice now… just… you know… get on your big boy/girl pants and make that happen.

#2 is the rub. What does “Necessary” mean exactly? If you only allow refactoring when flaws will stop the Earth from spinning, then you’ll never get to it. Likewise if “Necessary” means “It would be cool if…” then you’ll never finish anything. I won’t lie to you and say that that’s an easy thing to figure out for any project. And indeed this is why experience often means more to employers and coworkers than aptitude (and why those positions requiring it pay more).

And now to end on a grandstanding, overly preachy note (this is a blog after all):

  1. Be honest about your work and where you are with it (this makes everything better in the long run)
  2. Anyone that would tear your head off for asking a question isn’t worth being around and is going to end up making it harder for you to learn anything new.
  3. Anyone that would think less of you for seeking out their own expertise isn’t worth your time.
  4. There are a finite number of hours that you get to be alive.
  5. Your time is, in this context, inherently valuable (to youspecifically).
  6. Don’t fuck it up.

-r