This is akin to saying we don't need officers in a war, the soldiers and the NCOs know their shit, just leave them alone.
IT manager's responsibilities include:
- Monitoring whether his department meets the BUSINESS objectives set to it
- Measuring and imporoving the ROI of his projects, technologies and platforms
- Making sure his department is a good place to work
I.e. a good manager is MUCH more than just your gofer. No matter how much you know about your 'shit', as you put it so charmingly.
Hate to knock your penmanship, but 'depricated' is spelt differently. It is really quite embarassing when you try to pass on wisdom and can't even spell a keyword!
What? Logging the feature that makes Java more robust and attractive? Well, if that was the only thing holding you back from using Java, all you had to do was write the 17 line Logger class.
Of Elliotte's laundry list, only the IO and threads issues really resonate with me. But I would like to add my own:
All Java-platform packages shall be specified as interfaces, and come with reference implementations (set of concrete classes). The reference implementations are pluggable.
Many packages are already implemented that way (JDBC and JDBC drivers, servlet API and server containers, etc). Restructuring UI, logging, messaging, etc, to follow the same approach would be useful, IMO.
After 12+ years of going through similar situations (often being the most productive developer, and taking delivery way too seriously), there are two things I would do:
i/ Structure the project such that your part clearly depends on deliveries from other people. Ensure it is clear you can not proceed further without the other developer's deliverables. This first part, you *must* do, otherwise who's stupid here?
ii/ Now, only bother with the second part if you are willing to try to lead the team, as opposed to just complaining. The essence of these early stages of leadership is being helpful and understanding. People like to be led by helpful and nice individuals, and resent the opposite. Come to work earlier than others, leave later. Practice the Pair Programming techique. Try to come up with ways of helping people to deliver - daily builds, write interfaces, write simple 'smokescreen' tests that will be run after daily builds. Ask people to sit in on code reviews of your code. Look for tools to simplify the tasks of the group. Encourage, cheer people up, give helpful answers, avoid putting people down.
After some time of practicing leadership, you will see that you are spending A LOT of your time away from your desk, talking to people. You will also see that the team will break down into two groups: those who want the project to succeed, and are willing to work for it, and those who don't. Don't waste your time with the latter group, and focus on the work with the first group.
And, finally, after a year or two of doing this, you can sit down and ask youself: do I really enjoy being a leader? Do I want to go into management, perhaps take some courses in Project Management and People Management? Only at these latter stages do you get to make major decisions. Or do I prefer technical work?
Slashdot Mirror
This is akin to saying we don't need officers in a war, the soldiers and the NCOs know their shit, just leave them alone. IT manager's responsibilities include: - Monitoring whether his department meets the BUSINESS objectives set to it - Measuring and imporoving the ROI of his projects, technologies and platforms - Making sure his department is a good place to work I.e. a good manager is MUCH more than just your gofer. No matter how much you know about your 'shit', as you put it so charmingly.
Hate to knock your penmanship, but 'depricated' is spelt differently. It is really quite embarassing when you try to pass on wisdom and can't even spell a keyword!
What? Logging the feature that makes Java more robust and attractive? Well, if that was the only thing holding you back from using Java, all you had to do was write the 17 line Logger class.
Of Elliotte's laundry list, only the IO and threads issues really resonate with me. But I would like to add my own:
All Java-platform packages shall be specified as interfaces, and come with reference implementations (set of concrete classes). The reference implementations are pluggable.
Many packages are already implemented that way (JDBC and JDBC drivers, servlet API and server containers, etc). Restructuring UI, logging, messaging, etc, to follow the same approach would be useful, IMO.
i/ Structure the project such that your part clearly depends on deliveries from other people. Ensure it is clear you can not proceed further without the other developer's deliverables. This first part, you *must* do, otherwise who's stupid here?
ii/ Now, only bother with the second part if you are willing to try to lead the team, as opposed to just complaining. The essence of these early stages of leadership is being helpful and understanding. People like to be led by helpful and nice individuals, and resent the opposite. Come to work earlier than others, leave later. Practice the Pair Programming techique. Try to come up with ways of helping people to deliver - daily builds, write interfaces, write simple 'smokescreen' tests that will be run after daily builds. Ask people to sit in on code reviews of your code. Look for tools to simplify the tasks of the group. Encourage, cheer people up, give helpful answers, avoid putting people down.
After some time of practicing leadership, you will see that you are spending A LOT of your time away from your desk, talking to people. You will also see that the team will break down into two groups: those who want the project to succeed, and are willing to work for it, and those who don't. Don't waste your time with the latter group, and focus on the work with the first group.
And, finally, after a year or two of doing this, you can sit down and ask youself: do I really enjoy being a leader? Do I want to go into management, perhaps take some courses in Project Management and People Management? Only at these latter stages do you get to make major decisions. Or do I prefer technical work?
Good luck in your journey!