Let me start out by defining exactly what I mean by a Successful Developer.  The ideal Successful Developer is one who is loved by management, users, and fellow developers.  I know what you’re thinking, how hard can this really be?  Well, take a look at your own career and think back on how much you’re really liked in these three areas...

Managers typically look for someone who can make them look good.  This isn’t meant to knock anyone who I’ve ever worked for, but rather a simple fact of life.  A developer who makes a manager look good is someone who knows how to play the political game; someone who knows when to open their mouth and when to keep it shut; and finally someone who under promises and over delivers, on time, always.

Well, this is possible I guess, but typically a developer who makes their manager that happy isn’t really a developer but more a Manager in training.  Sure it’s easy to quadruple your estimated effort, promise nothing, and meet the insanely high timelines you’ve set out for yourself but let’s face it, a good developer is the ultimate logical individual.  If it is going to take a good developer one month to do something they will tell you it will take a month... we don’t make things up, life is what it is, nothing more nothing less.

Users are probably the easiest to please.  As long as you’re completely honest and deliver what you promise to them on time they’re typically happy.  Although this is no simple task in today’s political nightmare we consider Software Development, keeping our promises are usually fairly easy, but usually lead to CLM’s (Career Limiting Moves for those of you not familiar).  Again, Developers are very logical people so telling the truth usually comes naturally to us, but makes enemies with those who don’t want the truth.

Now, this is by favourite category because it is the most often forgotten.  I was once told by a lead that he was not here to make friends, that business is business and personal lives are personal lives.  Although this true we have this thing called the community who we have to report to as well.  If I constantly make promises that other developers cannot keep, I make enemies even though I may have believed the task possible. 

At the same time, I have to include myself in this category.  That is, I have to consider how many times I’ve sold myself out because I made a promise, and found myself working countless extra hours on my own time just to make that ridiculous deadline that was imposed on me.  The next time you find yourself on the tail end of a 12 hours shift staring at your keyboard wondering why the keys can’t type themselves take a second to ask yourself just how happy you are with yourself... I bet you’ll be pretty irked about it.

Then there is the maintenance factor.  That so often overlooked “extra” cost that I have yet to find a project team who actually cares about it.  The fact of the matter is simple a project team is there to developer a set of features, on time, and on budget... they don’t care if it takes someone two or three times longer than it should to make modifications after the fact, their success is based purely on their delivery date.  Well, I guarantee you that for every line of code you write someone at some point will have to maintain it.

Recently there has been a lot of talk around my work place about ease of adoption on a software project... essentially how easy is it for someone who has never looked at the code to go into TFS, download the code and run it and the unit tests.  I am a firm believer that I should be able to simply open my source control window, and double click on the solution file.  There shouldn’t be any third party items that HAVE to be installed separately, no libraries that need to be referenced out of the GAC, none of that.  In my eyes, if I have to do any more than a simple double click and run the project is a giant failure.  I mean it, at this point I think it would be appropriate to delete all of your code, and go register yourself back in school because you do not deserve to be developing on an enterprise level.

Now here’s why.

1)      Recently I’ve taken on a new project, and it’s taken me two weeks to find all of the third party libraries that I needed, install them, and configure my machine to actually work with this project and the others I have installed.  This is caused mostly by versioning issues, when the new project is expecting a different version of a DLL than I currently require for something else, who should win?  Well, the second I got it working I pulled everything into a library folder and checked it into our source control.  This took me all of about half an hour to accomplish once I got it working, and if I could have saved myself the previous two weeks or non-sense work I would have greatly appreciated it.

2)      Talking with the developers on the same project as I had all the issues with, they had the exact same problems as I had, and actually listed it as one of their biggest headaches. 

3)      The ability to move the code to a build server.  For those of you who have never had the luxury of using a build server I strongly suggest that you go out and download one such as TeamCity by Jetbrains.  It is one of those things that I’ve just started to use and I could not justify stopping.  It makes deployments as easy as copy and paste.  Also, when you’re working with other developers who might not be as anal about running unit tests as we are, you can set up the build server to automatically run them every time code is checked in.  Guess what that means, no more downloading someone else’ broken code when you get latest!

