While we would all like to work with the Fowlers and Blochs of the world, there are not enough of them to go around. Which means either changing career, or be accepting that there are less talented people in your industry, and by a cruel twist of fate you may well work with one of them.
With this in mind, what should one do ? The first thing is to not instantly assume people will understand what is going on from your code. Some documentation, is a good, thing, even if it is within the code itself.
Better yet tests your fellow developers can run, unit and integration tests are ideal for this, they not only show that the code works - they show HOW it works.
Secondly try not to use the most esoteric aspects of the language, they will only confuse and befuddle your coworkers, the most readable solution is the best and usually the simplest.
This will always be relative, the stupidest member of a team writing control code for a plane or power station is most likely to be _less_ stupid that the brightest member of a website.
With this in mind, what should one do ? The first thing is to not instantly assume people will understand what is going on from your code. Some documentation, is a good, thing, even if it is within the code itself.
Better yet tests your fellow developers can run, unit and integration tests are ideal for this, they not only show that the code works - they show HOW it works.
Secondly try not to use the most esoteric aspects of the language, they will only confuse and befuddle your coworkers, the most readable solution is the best and usually the simplest.
This will always be relative, the stupidest member of a team writing control code for a plane or power station is most likely to be _less_ stupid that the brightest member of a website.
0 Comments:
<< Home