Sitting in Blenz, in Horseshoe Bay; it’s sunny outside but I figured I should finish this post before embarking on a pleasant stroll here (picture taken from within the cafe):
My software development career “officially” started when I was 18 years old (“officially”, as prior to that I was still doing software development, just not in a career capacity). Since then, I held two permanent positions.
The first one lasted six years in an establishment I am not in the liberty to elaborate on.
The second one was with the Santa Clara-based security firm McAfee (back then, it was still called Network Associates, until they acquired McAfee some time in 2004 or 2005 as far as I can recall).
That last one lasted slightly more than a year. Then, one day in May 2004, I decided that I am no longer going to be fully committing myself to one department; one cubicle; one company; one interest. I decided that my professional destiny is to become a freelancer – spend my career working with multiple establishments, over the long run, and help them grow.
In June 2004, my career as a freelancer kicked off and is still going to this day. I worked with many companies, across multiple industries, fulfilling various roles. Whether I am good or not at what I do – that is up to my clients to decide; however, I do have my own perception of what makes for a good software professional, and I am here to write about it. Whether you agree with it or not, is up to you.
Hands-on Experience & Responsibilities
Why is hands-on experience important?
Granted, the software industry is over-saturated with software professionals (often dubbed “consultants”) who visit clients, write documents, tell people what should be done and haul away to their next project with a different client.
I always had a problem with such an approach towards career development, for a couple of reasons.
The first reason has to do with actual skills development. I have worked with hundreds of peers over the years, and I can safely state that there is a strong correlation between one’s level of hands-on experience and one’s quality of deliverables. As far as I am concerned, a software professional who claims to be top-notch without having hands-on experience is not entirely different from an M.D. who claims to be an excellent surgeon based on just reading and studying material, without having much hands-on experience cutting through flesh.
This is not to say that “theoretical experience” is not important; it is. However, it is by no means enough (and I’ll elaborate on that in my next post).
The second reason has to do with responsibility. I happen to be a strong believer in “practice what you preach”. If I am to cast my opinion in the ears of an information technology director of a company, I want to take full responsibility over the opinion and advice I provide.
Too often in this industry, I run into individuals who consider responsibility to be a liability; I just can’t get my head around that. When you avoid putting yourself in the position of being responsible for the consequences of your clients following your advice, you automatically give up one of the most important tools – if not the most important tool of them all – to help you become a better professional over time. Not only that, but you also lose credibility – and without credibility, there is very little for you to do in this field.
“Easier said than done” is the most understated value in the software industry today. Normally, the “easier said” part of the equation is done by salespeople, pundits and other non-hands-on-experienced individuals who are eager to make a point (or a sale). The “than done” part is obviously not “their problem” – that part is deferred to “later”. Someone else’s problem. “I’d just like to get paid for the ‘easier said’ part, thank you” kind of thing.
I choose to operate differently. I never have, and never will, sugar-coat bad news or make things appear easy while they’re not, just to make a point. A top software professional is not someone who sugar-coats inconvenient truths; instead, it is someone who knows how to deliver bad news in a constructive manner, and build a case (for example, for a project) based on merits rather than wishful thinking.
Next up, in a few days: theory vs. practice
Isaac
