Rampant CodeCraft

I used to be Projects over People. The work was all that mattered. Woe to those who came between me and delivering the highest value to the user via the cleverest user interface and highest quality of code I knew how to produce. Reminds me of a Robert E. Howard quote, but we will get to that in a bit.
Why? Considering the amount of time I’ve thought about it, you would think I would have a better answer. But alas all I have are these: The illusion of a meritocracy maybe? A meritocracy that, because of it’s existence in our schooling, I thought existed everywhere. If I wrote the best software, everyone would (somehow) know and I would be respected. I know you just chuckled. I didn’t hear it, but I still know you did. That’s ok, it was naive of me and warrants a good laugh.
Maybe it was a solution to a flaw I saw in using clients to measure project success: it’s not very scientific. The phrase “It’s not what you know but who you know” applies here and reeks of corruption that I despise. Which brings up another Howard quote:

“Civilized men are more discourteous than savages because they know they can be impolite without having their skulls split, as a general thing.”
               –Robert E. Howard (The Tower of the Elephant)

I saw clients evaluating the success of a project as a fail because at the time I thought it mattered that they understand the internal workings, you know, all the crap I had to go through and all the ‘brilliance’ I showed on the inside of the app. They can’t understand it, and it doesn’t matter if they do. I also didn’t see them as capable of giving honest feedback because of the naturally adversarial relationship that occurs between one paying for work and one delivering the work. But the relationship between these two need not be adversarial.
Maybe the true reason: it is in my nature, it’s in your nature, it’s in our nature to strive to be the best and people are competition, or just get in the way. I need a machine, an IDE and a compiler to make users lives better. Go away and let me get to saving the world. ;)
This Projects-over-People philosophy almost cost me one of the most valued relationships I have now. It was my manager at the time that made me realize Projects will come and go, but the relationships you make with the People you meet may last a lifetime. He is a gentle man and his gentleness is something I appreciated while working with him and began to emulate. So after the longest and most challenging project I’ve ever had in my short career, one that I alone followed to it’s full end, sacrificing everything else in my life, protecting it and defending it, I flipped. I became People over Projects. On my next project I nurtured the relationships with the client-users, managers and developers first and foremost, to the detriment of the codebase.
That was some time ago and the codebase that resulted has still not shipped. For my sake, the sake of the people that would have to use it, and the sake of the developers that would have to maintain it, I hope it never does. My change in philosophy was not the entire reason the project failed nor was it the determining factor, but I would be lying to myself to say it didn’t contribute.
What I see now is that one or the other is an insufficient solution. If you deliver a great app but all you made were enemies, you have failed because very quickly you will find there is no one that wants to work with you or wants you working for them. If you make a bunch of new friends but didn’t enforce coding practices you know are necessary to ensure the quality of the application and therefore develop a non-maintainable application, you have also failed because you didn’t do your job which was to deliver a functional application that can afford change. Both are needed.
A successful career is built by delivering a great application to the users, while leading your team, not by instruction or condescension but by example.  Prove to the team why the methodologies you use are worth the extra work. If you can’t prove that your methodologies are worth it, then you need to reconsider your chosen methodologies or practice to increase your skill in using them. This builds trust between you and the developers you work with in a positive way. An adversarial relationship with the client can be avoided with an agile project approach that delivers an application in pieces that is a good fit for the user as the target moves into focus. The client gets a front row seat to the addition and modification of functionality and trust and confidence is built as they watch you encounter and overcome obstacles along the way (especially the obstacles the client creates themselves as they refine the design).
Being Projects over People ignores the fact that no large software system can be built by one person in a short amount of time, which is not practical. Being People over Projects requires one to tame their individual desires of conquest for the perceived betterment of the individual egos in the group, which is not natural and benefits no one. 

“Let me live deep while I live; let me know the rich juices of red meat and stinging wine my palate, the hot embrace of arms, the mad exultation of battle when the blue blades flame and crimson, and I am content.

Let teachers and philosophers brood over questions of reality and illusion. I know this: if life is illusion, then I am no less an illusion, and being thus, the illusion is real to me. I live, I burn with life, I love, I slay, and am content.”
               –Robert E. Howard (Queen of the Black Coast)

The above quote, I thought, supported my initial Projects-over-People philosophy but I’ve found in practice that living your professional life to the fullest cannot be sustained without a balance of conquest and cooperation. The quote “It’s not what you know but who you know” is emphasizing the reality that without people, one cannot become successful. For the first part you must be great at what you do. But being only this will leave you alone to appreciate yourself. For the second part you must include, cooperate, and treat kindly the people you work and with and for. But being only this will provide you with the illusion of success that will soon evaporate once it is seen that you are not as good at your job as the illusion has led people to believe. Done together you practice and hone your craft to deliver the greatest applications you can while cultivating relationships with people that will spread your software’s success, and appreciation for your skill as well what a pleasure that it was to work with you.
Be good at what you do, and be good to the people around you so that you may have more opportunities to be successful.