|Perl: the Markov chain saw|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
Good questions and interesting points.
To counter #1, keep in mind that the evolution of the Internet has made it possible to contract and work with developers in many countries. For example, a buddy of mine has sucessfully started a home based business working on contracts from clients based across the U.S. Heck, even my few clients are distributed.
While this adds to the administration angle, careful management of the project helps reduce the risk for problems. As long as everyone is clear on the expectation and there are well documented tasks and deliverables, the process itself goes quite smoothly.
To counter #2: that is an issue in any language and/or environment. There are C++ "experts" who zealously believe their personal ideas are paramount. Similarly, you will find, with little effort, VB/VBScript developers with the same attitudes. Even in my baliwick (Delphi), there are hard nosed people who will not open their minds to an alternate approach.
It's up to the project lead to ensure that all resources are following the expected standards. One way to do that is to (loosely) tie compensation to behavior. Code reviews should be part of the approval/acceptance process. "It works" is not good enough. It must work, be clear, and meet all expected benchmarks--including documentation, standards adherence, and so on.
That said, standards must not be straight-jackets. They must be flexible enough to evolve and to adapt for new information and/or ideas. Do not dictate trivial elements (number of spaces to indent, brace cuddling, and so on). Standardize the important stuff: consistency, a design for reuse, documentation, security, implemention direction, corner-case unit testing, testing requirements, and so on. Programmers will resist changes to their personal coding style, but the good ones will adapt to guidelines designed to make their code better.
There is a creative element in programming and a good manager will seek out individuals that know when to think on either side of the box.
Personally, I would ask your manager if he really wants "sheep" working for him. Personally, I wouldn't. I'm not afraid of having my ideas questioned; I encourage discussion, because software is rarely designed well in a vacuum. I am afraid of being slavishly followed, for I know that I don't know everything and I'm always willing to learn something new, even from an intern working on his first gig.
These really are issues that should be brought up during the initial interview process. If he cannot get someone to open up and honestly admit whether or not they can work with his requirements, then he shouldn't be hiring them in the first place.
Programmers aren't code monkeys and the wise manager will look for those who tackle all problems creatively, even the mundane ones such as following coding standards or keeping the schedule/budget in mind. (Not trying to say that standards are trivial, but that they're often used to bludgeon submission, which is wrong in my book. Standards are vital to a success development organization. Documented standards are even more so.)
Your next step, my friend, is to see whether or not your manager has an open enough mind to explore the possibilities with you. His response to that will suggest your next course of action, e.g. can you work within the constraints he's laid out?
(I know you you already know this; it's just a button with me because I've worked with good managers and I've had bad ones. The ones I've personally respected the most were willing to give my ideas a fair hearing and were willing to back down when they were wrong. Many stories there, but this post is too long as it is. *grin*)
Update: Added the following for a minor bit of credibility:
P.S. This isn't just the point of view of a JAPH or an "in-the-trenches" programmer. As (briefly) outlined in my home node, I have been a programmer, a tech writer, a QA tester, a support tech, a product manager, a consultant, and a team lead. I have seen many management styles and worked with many programmers. The styles that work and the people I respect are those that that understand, at least implicitly, the principles outlined in the Software Maturity Model.
P.P.S. If anyone knows of a Level 5 organization in the Seattle area looking for help (or one willing to with with a Seattle-based telecommuter), please let me know privately. *grin*