Programmer Coder Engineer Technician

Recently I noticed a LaynesLaw-sort of argument, with one person interpreting the term "coder" to mean the traditional DataProcessing SocialHierarchy? meaning, "someone with minimal programming skills who writes code based on the specifications/supervision of the AlphaMale SystemAnalyst", where the other person clearly meant "coder" to mean "someone who codes", and "don't all of us programmers code?"

Rhyme that, with variations, goes back to at least 1695:

  Tinker, tailor,
  Soldier, sailor,
  Rich man, poor man,
  Beggar-man, thief.

Famous spinoffs:

("Tinker, Tailor, Soldier, Spy" 1979 movie (and British TV mini-series) based on John Le Carré novel 1974)
("Rich Man, Poor Man" 1976 TV mini-series based on Irwin Shaw novel 1969)
("Beggarman, Thief" 1979 TV movie, sequel to "Rich Man, Poor Man", Irwin Shaw novel 1977)

Anyway, this had me thinking about the traditional hardware world distinction between technicians and engineers. The former more or less do the soldering, the latter more or less do the circuit design.

I've seen resentment between those two worlds; in one case, a career technician friend of mine went to night school for 10 years to get an EE degree, and ever since has been a design engineer, and he was moderately unhappy that he had to do so, in his view. But he himself said that he was not able to do EE design until after he got that degree.

I contrast this with several people I know who never got a degree of any form, but did EE circuit design based on self-taught skills. The point here is not which approach is objectively better or worse, or who was right versus wrong; people vary in their skills and ability to self-teach.

The point I wish to raise is that, although there's some dissension in the EE ranks about "technician" versus "design engineer", it is quite minimal compared with programming/software engineering. In EE, people who only know how to do basic stuff like solder and watch the oscilloscope for waveforms given by others, mostly don't complain that they are the equal of the design engineers.

In software, however, it seems like those who really are simply coders, the equivalent of EE technicians, don't even notice that they are any different from the software systems architects who actually design the systems they implement.

And this has nothing to do with degrees, since again, I know multiple non-degreed self-taught software people who are in fact accomplished and recognized systems architects.

The point is just that, in hardware, people tend more or less to recognize their limitations, whereas in software, people don't, at least in my experience, at least as I'm remembering it tonight.

The question is, Tinker, Tailor, Soldier, Spy, is it harder for people to recognize their positives and negatives in the more abstract domain of software, than in hardware, or am I just confused?

For a description of the software equivalents, I would recommend reading the MythicalManMonth by Fred Brooks. I personally do not care for his chief programmer and minions model, as it leads to some of the disruptive values hinted at above. It does serve as a good source of understanding the mindset.

I think this is about bang-on. I was reading Joel Spolsky's foreword to Mike Gunderloy's CoderToDeveloper?, which makes the distinction between "coders" and software "developers". (I haven't read the book itself yet.) One of the big differences is that a coder will have next to no inkling that there is any difference, whereas a developer knows that there is a difference, and furthermore acknowledges that their own software development style/technique is far from perfect. I've met at least one coder who is a textbook case. Choice quotes: I've taken some courses, how hard can it be? and It compiles and runs, doesn't it? What more do you want?

I see this as something in general with software - to continue to pick on EEs, I've know a number of them who, having taken exactly one programming language course, assume that they can write good software. I doubt that they would be as certain about, say auto repair. And as I think about it, perhaps it is the 'abstractness' of software that makes this possible - it looks like thinking, and few people with a college degree deeply feel that they cannot think well.

I think that a major difference between software "coders" (in shops that make distinctions between "designers"/"analysts"/"architects" and grunt programmers) and electrical technicians, is that the latter seldom do design, but the former really do. Most of the activities that a hardware tech does - troubleshooting, repairing, turn-on - has little if any design component; any design changes that do come out of such activities are vetted by the responsible engineer. And the engineer, not the tech, is the guy who is responsible for the success of the design - if a circuit board design doesn't work, the engineer and not the tech is the guy who catches hell.

In software, OTOH, the manufacture/assembly (from spec) of software work-products is fully automated and fully deterministic. There is no software equivalent to repairing a faulty circuit board - things like debugging and testing are design verification activities. Instead, the tasks that low-level SW guys get assigned to - coding to a spec - are design. TheSourceCodeIsTheDesign. Even though a high-level design (often on paper) is being translated into a machine-usable, low-level form, it's still a design activity. And, unlike the EE tech who is generally immune from catching hell due to the mistakes of the designers he works for, the low-level coder is often the guy who catches hell when a software product doesn't work - not the architect, whose (unverifiable) paper documents are presumed to be flawless, on account of his seniority. If it doesn't work, it's the fault of the coder who obviously erred in what is perceived as a task of transcription.

Given that state of affairs, coders doing design (and getting the blame but not the credit), and being intimately familiar with the errors of the senior designers (though often not having any authority to fix them), it's no wonder that a) low-level coder positions are seen as undesirable; and b) many persons who occupy such roles consider themselves qualified for more senior roles.