You are young, you are hot. Nobody knows your stuff like you do. You use crufty languages because you can. You can't see the point in any language or CodingConventions
that restrict your freedom, or protect you from yourself.
Then the walls begin to crack. You look outside. You see people cooperating and adopting conventions that prevent problems from occurring. You start to test your code. Not because anyone forces you to, but because you are tired of chasing your own tail.
Someone tells you about the next big thing.
It will revolutionize programming. Jump on the bandwagon now! It sounds exciting and you start to get very excited. Then you pause. You think. "Is it really thought through, this next big thing?
Do I really need to use it right away?" What is the impact. Will it make things more stressful unnecessarily.
Congratulations. You are reaching DeveloperMaturity
Well, that's one angle. Another came up in the form of a counter-example on the CodingConventions
page: the maverick who won't adopt the team style. Programmers - perhaps especially good programmers - are sometimes PrimaDonna
s. They think they don't need to follow the rules.
I've supported a lot of prima donnas in my time. I wouldn't do it again. While I agree with Brooks (?) that some developers are 10x more productive than others, productive includes writing code that works as part of the entire system, not just crafting the bizarre stuff we used to think was good. --RonJeffries
(Not saying whether I've been one.)
I was one of these guys. We prima donnas have a very distinct, keenly artistic ability to build things. I pulled all nighters like they were going out of style. I loathed it when people disagreed with me because I knew I was right. And the ones who acted like they knew technology but didn't really know how to build
stuff with it sent chills up my spine. We always have problems with these guys because they feel threatened by our ability.
I hope I've achieve DeveloperMaturity
;-). Now, I see everything as tools. I use them to get a job done. Whether it's patterns or COM or Java or C++ or an IDE or even something as physical as a computer, I see them all as things that help me build stuff. If I'm faced with upgrading my hammer to the hammer++, I ask myself what the real value of doing that is. And I'm always, always
skeptical of buying and integrating pre-built components because it's always a reality that you run into stuff that won't work the way you need it to, and you get a sixth sense for when you should abstract yourself to something, or completely couple yourself to it. This sense, in and of itself, is a tool.
I like the "natural process" quality of the description at the top. No one's waving maturity goals in your face, hopefully. There's a big difference between reaching developer maturity and reaching for
developer maturity. Planning for maturity is like planning for grey hair. Silly, isn't it? -- WaldenMathews
I need immature programmers. They know technologies I don't know. They remember things I don't remember. Just by not knowing what is supposed to be too difficult to do, they often achieve things that I would not try.
Immature programmers need me. I know that the most important question to ask is "Why are we doing this?" I know that blazing a trail through the jungle is neither the first, nor the last step in building a road.
Well, nobody came out and said maturity is good, and here you are leading with a counter-example already. Nice work. Come to think of it, maturity is not often appreciated except by the mature. Although it's easy for them (immature ones) to try things that you wouldn't, isn't that a trick you might yet teach yourself? -- WaldenMathews (having just built a fireplace, of all things)
Hence the need for apprenticeship. These days, apprenticeship is not a valued career path, either for the prospective apprentice or the prospective artisan. For some reason, we assume learning must be either a classroom activity or a trial-and-error one. One-on-one teaching and learning is not as common as it perhaps should be.