The Good Developer, or: How I Learned to Stop Worrying and Love my Code
As a CTO, one of my greatest responsibilities is to find and hire the talent needed to move my company’s technology initiatives forward. All managers that have experienced any significant success at all will tell you that “good” people ultimately make or break your management career. Since we all know this, the question is “What makes someone good?”
Let’s get more specific and talk about software development. What makes a “good” developer “good”? I always ask this question of anyone applying for a software engineering position in my organization. I get all kinds of answers. As you would expect, they all have sound technical themes that go on about writing “good” code, or writing “efficient” code, or producing code with “very few” bugs. The more advanced candidates emphasize specific platforms or architectural knowledge. Indirectly, what I am really trying to ascertain from the candidates is what they think makes them professionally valuable. Logically, they all tell me something that has to do with development, usually code or design related. I never get the answer that I am looking for. That is to be expected since it’s a trick question. “Good” is of course a relative term, anchored in biased experience. To really compete in the current marketplace, the great majority of developers need to change the way they think, perceive their value to corporations, write code, and manage their careers.
In for-profit corporate America, a “good” developer is someone that adds value to the revenue generation process or revenue retention process. Software code, technology, and architecture are all barriers to adding that value, and your job is to overcome those barriers. Think about it. In a perfect corporate world, a company would make and defend its revenues by producing and servicing nothing at all. Profits would soar and expenses would plummet. A “good” developer is someone whose employment has a net positive effect on the corporate bottom line. The easier it is to make that connection, the more valuable you are perceived to be. I am not diluting the value of strong software development fundamentals. Command of fundamentals is necessary for success in any discipline. Without fundamentals you are not even in the game, and you just don’t know it. I expect a senior software engineer to have mastered design patterns, for example. Differentiating yourself on strong fundamentals will become more difficult in the future. What you are really competing on is price alone. Note: price is your salary.
Again, code is in the way. Technology is in the way. You exist to remove the obstacles. This is one example where you are literally fighting fire with fire, using technology to remove technical barriers. When you love technology, you love the barrier. Train yourself to learn to love the result, not the method that produces the result. The day that developing software produces revenues, the method will be more important. Until that happens, realize that selling software produces revenues, thus the result of development is where the value lies. Great code in projects that never complete is as valuable as great code in products that do not sell.
Products matter, sales matter, and most importantly customers matter. When you understand this then you understand that differentiating yourself is about building career value, not about making a high salary being the equivalent of a high-tech handy-man. Competing on software fundamentals alone is tough; competing with software fundamentals plus demonstrated data networking experience, or RDMS experience, is better. Competing on software fundamentals plus business domain knowledge is best because a “better” developer with little business domain knowledge will have a hard time competing with an “average” developer full of business domain knowledge. The latter has to ask fewer questions and is less impacted by bad or delayed answers, thus she stops and starts less. A good SDLC process will keep the average developer’s code “good enough.” What is “good enough” code: code that has a cost structure that meets the needs of the product’s revenue generating sales life.
Technology platforms are the tides that will continue to raise all boats. Software development life cycle advancements and technology platforms like .Net and J2EE seek to lower the technical skill set bar for productivity, not to raise it. In other words, they seek to make the average developer more productive, marginalizing the traditional “good” developers. You should seek to understand why this is a good thing. When you know that this is a good thing, and you have positioned yourself such that the effect of these dynamics on your career is positive, then you will have made the transition to the new age because you will no longer be a developer of software. You will be a developer of value.