If Carpenters Were Hired Like Programmers (2004)
jasonbock.net
jasonbock.net
"How long will it take to make this table?"
"3 weeks. But we're going to try using this new kind of leg because it's easier to replace with another leg if you don't like it. So it may take 5 weeks."
5 weeks pass
"Is the table done?"
"Well, no, not really. But now you can have four different legs if you want to. We've also got this table building machine that can make all the different types of legs that will slot in"
"Can we use the table-building machine to build the table?"
"No, it only does legs right now"
10 weeks later
"All right guys, it's been twice as long. Is it done?"
"Yeah, we're finished. You're going to love this. We upgraded the table building machine so now it builds as many tables as you like. All you have to do is sketch out a full blueprint. We've got one blueprint for the table you want, but you can make more if you like"
"Where's my actual table?"
"Oh, it's that pile in the corner. It's broken, though. Jack placed a red cup on it and it fell apart. You're not supposed to do that. We told him to use blue cups. It's in the manual. We explicitly fixed blue cups last week."
Customer: I want a table with four legs.
Dev: Ok, give me 2 days and it is done. after 2 days Here's your particle board table about 1 meter off the ground with seating for 4.
Customer: Great, but it would be nice if it could seat 6 sometimes because we sometimes have guests.
Dev: Ok, give me half a week. 3 days pass Ok, here's your table for 6, we had to change the material to wood to make it more durable and unfortunately it increases the cost.
Customer: No way I'll pay extra for wood. What's wrong with particle board? And the texture of this wood is too noticeable, the texture has to be more subtle. And we want to minimize the size to a table of 4 when the guests are not around so we can have more floor space.
Dev: Ok but expandable tables are significantly more complex and I don't think we can do it with your cost contraints. Can you consider increasing the cost?
Customer: What are you talking about? When I asked the Indian shop down the road they said it was possible at this cost. Are you lying to me? If you don't fix this and deliver then I want my money back and I'll just go with the competition.
Dev: Ok, we obviously can't compete with that price so here's your refund. But we highly don't recommend that shop because you will have issues with the table.
Customer: I think everything will be fine. Good luck to you and don't try to upsell me.
6 months later
Customer: Here's the table the Indian shop built. It sometimes won't collapse and they can't figure out what's wrong with it. Can you fix it?
Dev: Ok, we can take a look... You see the problem is this rail design is not fit for these specifications. We can fix it temporarily but in order to fix it permanently we have to rebuild the table top surface which means only the legs will be reused.
Customer: What do you mean? Can't you just install new rails?
Dev: You see, particle board is too flexible a material so over time the fasteners will fail. That's why we recommend wood. But you didn't want to pay for that in the beginning so we didn't want to continue with the contract.
Customer: Fine! Fix it, we need the table next week for a dinner party. How much?
Dev: Our backlog indicates we're booked for the next month. So to prioritize this job we need additional compensation as we'll temporarily have to hire additional help to satisfy demand.
Customer: Are you crazy? I can get 2 new tables that don't expand for that price. This isn't rocket science, I'll find my own way.
6 months later
Customer: We need a table. We're ready to pay anything.
Dev: Oh, you're in luck. Expandable tables are now free of charge. We only charge an installation fee and optional warranty fee if you want us to fix potential issues after delivery. The only catch is they only come in white.
Customer: Excellent, but what about brown? And since it is so cheap now can't you make it height adjustable?
Dev: The brown configuration is a small additional fee but the height adjustable feature has to be made from scratch as it is new technology. It is quite expensive because the motors have not been validated yet, so we have to do a qualification test on each part.
Customer: what? just give me the white table and I'll go talk to the Indians again.
---
Software often has expanding scope and new "innovative" requirements. It is almost never the case that we have a fixed deliverable; once the customer has a solution, they immediately want something else improved. This flexibility manifests on additional R&D costs for new or customized technology.
the small changes never stopped coming until it was a new website. I kept all the major versions so they could see their changes as they developed, so that when they demoed it to a focus group one of the people accidentally navigated to the original version.
next meeting: What is this website? a user accidentally navigated to it and this is now what we want. ... the original version
I think many people miss the fact that boring jobs with low wages will not attract talented programmers. Same holds true when you outsource jobs. Send interesting jobs and pay for good Indian programmers for quality results.
healthcare.gov was a clusterfuck not because it was complicated (a typical data integration task with a query layer) but because of the quality of programmers and managers working on it. Later after political and international embarrassment, a crack team of exceptional programmers was assembled (on leave from major tech companies) to fix that website.
"YAGNI"
"Where is the fourth leg?"
"Over there, across the street. See?"
"...Why?"
"Microservices. When you put something on the table that needs the fourth leg, you use these pipes to temporarily connect it."
Or
Interviewer: what's the most popular kind of wood right now? Exactly. We're putting together a team to make a sink using it. In the second phase we will use wood to build a toilet. Interested?
Or
Interviewer: A carpenter? We were looking more for a mahogany-scientist or a pine-wizard. Are you even a spruce-ninja?
These are too easy :p
that's actually kinda fun!
>that's actually kinda fun!
(years later) ... and that's how I ended up installing toilets in exchange for equity.
Will the price they pay be higher than the cost to build it?
Holy crap, "intalling toilets" hits too close to home as an analogy. Happens way too often.
Given this sequence of basepairs, compute the resulting protein that may be expressed from this sequence.
Suppose Xylem was no longer an accepted technical solution, how would you move water from the roots to the leaves of a tree using only things the tree could grow, and the sun? Compute the maximize tree size using your new method and design a plan for implementation in 3 generations of selective breeding.
Show on the whiteboard the for producing ammonia-based fertilizers at industrial scales, use the Odda process instead of the Haber one. How can you prevent ammonium nitrate from entering a tetragonal crystaline state at 84.2C?
Design a table saw that uses a linear electric motor instead of a rotary motor, assume a 7.3V 5A input source. If we wanted the saw blade to turn at 7300rpm, what gearing ratio would you use in the 3rd translational gear? Compute the lorentz forces on the components and show the resulting torque in an assumed ideal zero gravity environment. Diagram out all vectors on the whiteboard.
Interviewer: Could you give us a couple of examples of carpentry projects you have completed in your spare time, and do you have a portfolio of projects you have worked on outside of your day-to-day job?
Carpenter: Uhm, what do you mean?
Interviewer: I mean like carpentry in your community, or a project you've completed to hone your skills outside work?
Carpenter: Oh, I am usually quite tired of hammers and nails when I get home and I like to spend some time cooking and cycling, but my carpentry work I do in my day job I am really proud of.
Interviewer: We are not really interest in your day job.
Carpenter: ..
On the occasion that they do (super efficient manufacturing plant), the same rules would apply.
TLDR; The carpenter analogy is horrible.
It was strange, but that happens there.
It's probably more common for recent graduates to have public repositories than for the majority of senior devs. Then again I'm sure there are other pressures graduates have to deal with that senior devs don't.
From my recent experience (and anecdotal evidence) it seemed it was becoming a deal breaker for companies but maybe I reached that conclusion too quickly.
It'd be nice if tech recruiters actually had a background in tech.
I should not have to worry about not being able to show any of that. If the people interviewing me don't understand what I did without me showing them, then I am certainly applying at the wrong company.
Don't underestimate the value of some general understanding / intuition of how systems will probably work combined with a little googling.
On a side note I also worked with RFID readers, they were yesteryear's Internet of Things :).
Interviewer: Also, do you have any full stack experience?
Carpenter: Yeah, I guess.
Interviewer: How quickly would you adapt to using a new tool framework that comes out in the market?
Carpenter: I would rather choose to use the tools that I have honed my skills in and am good at.
Interviewer: But, considering the toolbase that our org uses, our other carpenter say that some new kit/framework comes out every other day and they all keep up. I think that toolbench is called JS in short.
Carpenter: ...
Interviewer: Also, how about the fragile methodology, any experience in that?
Carpenter: Yeah, I guess.
Carpenter: No, it's all internal to my previous employer.
"Heck no. I've spent the last ten years becoming an expert in cabinet doors. I don't worry about all that other stuff."
This attitude of breaking things into tiny silos is how you get small projects with 30 people in them that still can't deliver a working product.
Even on a skyscraper, you can bet that all the senior folks there understand the basics of most all of the jobs involved. You don't work in construction without understanding the job in general. This is opposed to IT, where it can be common to hide away in some sub-area and never have experience watching and helping other folks do their work. In many large orgs, the vast majority of developers couldn't build a plain-jane web app from scratch. That's pretty whack.
A carpenter knows enough to know not to try and do the electrical work, because he'll probably do it wrong.
So yes, I am somewhat describing a general contractor, but not really. A GC both knows and manages the work. A good construction worker generally knows what is going on and can pitch in and help (given the appropriate supervision) when needed.
Or put it this way: good construction workers could be really lousy general contractors, but they choose to stick to one area of speciality and become an expert. Really bad construction workers are extreme experts in one area -- to the point that they are obsessed with trivial bullshit that makes no difference to anything -- and refuse to open their eyes to the bigger picture going on around them. It's a difference of whether you're looking outward to the overall value being provided or looking inward to your own little world.
I've worked with good carpenters. They'd never touch an electrical box or plumb out a system, but they can describe what kinds of things happen when this work is done. They can also tell stories of how folks in those areas run into problems and how they've assisted. The physicality of construction, the fact they're all in the same place, makes for really good carpenters, especially if they've worked various kinds of jobs. In IT a hell of a lot of programmers actively want to be physically separated from the overall work.
You can know about everything involved without having to be able to do it or manage it. And you should.
That describes bad employees in general. And if we bring this back around to programming, I'd absolutely expect a back end developer to know a bit about the front end, and the design, and the architecture (and help out if needed).
Here's the key difference: "[A carpenter would] never touch an electrical box or plumb out a system." Software companies, in contrast, routinely expect front end developers to design (because it's all just CSS rules), to write backends (it's the same language), and to deploy in an easily scalable fashion (because "serverless"). That is where the expectations differ.
What are the dimensions of the house? How much will it weigh? What's the lay of the land? Is the soil compaction sufficient? Are there city utilities, or will we have to hook up a well and sewer?
It's about 2000 sq ft.
Those aren't dimensions.
Oh, just figure it out! We need it installed by Tuesday, we're giving it to the client then.
Carpenter: Will I be building pyramids or is there a limit to how many nails we'll have during construction?
Interviewer: No, but we want to assess your critical thinking skills.
Carpenter: (Arranges Pyramid) Ok, I think its done.
Interviewer: Hm... ok well it was kinda slow, but I guess you did ok. Alright, next question. You have 100 boards, for every one that is fir, say "Fir", and for everyone that is Birch say "Birch", and for any that are both "Fir" and "Birch"...
- "carpenter" with "data scientist"
- "brown" with "machine learning"
- "walnut" with "AI" and
- "rock" with "Kubernetes"
It was perfectly up to date regarding my neck of the woods :)
(edit: formatting)
lynx --dump http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac 2>/dev/null | nl | head -102 | tail -98 | sed -e 's/[Cc]arpenter/data scientist/g;s/[Bb]rown/ML/g;s/[Ww]alnut/AI/g;s/[Rr]ock/Kubernetes/g'
The last part, esp.
NEXT DAY:
Ring...
Interviewer: Hello?
data scientist: Hello. Remember me, I'm the data scientist you interviewed for the black AI job. Just wanted to touch base to see if you've made a decision.
Interviewer: Actually, we have. We liked your experience overall, but we decided to go with someone who has done a lot of work with ML.
data scientist: Really, is that it? So I lost the job because I didn't have enough ML?
Interviewer: Well, it was partly that, but partly we got the other fellow a lot cheaper.
data scientist: Really -- how much experience does he have?
Interviewer: Well, he's not really a data scientist, he's a car salesman -- but he's sold a lot of ML cars and he's worked with AI interiors.
data scientist: [click](open console on article and paste this hacky code for an automated version)
[ ["carpenter", "Data Scientist"],
["brown", "Machine Learning"],
["walnut", "AI"],
["rock", "Kubernetes"] ].map(function(r)
{
var rg = new RegExp(r[0], 'ig');
document.body.innerHTML = document.body.innerHTML.replace(rg, r[1]);
});Now if that were 20 years, instead of the rock it would be a complex, slow hammering machine that employed tumbled-smooth colored rocks.
Those rocks would pulled from a shared quarry at the point in time when they were needed.
The new way to provide such rocks would be to order a large truck carrying the rock hammering machine and a set of subcontractors you'd previously had to train by showing them videos on an old VHS tape player. However, the truck would still need to be loaded after each materialization for the job. The truck usually would contain the same supplies, but sometimes some of the rocks would be replaced by scorpions.
Whether or not to use the truck at a job and which trucking company would be a point of debate. Google Building Co. would make the best fleets of trucks with laser targeting systems that made sense to the highly-intelligent, fluffy bears that worked there. Microsoft Building Co. also had two versions of trucks: the old truck that was much slower but worked with existing technology and the new truck which worked if you used a Danish truck and better smaller rocks that few people could find. All of their workers swore like sailors. A subcontracting team all wearing red baseball caps worked with both companies, but supplied their own equipment that was all transparent, and you could either pay for it or not, depending on whether or not you got it from someone else they gave it to.
...there was something about nails, but I forget.
Inteviewer: So you are a carpenter?
Carpenter: Yes.
Inteviewer: Can you make a start fixing that leaky roof over there? We will monitor your skills and might hire you.
Carpenter: Done.
The only problem I've seen with this approach is where the applicant is legitimately pressured for time by their current work or family issues. Being understanding and working out how to extend the trial period will get you through most of these.
In countries (like mine) that don't have at-will employment it amazes me that employers don't insist on this approach. Instead - weird filtering by recruiters, overly specific interview questions and then disappointment when recruiting goals aren't being met and stress when developers who aren't a good fit are stuck with the team for years.
You will not hire anyone currently employed like this. You would be unlikely even to hire a contractor.
Carpenter: I'm breaking your roof.
John: Yes?
Interviewer: Can you fix the roof by tomorrow? This interviewee that was supposed to fix it really fucked it up..
John: But.. I've got to make this architectural blueprint for... sigh fine.
Q: so you're a programmer, how many years experience?
A: 10
Q: ever make a web application?
A: yes, I did I..
Q: great! you're hired!
A: Uh, don't you want to know what languages, frameworks, backend systems I've used?
Q: what no, you've built web applications. You will come in and do that right away because you built web applications!
A: uh, don't you want to know what my thoughts are on testing, product management methodologies I prefer, team sizes I feel comfortable with?
Q: no, of course not! HELLLOOO, web applications here. They're great, you're a natural!
A: Uhm, what size are these web applications meant to scale up to?
Q: any size that's reasonable of course! The size of web applications that people use! Be here tomorrow we're going to start you off right away!
A: I don't really want this job.
Note: I've never really hired a carpenter, but it seemed like the linked article didn't let the idea that these might be very different occupations get in the way of snark, so why should I?
There is a lot to learn about culture, tools, frameworks etc.
So Clojure, Java, Javascript, Haskell and Ruby are all basically the same?
I think damage can be done hammering different languages into the same methodologies..
> If a developer is skilled
You suggest skill is generic. If a programmer is smart they can learn new paradigms. Projecting the paradigms they are used to onto new domains can produce problems, least of all the standardisation.
Basically, yes. You learn to think how, the rest is implementation. Don't get me wrong, it's not an immediate switch, it takes learning and time, but deep inside, the are the same indeed.
It's just like grapes and grapefruit. Completely indistinguishable from one another.
Nice try, but we were talking about PHP and Java. Also, for instance, functional paradigm is the same for all functional languages, which is what I meant in the first place.
> You suggest skill is generic.
I'm suggesting the developer understands the OOP paradigm, knows about design patterns and isn't confused by the small differences in syntax or how much a language borrows from each paradigm. Two languages using the same paradigm are closer to each other, regardless of how different their syntaxes may be.
> Projecting the paradigms they are used to onto new domains can produce problems
That's completely true, but I'm not going to write generic comments that cover every case. I'm replying to someone comparing PHP to Java. It's my understanding the PHP is mostly OOP.
You started by saying "Software is software", you didn't mean this to imply all languages are similar?
> functional paradigm is the same for all functional languages
So Haskell and Clojure are similar?
> understands the OOP paradigm, knows about design patterns
Design patterns differ between languages. And OOP principles too. I don't want to see ConfigurationBuilderFactory classes in my Python code.
> I'm not going to write generic comments that cover every case
You only claimed "Two languages using the same paradigm are closer to each other" - but this seems tautologically true, depending on how you define "paradigm". Many OO languages differ in ways significant to the Java way of OOP.
Yes.
> Design patterns differ between languages. And OOP principles too
Not that much compared to paradigms. They're closer to coding styles. Once you understand what encapsulation is and how python lacks visibility modifiers, it's only a matter of using a coding style to compensate.
> "Two languages using the same paradigm are closer to each other" - but this seems tautologically true
Taken out of context, sure, but you excluded the second part. That's why I think Haskell and Closure are similar.
Using the incorrect nail for the job can lead to disaster or complications down the road. Think of using a nail that will rust over time being used on an exterior deck. Or a nail that is too long or thick for the pieces of lumber it is supposed to be securely (potentially splitting the boards).
If so, sounds like he's smart enough to pick it up.
A novice PHP developer will (or at least would have 5 years ago) create a messy script with interspersed HTML and PHP, a SQL injection vulnerability or two, and little code organization.
A novice Java developer will implement a bunch of patterns they don't understand (probably misusing them), and write a mess of code with too many side-effects.
An experienced developer can write good code in either language, and many of the patterns will end up looking similar.
Don't Haskell and Java differ significantly wrt Type systems? And the rigid class structures of Java might cause one to build very different programs that you might in a more dynamic language?
It takes a few weeks, month and perhaps 1-2 years for someone and i think it is fair enough to decide to hire an java guy for a java position over an php developer and to ask this in a job interview. It might be also okay to hire some php developer (or vice versa) but dismissing it, that there is a difference, is wrong.
But the more collaborative your environment is, the more the trivia doesn't matter. I often work on pair-programming teams, and in that context I mainly care about deep skills.
Let's say you are looking for experience with Machine Learning, Distributed Systems, Databases, Kernel, Graphics, Embedded, etc. IMHO those things are harder to learn than a new programming language or framework (at least after having some experience).
That said, I think this article was more about requirements such as: "at least 3 years experience with X". Where X is just another language/framework/tool. It artificially limits the number of applicants and you might miss some pretty good devs, just because they don't try to apply since either they've only worked with X for one year yet or they've only used tool Y instead of X.
Carpenter: Yes, I have experience to be a naughty apprentice and cursing the old carpenters who forgot the anti termite treatment.
Carpeting is just more tangible, I think.
didn't know that their work isn't called carpeting :D
In the US, for significant, long term financial security, it is close to essential to start, own, and run a business and make it successful.
As a young person in a hot field, being an employee can look good, but usually too soon, well before retirement, being an employee is awful.
For computing: If computing is valuable, and of course it can be very valuable, then somehow a person in computing needs not to be an employee but to own their own business and make it successful.
Broadly a key to being successful in business is to sell directly or nearly so to the end user. So, in computing, for the business, develop a product or service that sells to, gets revenue (or eyeballs for ad revenue, here and below) from, the end user. For this, pick a problem the end users want solved and that you can solve with computing, have a barrier to entry, ..., and get the revenue. Try to have the product, service so that the number of end users times the net revenue from each makes a good business, e.g., gets you some good financial security.
There is a huge, but easily overlooked, difference: (A) As an employee, you are getting all your money from your employer, only from your employer, and they know exactly how much money you are getting. If the employer concludes that they are paying you more than necessary, then they will work to pay you less. It's super tough to get good financial security as an employee from an employer. (B) As a business owner, you are getting money from usually at least a few and often many users, and usually the users have no idea what your profit margins and net revenue are, and, even if your revenue is high and they know it, there's next to nothing they can do about it. So, if you can find a way to get a lot of net revenue, then you have a good chance of some good financial security; the users have little or no way to keep you from the revenue.
In simple terms, if your work is valuable, then you should get a lot of money for it. Being an employee is a poor way to get that money; instead, your employer gets the big bucks. So, own your own business and keep that money, the big bucks, plus what would have been your employee's salary, for yourself.
In the terms of the OP, there are some huge advantages in owning your own business. To illustrate this point, I will draw from the best example I have, my startup:
I saw the problem, did some applied math technical work for a solution, designed a Web site as the means of delivering the solution, designed the rest of the software, learned a little HTML and CSS (but no JavaScript -- didn't need it) and Microsoft's .NET Framework (for writing applications software), ASP.NET (for Web pages), ADO.NET (for programming use of relational database, e.g., Microsoft's SQL Server), typed in 24,000 programming language statements in 100,000 lines of typing, and am going live on the Internet ASAP.
Well, all I had to learn was just what I needed, and for more I didn't learn it. So, e.g., compared with C#, I prefer Visual Basic .NET as easier to learn, teach, read, write, and debug and otherwise, as access to .NET, etc., essentially equivalent to C#. E.g., C# has much of the deliberately idiosyncratic syntax of C, a language designed to be really sparse and low level and to compile and run on a 5 KB DEC mini computer; and C++ was originally just a pre-processor to C (in those days, language pre-processors, e.g., RATFOR, were popular). So, for me, to heck with the C# syntax, and I have not studied C# and have yet to write a single line of it.
Yes, apparently Python is quite useful and very popular. As I understand it, it is interpretative which means it can be easier to use but slow. As I understand it, Microsoft's Iron Python is compiled and provides good access to .NET. As I understand it, Python has some really nice software "packages". Maybe in time I will need or be able to make good use of Python; then I will learn and use it. But so far I've had no use for Python and have not used, learned, or even installed it.
Python is just an example: I just learn and get needed experience with the software tools I need for my startup, and that's much, much less than would would be needed for the scenarios, in my experience accurate as a parody, in the OP.
Now what I concentrate on learning is not software tools (so far I have what I need and from early in my career much more) but what I need for my business, e.g., now, getting good initial data, publicity, and products (processors, motherboards, main memory, mass storage, etc.), and server construction, monitoring, maintenance, and administration.
E.g., for my servers, can I use AMD Ryzen processors with ECC (error correcting coding) main memory and Windows Server 2016 (that wants ECC main memory)?
So, I'm 100% owner of my startup. Thus, if there is good value in my software, then I will get that all that value instead of some only some small fraction of that value with some employer getting the rest.
So, to respond to the situation in the OP, I suggest that people who can write valuable software should start their own business, own 100% of it, pick a good problem, write valuable software for a valuable solution, and collect the big bucks themselves.
E.g., the OP has the employer asking really dumb questions. Why should a good software developer put up with such nonsense? They shouldn't and, instead, should have their own business. Such nonsense is not a good path for either the employer or the employee to make much money.