Clerk Turned Programmer

Programmers who start out in data-entry or clerical positions are less likely to use automation and abstractions in my observation. This is because they can make up for it by re-keying information or steps over again fairly quickly and accurately.

I do not wish to put a value judgment on such behavior at this point because if they can make up for such by typing their arse off and are good typists, then I cannot objectively complain. However, transferring such infrastructure to those of us without a non-clerical background can be rough on us. It is a style that favors a certain kind of employee and work-style.

Also, their lack of desire to find abstractions to avoid repetition also seems to hinder finding broader time-saving and more flexible approaches. However, management doesn't seem to mind that much because they satisfy immediate needs. This is another reason why I'm hesitant to call a value judgment on it: if managers/owners don't favor better abstraction and automation, I couldn't say its better or worse. That's not my job. Maybe it's easier to replace an ex-clerk with another ex-clerk than an abstraction-finding analyst. Staffing may be easier for them if built around clerk-types.

I'll make the judgement call - it's bad; not because of the typist-programmers, but because the lack of abstraction will eventually multiply the places where things need to be changed beyond the limit of fast-typing, and the process will come crashing down.

Furthermore, repetition increases the cost of maintenance, as changes to repeated code -- regardless of typing speed -- will take longer to make in multiple places than in one place, and missing or introducing an error into a single change among many is less likely to be caught than only one change.

But it often does NOT come crashing down because the "clerk-type" reinvents the wheel really fast in a mad-dash caffeinated fit of typing. And, they look like a hero in the process. Go figure. I've seen the opposite: overly-leveraged abstractions that are wound too tight to handle changes in requirements come crashing down, some of them my own creations. John Henry sometimes beats the steam-chopper. (In the original tale he died after winning the race. In this case he'll probably end up filing for federal assistance due to Carpal-Tunnel.)

In my experience, such "mad-dash" hacks fail to leave the starting gate as products - the customer tests the product, and it's too brittle to even pass the acceptance tests. At some point, for all large products, the codebase becomes too large for even an army of such developers to manage, since they often do not abstract even their searches for the many duplicated sections of code.

I agree that large projects are probably not a place where one can get away with such because that approach will be scrutinized by many more eyes, and most developers on large teams will not be kind to the clerk-centric approach. But for lots of small and medium projects or throw-away projects (one-time studies), they can thrive. (Even lots of one-time studies viewed together can have re-occurring patterns that can be used for automation.)

CategoryEmployment