I had an interesting discussion at work today that I thought I would share as I would appreciate your feedback.
For a particular problem I was attempting to solve, I chose a Hash of Hashes as my data structure. The data structure itself was generated in a subroutine and returned to the calling routine as a hash reference where it was used successfully. Code was not really obfuscated in any way, quite clean and did not resort to rocket science.
I showed the code to a co-worker and they made a rather bizarre statement: "Yep, that's pretty cool but if anyone else has to maintain your code they're screwed". I was rather miffed by this and asked him to elaborate further. Turns out that said co-worker did not understand HoH's or any other "complicated" (his words) data structure for that matter.
So that got me thinking. If we follow my co-workers logic, no code should contain any "grown-up" Perl concept until the whole team is comfortable with that concept. In other words you should "code down" to the least experienced coder on your team. If you don't, the code is perceived as un-maintainable.
So what do you think? Where/when is the line drawn?
When coding, do you assume a certain level of expertise of the lucky so-an-so who has to maintain the code? Do you simplify your code because the "next guy" might not fully understand map or perhaps doesn't yet grasp the concept of references? Do you code-on regardless knowing that there's always perldoc or a copy of The Camel begging to be read if the less experienced members of the team get confused?
Perhaps there's a happy medium - thoughts anyone?
-- vek --
For a particular problem I was attempting to solve, I chose a Hash of Hashes as my data structure. The data structure itself was generated in a subroutine and returned to the calling routine as a hash reference where it was used successfully. Code was not really obfuscated in any way, quite clean and did not resort to rocket science.
I showed the code to a co-worker and they made a rather bizarre statement: "Yep, that's pretty cool but if anyone else has to maintain your code they're screwed". I was rather miffed by this and asked him to elaborate further. Turns out that said co-worker did not understand HoH's or any other "complicated" (his words) data structure for that matter.
So that got me thinking. If we follow my co-workers logic, no code should contain any "grown-up" Perl concept until the whole team is comfortable with that concept. In other words you should "code down" to the least experienced coder on your team. If you don't, the code is perceived as un-maintainable.
So what do you think? Where/when is the line drawn?
When coding, do you assume a certain level of expertise of the lucky so-an-so who has to maintain the code? Do you simplify your code because the "next guy" might not fully understand map or perhaps doesn't yet grasp the concept of references? Do you code-on regardless knowing that there's always perldoc or a copy of The Camel begging to be read if the less experienced members of the team get confused?
Perhaps there's a happy medium - thoughts anyone?
-- vek --
Back to
Meditations