I have a new teammate. He's recently out of college and reminds me of me at that point in my life. He's secure in what he knows, willing to challenge the established practices, respectful of the "elders" on the team, etc. I miss the times when I didn't worry about the other dynamics of software development, when the code itself was the focus of the effort and the reward for a job well done.
So what is it that changed things for me? Some of it I would classify as maturing, seeing that there is more than code to having a successful product. Good code is easier to maintain and it is still a joy to see. But not everyone has the same definition of good. Good code simply works; both in that it is simple and that it does just what it should. Good code may also be judged for lucidity, elegance, brevity or even against "coding standards" -- someone's idea of a quantifiable measure of good. I've started to add: Good code is maintainable code, well documented and testable. Unfortunately, that starts to become a balancing act with elegance and brevity as not everyone is able to write or understand code at the same level. In this case, the maturing aspect is the inclusion of others in the goal.
But, it's more than that. Much of it is that I'm growing tired of the fight. I'm weary from nearly arguing about quality and costs with management that does not want to hear anything other than what is it going to cost the customer on contract. There's no buy-in to producing good code. It seems that the bean-counter definition that drives decision making is: Good code is shipped code. That's it, nothing else would seem to matter. I've put together justifications about technology upgrades to bring codebases into today's world (much of those are over a decade old!) The cost of being unable to attract or retain good developers doesn't seem to matter. Yet we're expected to be judged on quality, meeting customer expectations and other "Good Code" (and important outcomes) metrics. Apparently we're expected to do this for free or on someone elses' dime.
It would be nice to get back to the simple definitions, to being the happy coder truly enraptured with my job. Where I could have simple pride in the completion of the job, not, "if you qualify it thusly, make this exception, take that into consideration... Yeah, I could be proud if it!" Yet, somehow, I still enjoy the work. It's still a thrill to see the software through the customer's eyes. I really love it when on first demo they pick at little things because it means we've truly impressed them and nailed the big stuff!
So, Is it that I'm Aged or Jaded?
My answer: Yes.
3 comments:
Not necessarily "bean-counter," which denotes accountants. We are also constrained by management. All accountants can do is work with what they are given, the same as coders.
Thank you, that is fair enough and a perspective that should be respected.
That reminds me of an article I read, wish I had the link, about what it takes to run a software company. The summary of which is that management's job is to provide the illusion of simplicity -- that it is only the code that matters -- so that the developers are free to concentrate on code instead of the individually-overwhelming task of running the company. It is likely an inaccurate association to developers that "bean-counter" has become a pseudonym for the tight grip of management that says "no" to the majority of requests for a reason which commonly distills down to a statement of "we can't afford to do that" whether it is a direct cash reason or a broader resource problem. Since this is my perspective, however, I'm going to leave this article as-is, but I will try to be more accurate in the future. It is as unfair to use sweeping generalizations against other disciplines as it is to say that we're "just coders who could live in a cave with a computer and pizza and be happy."
I wasn't suggesting a change. Merely pointing out something that stuck out to me. :)
Post a Comment