4)      And finally, why not?  For the half an hour that it took me to fix it, it probably would have taken 20 minutes to do it right the first time...

The most common excuse that I’ve heard in regards to this from other projects is we don’t have the time to do it right, so we made it work the only way we knew how to.  At what point did our profession become more about getting it done, and less about getting it done right?  I’m sorry but I don’t know of a single user that would object if I said I was going to spend an extra half an hour on a three month project to make it so that any changes they ever wanted would take half the time to implement... but maybe that’s just me...

I am what I refer to as a developer by birth.  I have long subscribed to the school of thought that there are two types of software developers currently practicing in our industry, there are those like myself who were born with this gift that allows them to just kind of see the way things fit together, and the reason for wanting to put them together.  There are few questions that we do not know the answer to, both professionally and personally, however acting on those answers is entirely different.  This group of developers tends to be highly practical individuals, everything follows a flow of logic and even though we may not know every term from every book on the subject we are practically obsessed with the profession that is we eat, sleep, and breathe everything related to development from a mental standpoint whether it really has anything to do with code or not.

Then there are those developers who are trained to do what they do, either officially through the use of post secondary education institutes, or through back room training found in books and practical experience.  These developers make slightly less sense to me because it seems that everything is over thought, over analyzed, or just plain too much by the book.  These developers are the obsessed type who leave work for the day hoping to read the next book on the subject so they can learn two more terms… even though most of the knowledge they memorize will never be put into place, they know the words to describe what they do not do.

I think the best way to look at the difference between the two is to take a real life situation not related to code in any way.  Let’s take the example of changing a tire on a car.  The second group will read the owner’s manual to find out where the spare tire is stored, and religiously study the book numerous times before they so much as open the trunk to retrieve the tire.  Once all of the possible details are taken into consideration, and everything is mentally mapped out then and only then will they remove the spare tire and begin their task.  If they run into a problem they first go back to the book to ensure that this scenario was not covered, than act on whatever knowledge they can to work through the task at hand.  The first group of developers however, will pull out the tire, jack, and tire iron; jack the car up; and start beating on the tire with the tire iron until it eventually comes lose.  If they run into a problem while changing the tire, it is only a matter of time before their analytical minds discover a solution, no matter how crude or unconventional in nature.

I am not here to say which group is better or worse, I mean I take great pride in belonging to the first group but would never say that someone from the second group is not as good as I am just because they belong to that group… that’s usually something said with proven evidence and countless hours of frustration on my part trying to find the right book for them to read to understand what I am talking about but, I digress.  My problem lies with all of the HR focused idiots who rate me not on the quality of my work, not on my ability to solve impossible tasks, and not by my utter love of being a developer… but rather those who rate me based on the last book that I read, the number of fancy terms I can throw out, and finally how smart I sound as opposed to how smart I am.  It is truly a sad day today as I realize that how smart I am has nothing to do with what I know, but rather how well I am liked to those HR focused dumbasses that seem to hold their rubber sticks over our progression.  I think this is where we have truly failed, by allowing a bunch of rubber stick carrying dictators instruct us on how much we know and my question to them is simple… when was the last time you wrote something?

It was late last night I stumbled upon a question I've never really been able to answer. I love being a developer, I think like a developer, I act like a developer, I am the prototypical developer… but why do I enjoy it? I look at those around my family and they are about as far from technology as you can get. My friends, sure I have some who develop, but even then I question if they feel the same passion of this work that I do. Than this morning I was going through some of Jeff Atwood's blog entries over at Coding Horror, and I came across this quote "Only recommended for those that enjoy pain. Or programmers. I can't always tell the difference."

