|laziness, impatience, and hubris|
Re: Enterprise development: Its ok to say No!by crouchingpenguin (Priest)
|on Dec 16, 2003 at 13:11 UTC||Need Help??|
I think what you are describing fundamentally breaks down to different levels of skill sets and experience.
Your JGID programmer is usually the greener programmer (notice I didn't say younger) who wants to jump into the project to get his/her hands dirty and gain experience. This isn't a bad characteristic, it just needs to be carefully watched and cultivated. Sometimes this type of programmer is extremely handy with finishing details or peripheral components that need to be completed quickly. With a little guidance from those with more experience and skill (journeymen and craftsmen), this person will eventually start seeing the larger picture.
Your "happy customer programmer" to me reminds me of myself not long ago. I was all about delivering solutions that could later be built on top of. I don't think this type of programmer is lacking due to this drive. In fact, if you look at the building blocks of a lot of frameworks, you will see their origins in this type of development. Of course, they always tend to need heavy refactoring due to some of the broad design oversights. But that is where the "profi" programmer comes in.
Your "profi" programmer is definitely the master of the guild. He is most likely heading the team, overseeing the design and delegation of the project's subsystems. I don't think your definition covers all aspects of what I would consider to be this type of person. Some can easily interface with management types and further the development teams needs. Some simply butt heads with anyone outside their group or control. This broad range is always due to the experience given to them as they moved up the chain from apprenticeship to master craftsman. It is also this person who has the most influence on the greener programmers beneath him/her.
Every team is different, just as every person is. It is handy to be able to quickly identify a situation or team so that you can normalize yourself quickly. But I think you lose a lot if you try to be too rigid in your definitions. Believe me, even your "profi" master craftsmen benefits from those greener apprentice programmers. How many times have you gained from simply explaining to someone how to get something done, while also at the same time imparted your wisdom on the why's and how's? Or how about that fresh perspective from a new pair of eyes?
I guess my point is, give everyone a fair chance to contribute. You will be surpised when you learn things from those less experienced than you.
"Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic."