Re (tilly) 2: My code and your stupidity don't mix!

While I would cheerfully bet your paycheck that you have been in software longer than I have, I think there is a bit of a 2-way street between keeping to what other people know, and teaching them more about the tool.

If you do code reviews and 40% of developers find your code obscure, then possibly you do need to work on making your code clearer. OTOH possibly you need to work on educating them so that they understand your code, and work more effectively themselves. I think it is good for a company to decide that its standards for new employees include a learning curve, and that learning curve shall include mastering a set of features which may or may not be in wide use elsewhere.

I think that is particularly true with a language like Perl where most people who claim on their resume to know it actually know it very poorly.

Note that I am not saying that all problems are to be solved by teaching your fellow co-workers. There is a balance to be reached between using features that make you personally more productive, and keeping to what is generally known.

Comment on Re (tilly) 2: My code and your stupidity don't mix!

Replies are listed 'Best First'.
Re: Re (tilly) 2: My code and your stupidity don't mix! by dws (Chancellor) on Dec 06, 2001 at 22:24 UTC
If you do code reviews and 40% of developers find your code obscure, then possibly you do need to work on making your code clearer. OTOH possibly you need to work on educating them so that they understand your code, and work more effectively themselves. There's a sampling trap here that I've seen many organizations fall prey to, which is to have the top 50% of developers be the principal (or only!) participants in code reviews. Big mistake if you're vetting code for maintainability. The top half may have no problems with idioms that will stump others. I've seen this happen with Java and C++, as well as Perl.	[reply]
Re (tilly) 4: My code and your stupidity don't mix! by tilly (Archbishop) on Dec 06, 2001 at 23:19 UTC
Interesting point. However I think that good developers who are on the lookout for it can flag constructs which they understand but they think others might not. Furthermore good developers are more apt to notice the maintainance implications of seemingly innocuous constructs. Therefore if you have good developers who are concious of these points, and who have exposure to what others know (eg through assisting in training, answering questions, etc), I think they can take into account the bottom half in considering maintainability for code reviews. But still I have to wonder at the value of doing a modified usability study to find maintainability implications. Take code from programmer A, hand it to programmer B, and have experienced observer C take notes as B talks through trying to figure out A's code... UPDATE Inserted an important "not" that Corion caught.	[reply]