I think he's right. I am a masochist. Obviously that is not literally what he said, but taken with a grain of salt, he's right. Day after day I get up, and I crave getting stuck on an impossible task. I may be the only person on earth who goes into work, hoping that I get stuck and I cannot get anything done … but the question is why, what could possibly be that thrilling about it? Well, after thinking about it some more I came to the conclusion that it's the challenge. There is nothing better for the self esteem than a good challenge (if you can fix it that is, but so far I've never come across anything that I cannot fix it in some way or another). Could it be that I crave the challenge of my machine attempting to prove it is better than me? Now the main problem with that theory is that if everyone likes a challenge, than why are there so few good developers in the world? Or developers at all? There must be something different about our breed, our species that drive us into our daily tasks.

How about recognition? Could it be that I strive to do what I do so that some other unsuspecting person can be forced to use my little piece of creation? Well I guess artists paint so that others can enjoy their work… wait, no most artists paint to express themselves. Just as a side question though, would an artist still want to express themselves if no one was looking? Back to 'reality' though. Do we do what we do because we enjoy watching people enjoy our works of art? Although that may be part of the reason I'm sure it's not the entire reason, if that where the case I'm sure that our work would concentrate a lot more on the user and less on the back end functionality… after all they say that a user is 75% more likely to like your application if it looks pretty, functioning or not. But maybe I am partially right when I say it is because I want someone to enjoy my masterpiece…

What makes a great piece of art? What makes the masterpiece hanging in your living room? Its creativity, it is that self expression that makes the artist so famous, so powerful in his own circles. Someone once told me that the greatest masterpiece is so perfect that it can be appreciated even if no one ever sets eyes on it. Could that be it? Could it be the high that I get from staring upon a blank screen knowing that I have the power to create whatever world my fingers can type? Through our work there really is no limits, I mean sure I'm still stuck within the physical limitations of the monitor, and I can really only do a limited number of commands in a particular order, but within those infinite borders I have the power to do what I please, I have the power to create my world how I see it, I have the power to control the color of the sun, the size and dimensions of my container, and whether or not the moon even rises… in a sense, I control the limitations I put on myself.

So, there, it's settled. I am both a masochist and a control freak… great combination when you think about it... I need to be in control of everything and I get pleasure from receiving pain. This world is doomed.

This is obviously my first post, so I figure why not start off on a good note and thank those who have helped me to get where I am; more specifically the five samurai and our Sensei. We are not some secret ninja society or anything like that; I am rather referring to that group of close knit friends of mine whose friendship was formed through sweat and blood of our school experiences.

It was my second time going to school, at a small technical institute in Calgary Alberta where I was partaking in an applied Software Engineering Degree. Eight months, two semesters, and 14 courses promised to be a challenge but after all as a software developer that is what I live for. The first day of class we all met, and as one would expect we all had different backgrounds, different skills, and had all faced very different challenges; but after a month none of that seemed to matter anymore, we where for lack of better words a family. We spent the mass majority of our day together in our private lab in the basement of one of Sait's main buildings surrounded by posters preaching the Agile Manifesto, proper lab Etiquette, and a server rack in the front corner. We worked together, we ate together, and we essentially lived our lives together with the exception of the occasional hour here and there spent in our homes passed out with pure exhaustion. Through the watchful eye of our slave master and sensei Grigori our friendships where formed.

Grigori (see his blog at Microsoft here) was by far the best instructor we could have ever wished to have. Although the content of the lessons he taught has for the most part been long forgot, his message rings loud and clear. He taught us the most important message that no other instructor through my four years of formal learning could teach us, simply how to learn whatever it was we needed to know. I know that message sounds almost stupid with simplicity, but it was a message that I've since realized none of my fellow developers seem to know, other than those with years of industry experience. It is a powerful realization to know that anything is possible, and all it takes is some a few minutes on Google and a bit of trial and error.

I would not have traded anything for the time spent, the bloodshed, or the pain felt in those short 8 months at Sait. It has taught me many things I could not have learnt elsewhere; not a day passes where I do not miss it; and I would do it again in a heartbeat. With that being said I would like to thank the five samurai, and our Sensei for a life changing experience, and invite other people to share their experiences, similar or otherwise.