This is the worst analogy I've ever read about hiring.
Carpentry is much different from programming. If you're building a subdivision, you're not building 500 unique houses. You build one, then you build an almost-exact copy. But here's where it diverges from programming: you don't get to copy it, you have to follow the exact same steps again. You're not building a machine to build houses and then have it build 500 houses. You're just repeating the exact same thing 500 times.
So for hiring a carpenter, a lot of things that don't make sense when hiring programmers makes sense. For example, if you like house 1 of 500, you can probably hire the same team sight unseen to build house 2 of 500. All they're going to do is the exact same thing they did on the first house, leaving very little room to mess something up unexpectedly. They'll probably do a better job, just from having done it before.
Programming is not like that, because we can reuse code, we almost never solve the exact same problem over and over. We are always coming up with a more abstract problem to solve, because the foundation exists for doing so. (Say you're making two websites. You write the first one. What do you do for the second one? Cut-n-paste-and-modify? I hope not. What you probably end up with is a mini web framework and two things that use that. This makes website 3 even easier than website 2, and website 4 easier than that. That's why we call it engineering and not carpentry.)
Another factor that comes into play with programming is deciding when to build a machine to build houses and when to just build a house. That's "experience".
(A more appropriate analogy might be civil engineering. Civil engineers don't build machines to build bridges, they build bridges, because while a lot of things are similar between individual bridges, a lot of things are different too. Civil engineers abstract the components of the bridge, of course; they're not milling I beams or fasteners or developing new types of concretes from scratch for every bridge. That's like libraries that programmers use. But they are also doing engineering -- what's the right material and right type of structure for the given design constraints? Similarly, it would not be strange to ask a civil engineer if she's ever used concrete when you're planning on building an interstate highway. It would also not be strange to set up an example structure and do some load and material calculations on the whiteboard. While being able to do those calculations doesn't mean she's a good engineer, not being able to do those calculations would be pretty strange. I don't know much about civil engineering, but I hope this analogy at least makes a little sense to other laymen.)
I agree with what you say except that the "joke" is not about carpentry at all, instead we are transplanting some common (?) programmer occurrences into the world of carpentry. So it is not an analogy..
It's like that joke, "what if OS'es were cars?" and then in the linux car you have to bring your own seat or something. Car lovers should not be offended...
But back to agreeing with you: it seems that the world of programming is much more brittle than carpentry. Ie. it is indeed true that someone without vast experience in brown may get tripped up by some rarely seen consequence of brown-ness. Maybe it has a weird interaction with the extra warm weather that causes the wood to rot. Etc.
Carpentry is much different from programming. If you're building a subdivision, you're not building 500 unique houses. You build one, then you build an almost-exact copy. But here's where it diverges from programming: you don't get to copy it, you have to follow the exact same steps again. You're not building a machine to build houses and then have it build 500 houses. You're just repeating the exact same thing 500 times.
So for hiring a carpenter, a lot of things that don't make sense when hiring programmers makes sense. For example, if you like house 1 of 500, you can probably hire the same team sight unseen to build house 2 of 500. All they're going to do is the exact same thing they did on the first house, leaving very little room to mess something up unexpectedly. They'll probably do a better job, just from having done it before.
Programming is not like that, because we can reuse code, we almost never solve the exact same problem over and over. We are always coming up with a more abstract problem to solve, because the foundation exists for doing so. (Say you're making two websites. You write the first one. What do you do for the second one? Cut-n-paste-and-modify? I hope not. What you probably end up with is a mini web framework and two things that use that. This makes website 3 even easier than website 2, and website 4 easier than that. That's why we call it engineering and not carpentry.)
Another factor that comes into play with programming is deciding when to build a machine to build houses and when to just build a house. That's "experience".
(A more appropriate analogy might be civil engineering. Civil engineers don't build machines to build bridges, they build bridges, because while a lot of things are similar between individual bridges, a lot of things are different too. Civil engineers abstract the components of the bridge, of course; they're not milling I beams or fasteners or developing new types of concretes from scratch for every bridge. That's like libraries that programmers use. But they are also doing engineering -- what's the right material and right type of structure for the given design constraints? Similarly, it would not be strange to ask a civil engineer if she's ever used concrete when you're planning on building an interstate highway. It would also not be strange to set up an example structure and do some load and material calculations on the whiteboard. While being able to do those calculations doesn't mean she's a good engineer, not being able to do those calculations would be pretty strange. I don't know much about civil engineering, but I hope this analogy at least makes a little sense to other laymen.)