You could argue that building software has a higher potential for complexity than work in any of those fields. So how do you measure someones ability to be good at that within a reasonable time frame using limited resources (interviewer time)? You're always going to have a "broken" process with those limitations, because you can't test for every possible scenario they may encounter. This leads to a small subset of questions that you use to generalize ability, which leads to errors.
There are two things that guarantee at least a nominal level of competency in those fields:
1) For junior positions, both have professional accreditation, with standardized testing that ensures a basic level of competency. Not to mention the mandatory schooling (in most cases).
2) If you screw up as a doctor or lawyer, you can end up with official sanctions on the public record. If you screw up too bad, you lose your ability to continue to do your job.
I've worked with plenty of dead weight developers who wouldn't pass even these nominal competency tests.
Further, it just seems to me it's easier to benchmark your successes as a doctor or lawyer. At least in a way that has meaning to your potential employer.
I think part of that has to do with the fact we pretty much all work on teams. The actual projects themselves might be somewhat verifiable, but figuring out that developer's actual contribution is a pure crapshoot.
I list of successes for a doctor or lawyer are going to be both more individual, and also verifiable (i.e., less likely to be bullshit).
I'm not a doctor, but from the outside, it seems that practicing medicine is mostly about memorizing a whole bunch of things and then doing them correctly over and over again.
Law actually seems quite similar to programming. You can think of the jury as your users and facts/precedent/laws as the statements available in your programming language. Then your job is to assemble the statements into a program that compiles and that your users want to buy.
I like the law/programming analogy, but theres probably more of a margin for error when your job is to convince some people, depending on if you're prosecuting or defending. If you make even a small mistake when programming, it could break your entire program.
You misinterpreted what I was trying to say. I was simply trying to highlight that theres a difference between dealing with people and dealing with a perfectly logical machine, to support the point that interviewing programmers is harder than interviewing lawyers. And I'm not a programmer.
> There are easily many more programmers who work on potentially life-or-death systems than there are lawyers who litigate death-penalty cases in court.
But potentially life-or-death cases are not limited to death penalty cases, they are just the most obvious class of cases that are life-or-death.
There are far greater numbers (and proportion) of lawyers who work on potentially life-and-death work -- not limited to death penalty cases -- than programmers who do so.
Well, the OP said "sentenced to death" specifically, which is why I mentioned the death penalty. But ok. Either way I still don't think I agree, though frankly I'm just going off gut feeling and don't have any numbers. But think about how much medical device software is out there, plus industrial control equipment, airplanes and other vehicles, military stuff, etc. I know on HN the image of "programmer" is "person taking VC money to write a photo sharing app" but there's a lot of other work out there.
Though for what it's worth this is less a "programmers are awesome and important!" argument than it is a "don't get your view of lawyers from television shows" argument -- if the OP had gone with doctors or something I wouldn't have said anything.
