Re^6: improving the aesthetics of perl code

And if I can teach my senior programmers to write clearly in the first place, 90% of the time I'll be able to let my junior coder just fix things. 10% of the time, he'll have to call in someone more senior to explain things ...

The tricky bit is determining whether the junior coder can recognise the 10% he can't fix himself.

Hugo

Comment on Re^6: improving the aesthetics of perl code

Replies are listed 'Best First'.
Re^7: improving the aesthetics of perl code by Ytrew (Pilgrim) on Jan 26, 2005 at 07:36 UTC
The tricky bit is determining whether the junior coder can recognise the 10% he can't fix himself. Actually, the hardest task is probably correctly assigning the junior programmer to tasks which he's likely to be able to accomplish, and watching him carefully when it doubt. :-) But this job can be made easier by documentation. Part of the documentation job that the senior programmers need to do is clearly explain where that complicated 10% of the codebase lies, and what level audience each section of it was written for. Good documentation and testing techniques should also tie business requirements to specific sections of the codebase, if only for verification purposes. ("Yes, the billing section works!"). The major and minor business premises and code specific assumptions should also be documented in case of change. From that documentation, it's much easier to see who can work on which sections of code. First of all, if the code was written for a more advanced background than a programmer has, he doesn't get assigned to it. If the new business requirements don't challenge any of the assumptions, then the new code can be slotted directly in for the old. If the novice can write the code, then he can do the maintenance. If some of the lesser assumptions of the code have changed, minor re-design may be needed. With some guidance and direction from a design architect, the problem can probably be delegated to an intermediate progammer. If some of the major assumptions about the code have changed, then it will probably take some serious design work on the part of the senior architect, and possibly be delegated to the senior programmers to work on. If all of the major assumptions about the code have changed, it may be time to write a new codebase. ;-) -- Ytrew	[reply]

Replies are listed 'Best First'.

Re^7: improving the aesthetics of perl code
by Ytrew (Pilgrim) on Jan 26, 2005 at 07:36 UTC

The tricky bit is determining whether the junior coder can recognise the 10% he can't fix himself.

Actually, the hardest task is probably correctly assigning the junior programmer to tasks which he's likely to be able to accomplish, and watching him carefully when it doubt. :-)

But this job can be made easier by documentation. Part of the documentation job that the senior programmers need to do is clearly explain where that complicated 10% of the codebase lies, and what level audience each section of it was written for. Good documentation and testing techniques should also tie business requirements to specific sections of the codebase, if only for verification purposes. ("Yes, the billing section works!"). The major and minor business premises and code specific assumptions should also be documented in case of change.

From that documentation, it's much easier to see who can work on which sections of code. First of all, if the code was written for a more advanced background than a programmer has, he doesn't get assigned to it.

If the new business requirements don't challenge any of the assumptions, then the new code can be slotted directly in for the old. If the novice can write the code, then he can do the maintenance.

If some of the lesser assumptions of the code have changed, minor re-design may be needed. With some guidance and direction from a design architect, the problem can probably be delegated to an intermediate progammer.

If some of the major assumptions about the code have changed, then it will probably take some serious design work on the part of the senior architect, and possibly be delegated to the senior programmers to work on.

If all of the major assumptions about the code have changed, it may be time to write a new codebase. ;-)

--
Ytrew

[reply]