Passion and Pride

No, you didn't stumbled onto the beginnings of a new Jane Austen novel. It's been a heck of a long time since I blogged and despite being abducted by aliens for the last month, I'm back on the wagon again.

Passion and Pride. These are two key attributes I follow in work. Lately I've been combing the streets for contracts and meeting with all sorts of interesting challlenges, people, and organizations. The one thing that comes up often is the question of values (both in life and work). When I'm talking to these people I emote a strong belief in passion and pride both in teams and a company itself.

I have a deep passion in what I do. Whether it's building ginormus infrastructures in SharePoint or writing a single unit test. I enjoy what I do. I think it's important that you feel what you do is important and have a sense of passion behind doing it. After all, if you're not enjoying your work maybe you should consider going elsewhere? Or changing your environment to suit what you like. You are in control of your destiny. Someone once asked me (as a team lead) when I was going to send them on training for xyz product. I asked them why they haven't gone already and why they were asking me. I'm glad to send people on training if they want it, but I won't shuffle off a team to a week long course because somebody in the organization thinks they "need it". You know what you need and what you want. If you want to better your skills in .NET or Scrum or OO and find something out there you like (I highly recommend J.P. Boodhoo's course but not sure if he's still doing them) then by all means I will fight the good fight (if that's my job) to get you out there. The point here is that you need have passion in what you're doing. J.P. is one of the most passionate persons I know in the software industy and it shows.

Don't get me wrong, you still need technical aptitude. Notice I said aptitude and not skill. Frankly, if you understand structured programming and can grasp the basics of good OOA/OOD there's not a single language or environment on the planet you can't learn. Skill is an attributed applied. I've always considered software an art. My background started in art, and IMHO building software is creation of a new piece of art. With creating art comes passion and you apply skill to hone your craft. When I first started sculpture in High School, I really didn't know what I wanted to produce. My teacher at the time was a great man who, rather than sticking to cirriculum, took his classes through every media known to man. Iron, wood, clay, etc. He wanted each person to find their niche. Their passion. If sculpture wasn't your cup of tea that's fine but at least you tried it. Maybe .NET development isn't your gig. Try something else. Another language perhaps. Or maybe your prefer the Linux platform to Microsoft. Or Apple. In any case, there's a sense of discovery that has to happen. You'll know your passion when you see it. Once you find it, land on it and hone your craft.

The other side of the coin is pride. Again, whether it's a single unit test or an entire solution I try to take pride in what I do. I have a fault in that I'm a bit of a perfectionist so I'm always going back and tweaking something until it's "just right", but it never is. To me this is my continuous improvment technique. I hone my skill by practice, practice, practice and I reflect. When I look at what I've done (and while I'm doing it) I try to take pride in what I'm doing. Recently we had a discussion at a user group where the developer was presenting code he had written to solve a problem. The conversation dipped into things like writing good solid code, abstraction, re-usability, etc. One comment was that "it's only demo code" and that somehow forgave all the issues that I saw in the codebase. True, if you're doing a demo to present to someone you might skip some good practices. For example, not writing unit tests. This is probably the biggest thing I see and perhaps the easiest to accomplish. However I saw if you're building something for anything other than a spike (that you'll throw away) then take pride in your work. If the code starts to get ugly, think about how it might better be accomplished. Is there a pattern here you could use? A state pattern for example to remove an ugly case or switch statement? The biggest excuse will be "I don't have time to make it pretty, just make it work". I don't know how many times I've heard that but then years later come back and see that "ugly code" running a mission critical system.

Take pride in what you do everyday and in everything. It'll reflect in your work and that day that it needs to grow, it won't be a "let's rewrite this correctly". It may take more time at first to "do the right thing" but please don't sacrifice good software practices for the sake of time. I personally have no issues going to a client to say "we can't deliver you xyz functionality in the given time/budget/resources but can give you x and y fully tested and reliable". It's a hard sell but one you have to make. Being proud of the work after the fact shows through it's lifetime and you'll be able to go back and *really* re-use what you've done rather than re-invent. On the flipside, like my perfectionist side, don't go overboard with pride. If you're truely under the gun for delivery take whatever measures you have to do meet those goals but do it smartly. Not every "i" has to be dotted and "t" crossed, but you also don't have to throw out entire modules because of shortcuts. It's a difficult balance but one that will come with time and patience.

So bottom line. Be proud in what you do and have passion in doing it.

Anyways, that's all I have to say about that. Welcome to 2009.