in reply to Re^2: Programming *is* much more than "just writing code".
in thread Programming *is* much more than "just writing code".

It's not often that I consent to inherit someone else's problem code, but when I do there's an economic reality to be considered. If the client's cap is at four hours of labor (billed), I'm not going to spend 40 hours writing tests. I don't provide charity to commercial enterprises aside from that extorted by the IRS to be doled out as corporate welfare.

I always comment non-obvious design decisions, by the way. Those are comments that might actually be useful to the competent maintenance programmer who's been tasked with refactoring my code. I frequently include URI's for in-depth discussions of the algorithms that might not be known to programmers at large. If I've optimized the code, I'll frequently include benchmark results to show that the code has been optimized at the right point in the development cycle. But I'm not going to take on the role of educator to explain to a maintenance programmer why I've chosen to implement a database connection as a singleton, or memoized a recursive method that can benefit from it. He already knows why, or can do his own homework, or can take the job he's best suited for down at the car wash. I can't save the code or the client from him and it's not my job.

While I value good code and sound professional practices, I'm really not going to lose any sleep over what happens two years down the road when some cheap client hands my code over to some high school kid who's only worked through the first four chapters of Learning Perl. Not my problem, not my job. If I'm for some reason deemed not quite good enough to do the work, then that squeaky voiced kid who calls to ask "Yo, Gee, w'sup widdis singleton shizit?" had darn well better be. He dialed the wrong number and is on his own.

  • Comment on Re^3: Programming *is* much more than "just writing code".