3-16-2010 10 Things I Wish I Knew…

On another programming blog today, a guy by the name of Chris wrote an article about 10 things he wish he’d known 10 years ago.  It’s pretty telling, I think, that a number of the ones he’s listed are the same that I’d list.  Anyway, here’s the list that I’d produce, which while shorter than his, is pretty much just supplementary to it:

1. People are stupid.
   In essence, they’re going to use your programming in a way that you didn’t expect and didn’t account for.  Assume this and try to fail as gracefully as possible.  Granted, this is a rule from Computer Science 101, but it’s still relevant and something that’s actually rather difficult to accomplish regardless of it’s universality.
2. However long you think it’s going to take, it’ll take longer!
   Chris included this one, too.  My fudge factor is about 2.5.  If I expect something to take 2 hours, it’ll probably take 5.  I’ve begun to simply multiply my gut-level estimate by 2.5 when I talk to people.  This has an added, hidden benefit:  if I beat that estimate, they think I’m awesome!
3. Learn new techniques.
   This is inspired by part of the other article and includes a few things therein.  When I started my current job, I didn’t know very much about some of the techniques I use heavily today.  For example, while my traditional education included object oriented programming, applying the techniques of OOP to web sites wasn’t something that I’d encountered.  Now, however, I use OOP every day (or nearly so).  Same deal with AJAX and other client-side Javascript techniques.
4. Do it yourself or confirm that it’s been done.
   Recently at my day job, I’ve been running into situations where I’ll indicate a concern about this or that and tell someone what they should do to alleviate it, and for a variety of reasons from confusion to misunderstanding to a failure to communicate those concerns remained … concerning … until after the programming was complete and released!  From these experiences, I think I have a new rule for myself:  if you’re worried about it, do what you need to do to not worry about it.  Good rule for life, too.  Whether this means that you have to handling things your self, or just confirm with people that they’re on top of things, taking on a little bit of managerial duties might help solve some problems in the long-run.  Just don’t step on people’s toes!
5. It’ll never be right.
   You’re never going to get it right.  Never.  Not once.  There will always be bugs or problems to sort out and when you sort those out, someone will find more for you to handle.  This shouldn’t be seen as pessimism (though it is a little negative) but rather as job security (see what I did there?).  Seriously, though, eventually you have to bite the bullet and release a product that you’re happy with rather than constantly trying to improve it.  Whether you pull a Google and release it in beta for some time or you just provide incremental fixes to bugs as they come in is likely a decision that you may not be making alone (and may not be included in depending on where you work), but you’re going to have to be prepared for the fact that someone, somewhere is going to do something that’s going to cause your program to fail (see #1) and you’re going to be the person who has to fix things up.  If you let these situations get to you, burn out is likely to be the only possible result.