Software Developer or Manager?

Since I have entered the workforce I have been saying the same thing: “there are the people that know what they are doing, and there are the managers.” I am not sure about other industries, but in the software development industry this the case 99.9% of the time. I know what you are thinking. “Developers are geeks and they can't look someone straight in the eyes, that's why you need managers!” Yes, sometimes that is the case and sometimes it is not. Like most of you, I have encountered (personally or through reading previous code) many people who are not managers, but do not know what they are doing either. So that threw my whole theory off. But that is OK, because after thinking about it, I came up with a better one: “there are the people that do the work, and there are the managers.”

Where am I going with all this? I want to focus more on the category of the people that do the work. Because inside this category there are sub categories: there are the people that know what they are doing and the people that do not know what they are doing. There are the people that keep quiet and do as they are told and people that refuse to have someone think for them and actually use their own brain. I am sure there are millions of other sub categories, but what makes a developer a good developer? In which sub category do you have to fall in? To start with, one sub category is not enough; you need to be in multiple sub categories.

As I write this I want to make sure you guys understand that I do not want to make distinctions between consultants, contractors, or just plain old full time developers. They are all developers. I love it when a customer starts describing what they want and goes on and on and when they are finished they described a program that reads their mind to do what they want without using a keyboard, mouse or anything, and if they made a mistake it goes back in time and fixes the mistake and then makes them millionaires. Right then and there is when the great developer comes in, jumps into the conversation and questions the customer in such a way that leads him or her to realize they have gone way past their initial objective.

I am not saying you have to ask all these subliminal questions, sometimes being direct and straight to the point is OK and the best way to go. Sometimes customers know what they want, but do not know how to explain it. For example, the first question the developer should ask himself is what is the objective of this project? And if the customer has not mentioned it, it is the job and responsibility of the developer to ask him or her. Sometimes customers asks for a sales report and when they are finished they have created this monstrous report that has nothing to do with their initial need. Always go back to the objective and the need of the client.

It is the job of the developer to care for the best interest of the customer. If they want to do something to the application then look ahead of the short term impact. Is it worth spending all this time and money when the application is going to be rewritten next month? Are we adding that feature in the correct place or just adding more garbage? Is the feature within the domain of the application? In other words, do not act because you were told to do so, think about it first and provide your feedback.

No matter how you think and what you told the customer, though, he has the last word. It is his application, his money, and his time. If he wants it to fly then you better make it fly.

Everything mentioned above is worthless if the developer does not know how to write good code. Usually when this happens I say he BS'ed himself in and most likely he was supposed to be in the manager's category. I found a couple of these people throughout my career and I am sure I will find many more. There is not much to say here other than learn your code. Knowing how to use an IDE to create a program is not enough. The developer needs to know more about the internals of the chosen environment.

Do you want to be a great developer? Then do not just do as you are told. Use your brain and speak out your opinions to help drive the project forward in what you believe is the right direction.