serving many masters

came across an interesting blog post on commenting/documenting code today... i've seen many of the things mentioned before but at the end i'm always left with the feeling "why should i?"... not because i don't think i should bother, i know better, but because these tips never seem to address the key inertial speed bump of "what's my motivation?"...

what one really needs to be asking oneself, however, is "who am i writing code for?"... is it for me? my employer? the end user, perhaps?...

i'll ask another question - "who is going to see it?"... i'm going to see my own code, obviously, but so are other coders - specifically the people working with me on the project now and the people who will be working on it in the future... they are the audience of my code, they are the users of my functions, they are the consumers of my classes... when i write code, i'm writing it for other coders... with that in mind of course i'd try to write the best, most elegant, and meaningfully documented code i can...

it may seem strange that i'm considering my fellow coders as one of the masters i serve as a professional software developer or more specifically why them and not some other master... well, being a coder means mastering the art of serving many masters and they are the ones most directly impacted by the form and nature of my code...

end users, on the other hand, are most directly impacted by the user interface i design - so i design user interfaces for end users... likewise with employers (or direct supervisors, at any rate), they're most directly impacted by deadlines so i try to meet deadlines for them...

and for myself? i solve problems... i solve problems for the sense of accomplishment, of course, but also to make my life easier/better... and i don't just mean solving problems with the product (though that's part of it)... solving problems with the nature of my code means other coders can use it more easily... if they can use it more easily then then don't have to ask me as many questions and i can spend more time either being productive or goofing off... it also means they're less likely to use my code incorrectly and thereby introduce bugs which create more work and complexity for everyone down the line...

solving a problem that affects my productivity of course means that i can better meet my deadlines and that makes my employers happy - and it's far better to have employers that are happy you're meeting a deadline than employers that are unhappy because you are missing a deadline... that kind of stress sucks...

finally, solving a problem with the user interface makes the user experience go more smoothly... if the user experience goes more smoothly then the user is more apt to use the product the way it was intended to used... if the end user is less likely to use the product in unintended ways then they're less likely to encounter unexpected behaviour which would be reported to my employers to be fixed which leads to cluttering the next to-do list, making more work for me and my fellow coders, making the product more complex which inevitably means more questions asked of me, and making the deadlines harder to achieve which makes the employer less happy...

in the 7 years i've been programming professionally that's the realization i've come to... i need to design UI for users, meet deadlines for employers, code for other coders, and solve problems for me...