Going the extra mile to make code that doesn't just work -- it works well.

I think that everybody writes code a little differently. I know that the "right" approach taught to me in school, and used by several of the smartest people that I know, is to sit down and carefully plan out each and every aspect of your code. The implementation then is just translating your carefully contemplated notes into code. That really doesn't work for me. Maybe I just haven't transcended to that plane of intelligent yet, but I find that I produce much better code by just starting to work on it. Cluster bomb programming, if you will -- I almost definitely won't hit the target on the first try, but I'll at least figure out the holes in my logic quickly. It usually takes a couple of passes before I've got code that works and works well, but it's there. Oh Linell, that has to take forever! Just do it right the first time! Like I said, this works for me. I'm usually on my second pass by the time I would've finished writing out my thoughts on the code that needs writing. I write code, review it, clean it, and then repeat until I can't think of any more cleaning to be done. In my experience, for me, this produces the highest quality and most complete code.

But.

Sometimes the deadline is a little tight. Hey, we need this. It's super important and needs to be done by the end of the day coming in at noon is a decidedly bad feeling. So I get to the second pass of my code and it works. There's a bit of smell to the code, but it definitely works. Stuff like a method being a little too long, a variable probably not being entirely necessary, or even a couple cases that could lead to faliure could all be there. Stuff that probably won't matter nearly as much as getting this code out of the door. We can refactor later, right?

Meh.

It's happened a few times, I won't lie. Every time it's happened has been a huge regret.

"We can refactor later" turns into "We can refactor that one day" turns into "When we've got some downtime" which ends up being never. Even at a place like SchoolStatus, were we do have the freedom to decide what needs to be worked on for ourselves (outside of the obvious deadlines and super important need it right now stuff), there's almost always something that needs doing more than fixing that code. After all, it works!

At least, it works until it doesn't.

Bugsnag starts shooting errors into Slack. The dreaded "10th error occurence" message is there before you've even got a chance to know what's going on. That code needs fixing and now it's one of thsoe super important need it right now issues. So you open the file, find the problem, and fix it. Whew, problem solved. Except... you're right back where you were. You've still got meh code, you're probably going to have to fix it again one day, and you probably just made the problem worse by tacking another layer of meh right on top of the problem.

The "right" way to solve the problem is to go the extra mile and do it right the first time. Sometimes that's not going to happen for whatever reason, though. You don't have time to make a third pass on it, or you don't have time to sit down and think of every case the code needs to handle. If that happens, what can you do? (Besides the obvious route of just scheduling some refactoring.) When the inevitable required maintenance comes along, do it right this time. There's no way you can't mentally justify it this time, even if you are in a crunch. Make a patch for the bug and then immediately start working on making it not suck. You'll be happy you did every single time.