I have seen this attitude persist all the way back to my days with IBM. It was not good then, and it is not good now. The idea of doing things with speed being nearly the only criterion precludes an organization from choosing certain solutions, because they don’t want to stop and think about them.

My personal ideal for code quality and documentation are the marvelous LINPACK and EISPACK packages, and to a lesser extent, NAG. I rarely achieve that level of thoroughness, although I try.

I also think it’s important to try to write portable code, and find such a focus helps to reduce bugs. I’m also considered stodgy, I think, by some at my place of employment, because I like to insist upon written requirements statements, if only in the form of a paragraph of prose.

I’m also serious about embedding haskell in the build system (I was bored one week), documenting in Japanese on paper (I’m much faster diagramming and writing notes in Japanese– I did it for my own productivity b/c of crazy schedules). Many of my variables are single greek letters, too… they’re faster to type, and I have my own undocumented policies for which letters mean what.

Furthermore, I’d say that, unless you’re a junior PHP programmer or just doing something completely unoriginal and low-skilled in a trendy language, making yourself dispensable is not practical in most cases. There are countless Cobol and FoxPro hackers out there who properly documented their code and did everything you say, and yet they are indispensable b/c Cobol and FoxPro are ‘dying’ languages, and programs written in those languages tend to involve lots of business-specific logic. Should those programmers spend the rest of their programming days trying to make themselves dispensable? What if you’re one of a handful of, say, chemist-programmers that would ever understand what you’re doing, and there’s no replacement in the first place?

With regards to @ehhh, unfortunately he’s got a point in that trading hours of current work for weeks of future work, and other production for production capacity trade offs will get you ahead at the wrong companies.

If you see this happening, take it as a sign that it’s not the job for you.

http://wjmc.blogspot.com/2010/03/polyvalence-defies-commoditization.html

Thanks for the opportunity to comment…

Getting “hit by a bus” is American English idiom or slang for “being made unavailable for reasons no one can control”. It’s not meant literally.

There are other matters here, however, which bear upon the relationship and its ethics. If I write code for hire, the code, its design, its test cases, and its documentation belongs to the person paying me to do it. I therefore have certain obligations to them. However, I reserve certain obligations to myself. Surely, if I don’t get paid for a period I am supposed to get paid, I need to review the relationship. Maybe there’s a good reason why my employer cannot pay me that period and it’s better in my long time interest to understand. Maybe there isn’t, and then, as a professional, I need to finish off my work for them as quickly and diligently as possible and then end the relationship.

There are other ethical things which bear, too. If I am writing software that serves an important social purpose, such as for the military or for a medical device, as professional, I’m responsible for being sure that device performs as it is supposed to perform. Moreover, if I feel the specification is incorrect and I’m aware of it, it’s my responsibility to ask the right questions of the right people to either understand, get it changes, or file the appropriate objections. The same applies to statistical or quantitative consulting, and many other professional activities.

I surely don’t get paid simply to “do software” for N hours, and that’s where my responsibility ends.

on the opposite you can quit or get promoted if you make no documentation. ive seen it both happen.

If the MTBF for a component is 100 days, that may be good enough if it’s your only component. But if you have dozens of such components and they interact with each other, you’re constantly dealing with failures.

In some cases, turning the code over to somene else may not be possible, even if the documentation and test cases and clarity are there. Sometimes the company doesn’t have the skillset that understands the code. I have found, for instance, that programmers aren’t plentiful who understand numerics, even if these are calls to the GNU Scientific Library or routines in R. That’s unfortunate but real. I’ve had to design, devise, code, and plan around this fact of life. I bet others do too.

I’m still around and he is not, but working on his code is no fun.