Year End Retrospectives / What good are New Years Resolutions if you don’t follow through…

It’s funny that the older you get, the faster the years seem to move.  I often wonder if it is the routines that you fall into that cause the days to just fly by or it is that you become cynical and bitter and lose that wonderment that you had as a child?  Or, if you’re like me, it’s that you’ve got so much on your plate that you never seem to get anything done, yet at the same time, you do get a lot done — it just never feels like it.  And like that, we’re at the end of this year and waiting a new year to show up so we can write a list of things we want to do, look at what he didn’t accomplish and push it to the next year and try at it again.

It’s the year-end retrospective; and it feels like you’re at a job.  You’re always doing these retrospectives, be it every month, every week, every product delivery, whatever.  The reason these work retrospectives work is that you’re sitting back figuring things out, really analyzing what went wrong, what went right, what you can do to improve.  Unfortunately, we don’t hold ourselves to the same standards we do at work.  We write the new year resolutions, tell ourselves we’re going to do it and then a week or two later fall down on the job and not do any of them.  We make excuses as to why we couldn’t do it.  I say, forget that.  Hold yourself accountable.  Set goals, set high goals.  Set goals that seem impossible to achieve — that is the only way you’ll get better.  To strive for something, to push yourself to the edge and complete it.  I know this sounds like a bunch of self-help schlock (and it probably is) but you’ve got to do something to push yourself forward.

Now, off from from that little derivation, the one thing that happen with retrospectives is that they occur at regular intervals to make sure you’re on target.  I think this is the one thing many people don’t do with their resolutions — don’t follow through and don’t take stock of how far they’ve gone in completing the resolution.  I suggest that what needs to be done is to do retrospectives each month on the resolutions.

Of course, now, what good would I be if I didn’t objectively talk about how I did on my resolutions for this year.  My main goal was to propose my PhD topic this year.  However, I didn’t get this goal like I had hoped — I got much closer, however — which was nice.  So you know I’m going to be putting this high on my list for the coming year (and once achieving it, putting completing my PhD up there as a high priority).  The other goals I had, some failed, some I succeeded on and others I still put in the improving range.  So come January 1st, I want to list out my new goals and do a once a month check-up on them to prioritize and update my progress on each of the goals I have.

Now that I’ve talked about how I intend to follow through on my New Year Resolutions, what are some ways you handle your resolutions?  Not make them at all? Do more of the same (not a good idea unless you’re constantly improving at something).

Overfactoring: Taking Refactoring to the Extreme

I think refactoring is a great process that every programmer should be aware of and practice it judiciously.  The benefits of clean code are numerous and if you can’t figure out why you’d want to refactor, then don’t bother reading the rest of this post. 🙂  However, like anything else in this world, there is always too much of a good thing.  Eat too much candy, you get sick to your stomach, throw up, whatever (you at least don’t eat already been chewed candy).  Refactor too much and what do you get?

There is a sweet spot between completely sloppy code and code that has been refactored too much that you can’t make heads or tails of what is going on.  The sweet spot is where the code has been made better; it needs to have the right amount of abstraction and coupling to all the other classes associated with it.  Remember, this is subjective and it comes down to experience to know what is too much or too little — the more you program the more you’ll know what that sweet spot is.  I’ll say the best way to know when to stop is when you’re no longer applying it for a purpose and you’re just applying refactoring for the sake of refactoring.  Or, if you want something more definitive on when to stop refactoring, this page has some pretty good guidelines.

Of course, you can always remember the golden rule of coding: always leave the codebase in a little better shape than when you entered.

Source Code Control and Release Management

Two concepts that are never touched on in college, yet are highly important in business (and academia for that matter) are source code control and release management.  Yes, everyone knows that it should be done, yet I’ve never really seen a good primer on it until recently.  The funny part is, these primers came from The Daily WTF (which I guess is appropriate when one thinks about it).

The source control primer goes from the ground up describing exactly what source control is and covers many of the common operations done in source control: gets, puts, merging, branching, labeling and even shelving.  The release management primer is also quite good and gives a good idea of how release management should work and even provides a nice example to help follow along with the concepts of release management.

These two articles definitely helped codify a few concepts in my mind about source code control (more than just use it) and release management (more than just: don’t break the build) and it should help you as well.

Are there any other articles out there that are worth reading about source code control and release management that might add some more insight that was missed in these two?  Let me know.

Using the iPhone as a source of music on your VW Jetta SportsWagen with a Bluetooth connection

Now, being the person that I am, I love music and love listening to it wherever I can.  It makes sense then, that I put a lot of music on my phone.  My iPhone has the ability to connect through Bluetooth to my car and should have the ability to send the music to the speakers within the car.  Now, the issue is, how do I do that?  If you’re like me, you don’t read the instructions cause they’re long and boring.  I want the three bullet points to make it happen.  So here is how it works:

  1. Make sure your phone is connected to the car through Bluetooth.
  2. Start playing music on the phone’s music player
  3. On the radio select ‘BT Audio’
  4. Listen to the music through the car’s speakers

See, that was easy.  Why it took me two manuals for the car to figure this out is ridiculous.

Issues in Object Oriented language programming

I’ve been coding like a man possessed in the recent weeks (for both work and school) and I’ve been seeing it first-hand that just because you call yourself a Java developer doesn’t mean you know object-oriented programming or any of the main principles behind object-oriented design.  I’ve seen Java classes only containing static methods (and I hate saying methods, because, these are really functions) then being treated like objects,  I’ve seen classes that reference variables in other classes without any encapsulation, I’ve seen method names and class names that are not the Java standard tangled with classes names and methods that are, and I’ve seen objects that have been decomposed through interfaces and objects that they stop being coherent.

In my opinion these are all lack of experience issues, but the first three are for a different reason than the last.  The first three happen because you’re a new to Java (or C# or any other object-oriented language) or you’re steadfastly stuck in your ways as a C-style programmer.  The last one occurs because you’ve read too many books and haven’t done enough real-life programming to realize there is a point at which decomposition makes the answer hard to understand (or isn’t even the right approach).

I’m not dead (nor is this website), I’m just extremely busy!

School, work and life sure have a way of making life crazy for you. I’m hoping to get to the point where I can update everything on my site from random thoughts that have been bouncing around my head to talking about the new workout routine which I haven’t had a chance to get off the ground — and if I’m feeling saucy, my PhD work.

Once I get my PhD proposal done and accepted, I’m hoping life can slow down just a shade so I can catch my breath, then push on through to the end when I find out if the light at the end of the tunnel is a train or daylight.