Category - Software & Technology

Pride has its place. You should take pride in your work, your family, and things that you do. It is when this pride becomes excessive that there are problems. The right amount of pride will ensure that the highest level of quality is achieved in everything we do because we will check and check again to make sure that the work we do is up to par with what we consider correct. However, slightly too much pride can tip the scales and usher in carelessness. When we think we know it all we let down our guards and have a tendency to stop second guessing ourselves, which increases the probability for mistakes.

Programmers, for the most part, are a pretty positive bunch.  We tend to think we can solve the problems of the world through a couple well constructed key strokes. While we often have the best of intentions we are also fallible and find ourselves backtracking to undo our mistakes on a regular basis. The difference between developers that spend a lot of time backtracking and those who spend very little can ultimately be boiled down to pride, ceteris paribus. So how can the typical developer keep a tight leash on hubris? Write test cases.

When developers begin to assume that they are too good to need to write test cases problems often follow closely. Test cases form the foundation for unit testing, refactoring, and new development and serve as a base to which developers can use to ensure that their changes did not have any unintended affects on the system at large. Test cases are simply good programming practice and should be an essential part of any developer’s repertoire.

As professionals we should, for the most part, find ourselves in a perpetual state of learning. It is when this trend of a ferocity for consuming knowledge subsides that we find ourselves bordering on mediocrity and threatening to fade away into the abyss of the typical. As a junior, mid and senior level developer I was constantly reading. Looking back I now wish that I had, at times, chosen different content, however I still give myself kudos for reading something.

As part of the shift from a mid level engineer to a senior one I began taking part in interviews, a process that has left me confounded at the masses of software engineers that consider themselves to be senior level but are anything but. My wife has mastered the lingo and many of the buzz words of the industry simply from being around me for my years of service to the software industry. However, the difference between my wife and many buzzword slinging prospects is that my wife will openly admit where her knowledge is lacking. Job candidates, however, often do not. I am continually astounded when I ask a “senior” level engineer for a couple books they have read only to find that Sam’s Learn [LANGUAGE] in [TIMEFRAME] is the front runner in their literary portfolio. I must admit I have read some of these books and I actually think they have their niche in which they provide benefit, however you will never hear me mention them in line with Design Patterns: Elements of Reusable Object-Oriented Software, Refactoring: Improving the Design of Existing Code, or Effective Java.

I like to consider myself a very good software engineer – I study hard, I try and stay abreast of the industry, I practice hard and learn from my mistakes, and I pay attention to those who I have recently seen dubbed as software “rock stars”, people like Joshua Bloch and Martin Fowler. It pains me to see such a high number of software engineers that expect the longevity of their career to dictate both their status in the field and the quality of their output, as this expectation is a fallacy in its purest form. I have worked with many individuals who possessed unbounded potential but refused to apply themselves. Likewise I have worked with many whom have had unbounded potential and have applied themselves, many of which I expect to some day see in that ever expanding “rock star” clique.

The point here is simple. Those who read and apply themselves will, talent willing, find themselves moving into the upper echelon of the software world. Those who don’t are destined to remain followers of the software elite. Don’t believe me? Check out The Mythical Man Month and pay close attention to the emphasis that Brooks continually places on the programming elite.

Of course the true irony of this post is that the intended audience is unlikely to ever read it.