Let's say your organization has a custom-written software application it uses month-in and month-out. Now let's suppose that the app. needs to be modified. And, finally, let's surmise that you have two programmers to choose from:
Programmer A bleeds ones and zeroes and knows everything about the language in which the software is written. Alas, s/he knows little to nothing about how you use it.
Programmer B has been with your organization for a number of years, in a number of roles. Alas, s/he is barely partway up the language's learning-curve.
Which do you choose?
Here's my take: Processes are picked up by using them. This in many, if not most cases—takes time away from actual programming. Or else processes they’re picked up by osmosis—working with users, listening to their gripes, cleaning up data after mistakes, etc. Understand that I’m not trivializing the learning of a new language--nay, not in the slightest. But I would make the case, based on experience, that the process of learning processes is inherently less efficient than the process of learning a new language/platform.
Why, then, in so very many job descriptions, are the platforms and languages in the "must-have" list, while the industry knowledge is in the "nice-to-have" list? Why, then, is the resident "cowboy coder" called in to inflict her/his cut corners and minimalist use cases and "I don't write code for stupid people" attitude on ao many users? Maybe I've just been disproportionately unlucky that way throughout my career. But it seems to me that, just like politics, software is only as good as the standards we insist upon.
