Core Strength

A common mistake many people make when they first begin exercising is to focus on the wrong thing.  How many calories did I burn?  How many pounds did I shed last week?  How fast did I run that last mile?  Although all of these things are good indicators of how you may be progressing, they’re not such good indicators of why you’re progressing as you are.

You see, all of the goals listed above are simply end results that happen to come with dedicated training and commitment.  They’re not the focus of the training itself.  Most exercise experts recommend focusing more of deeper indicators of your overall health such as heart rate.

How does relate to software?  Simple.  Don’t spend too much time working on point technologies such as the latest and greatest web framework or UI toolkit.  Although there is undoubtedly value in this, you’ll likely glean more value from shoring up your understanding of more technology agnostic principles like patterns and emergent design techniques.  Not only can you take these lessons to any technology, but you’ll likely gain a deeper insight into the inner workings and philosophies of the next framework you learn which should greatly reduce the time it takes to understand it.  The reason is that you won’t be focusing on the end result (the finished technology) but why certain decisions were made in designing that technology.

To be clear, I’m not saying don’t spend time playing with different technologies.  Experiencing other ways of thinking can pay off dividends in your own work.  There’s also a definite benefit in learning as much as you can about your current platform and language(s).  But I am suggesting that you put more of the focus on the technology agnostic fundamentals.

Take CAB, for example.  The CAB is an incredibly powerful UI framework, but it has a learning curve like a brick wall.  The first time I tried to to learn CAB I was completely and utterly lost.  It was incredibly complicated and nothing seemed to make sense to me.  However, when I returned to it later on, after becoming exposed to many of the patterns at work inside of CAB, I was able to pick it up in a much shorter amount of time.  Why?  Because many of things that had originally confused me no longer seemed like arcane, CAB specific rules but rather how CAB chose to implement well established practices.  I was able to not only see the big picture of many of the ideas at work inside of CAB, but I was able to glean the specific implementation of them much quicker because I already had a solid understanding of their underlying fundamentals.  I then only had to focus on where CAB deviated from the norm or how it was using that particular pattern in its own implementation.

Here’s a better reason:  the future is always uncertain.  I can be reasonably sure of what sort of technologies I’ll working with in the next three months.  In six months, I can make a decent guess.  How about in a year?  How about in two years?  I have no idea.  Our business requirements change fast and what our customers want today may be very different then what they want tomorrow.  This is particularly true when we take into account what our competition may also be doing over the next year.  Spending time deeply learning a new framework that I may or may not use in the next twelve months isn’t going to pay off nearly as handsomely as spending time learning fundamentals and principles that I can use in any technology.  The best way to ensure that I can handle anything my job throws at me, and hit the ground running with it, is to focus on my core software development strengths.