12 ms·

> When people are doing a physical task, it’s easy to assess how hard they are working. You can see the physical movement, the sweat. You also see the result of

by jxf 13y ago

> When people are doing a physical task, it’s easy to assess how hard they are working. You can see the physical movement, the sweat. You also see the result of their work: the brick wall rising, the hole in the ground getting bigger. Recognising and rewarding hard work is a pretty fundamental human instinct, it is one of the reasons we find endurance sports so fascinating. We've all heard about the stereotypical manager-perception of "effort invested will be proportional to results delivered!", like the article laments. But this analogy breaks down really quickly. Let's use an example that's not from software to illustrate the point -- in fact, let's use the author's own example, laying bricks. Who would you rather hire? -- Bricklayer A: Takes 2 weeks to finish a wall, stays late every day to finish the job, finally builds a brick wall of passable quality. -- Bricklayer B: Finishes your wall in two hours because he realizes there's a better way to lay your bricks, and builds a wall of excellent quality. I feel like most people, even managers of non-software folks, would rather hire B. At least, I certainly would. So I think the premise of the article is wrong. There's something deeper going on, and dismissing it with "managers want to reward hard work, and creatives don't look like they're working hard" is an explanation that is "neat, simple, and wrong" [0]. [0]: http://en.wikiquote.org/wiki/H._L._Mencken http://en.wikiquote.org/wiki/H._L._Mencken

knightofmars 13y ago
I think the point missed is that you can easily look at the work done and contrast the quality of Bricklayer A's and Bricklayer B's. Concrete results will always be easy to verify and contrast immediately whereas the nebulous and vague world of software will really only show its true colors when you're ten years down the road and still able to add enhancements without crippling the system.
- breischl 13y ago
  Unless you've got x-ray vision, it can be pretty difficult to verify the quality of work. Is there a proper footing under that wall? Is there gravel under that? Was the mortar mixed to the proper consistency? Is there a second course of brick hidden behind the first one (wait, should there be?) and if so what's the quality of that? That's just what I can think to ask from having had one minor wall built. I'm sure a real bricklayer could do better.
greenyoda 13y ago
Exactly. I think the underlying issue, for both bricklayers and software developers, is that managers need to have the competence to accurately evaluate the work of their employees. If they can't do that properly, they're hurting their businesses and should be retrained or replaced. (Unfortunately, these managers' managers are also frequently incompetent at evaluating their work, so the bad managers keep on doing what they do and good employees leave.)
- danielweber 13y ago
  But that is hard! I've experienced management that could only evaluate your productivity based on hours in the office. Now, I generally did pretty well at that one, because I was doing a lot of hours, but if I had to come in late because my apartment flooded he was all grumpy, because the one tool in his toolbelt wasn't working.
  - greenyoda 13y ago
    "But that is hard!" Who said that being a good manager was easy? Managers also need to work hard to deserve their high salaries. Lazy managers who can't be bothered to do their jobs properly should be fired.
    - rattray 13y ago
      How can you tell if he's an excellent manager who knows not to bother engineers, or just lazy? ;-)
      - Shamanmuni 13y ago
        Probably by talking to him. It's not hard to tell if a manager has no clue about what you do. If he doesn't, then he's probably using some silly and lazy metric like "hours in the office" or "lines of code written per day". If he does, he probably took the time to learn about your job and make a more accurate assesment of your work. Really, as a programmer you are supposed to know lots of things, learn some more and work hard; but the guy above you cannot be bothered to learn some useful skills in order to asses your work? What kind of logic is that?
jamii 13y ago
I think the explanation still functions if you also add the belief that work is largely incompressible. If most professional bricklayers take a year to build a passable house and someone tells you they can do it in two days but wants 10x the rate, that would smell a little fishy.
markrages 13y ago
Your analogy fails: There's just not a 100:1 difference in effort to lay a brick wall. Maybe 3:1. But you still have to pick up each brick, no matter how talented you are. This is why bricklaying (and other physical processes) are bad analogies to computer programs.
- Swizec 13y ago
  Not really. There are these things: http://assets.inhabitat.com/wp-content/blogs.dir/1/files/2010/11/new-127.jpg http://assets.inhabitat.com/wp-content/blogs.dir/1/files/201... Bricklaying machines where bricks go into a bucket and out the other end comes a horizontal wall. You could prefab this on the floor and then just put it up ... maybe, I don't know, I'm not a bricklayer.
  - Sharlin 13y ago
    The image is a bit misleading. That is not an automated bricklayer, it's just a bit more ergonomic way for human workers to lay bricks.
    - deleted 13y ago
      [deleted]
    - zoips 13y ago
      http://www.dailymail.co.uk/news/article-2276585/Follow-self-road-Incredible-machine-lays-carpet-bricks-removing-breaking-hard-work.html http://www.dailymail.co.uk/news/article-2276585/Follow-self-... Seems automated from the article. Edit: As mentioned below, reading is fundamental, I should learn to do it sometime.
      - ygra 13y ago
        Well, from the same article: »All a worker as (sic) to do is load the bricks into the machine in the desired pattern and gravity does the hard work« So it is a more ergonomic way of laying bricks; you're doing it upright, not crouched down. But you still have to lay them. You can't just throw a pile of bricks into it and get a road out without workers doing anything.
logicallee 13y ago
You're wrong though, you wouldn't prefer to hire B. A will quote you $2000, $500 up-front maybe, and B will quote you $2000, $500 up-front maybe. When you realize B is talking about two hours of work, there is no way you will ever work with him. You will prefer to find some cheap shoddy solution you can supervise for two weeks. It's just how people operate. There's pretty easy proof of this. You would spend weeks of time, $8000 in recruiting expenses, trying to get a web marketing manager who can increase your conversion rate. But if there is a web site that you could allow to A/B test some change to your layout - that its operator somehow comes up with very quickly or even programmatically - you would not give them $5000 for a few minutes of work. It doesn't matter what the 'results' are, or if it's in escrow or tied to the results: you just wouldn't. You would prefer to spend weeks of time and double the money on a web marketer who doesn't work as well. And for that reason, such sites just don't exist. There is no place on the Internet you can pay someone $10K for 20 minutes of work, even if those 20 minutes are objectively quantifiably better than the results you would otherwise spend 6 months and $100K trying to achieve. Human psychology just doesn't operate like that.
- greenyoda 13y ago
  It takes time to learn these things. Maybe after hiring A's for a dozen jobs, it will slowly dawn on you that the value they provide for your money is low, and there's always rework and cost overruns involved. At that point, if someone you know recommends a B to you, you'd be open to trying them.
  - lawnchair_larry 13y ago
    So all of A and B's clients have to learn that before things might correct. Markets can remain irrational longer than B can remain solvent.
- joshyeager 13y ago
  I don't think your proof works. If you spend $8000 and several weeks recruiting a marketing manager, you're paying for someone who knows what to do and how to do it, because you don't know how and/or don't have time. If you go to a web site that does A/B testing, you're going to get a set of instructions about how to install it on your site, and then it's up to you to figure out what changes you should try. You now how more work to do, and no better idea about what you should be trying. If you really do have a way to replace a full-time marketing person with an automated web site, build it. It will be a gold mine.
markkanof 13y ago
I completely agree with your conclusion that almost everyone would like to hire Bricklayer B, but I think the disconnect in most work situations comes in rewarding the value provided by that person. If for example both workers would charge 5000 dollars to build the wall, people would be much more skeptical of paying Bricklayer B, because after all, it was only two hours of work. Basically people still have trouble evaluating the value of the work done vs the effort expended to do that work.
- Avenger42 13y ago
  It depends - if everyone knew that B would provide a superior wall, in less time, for the same money, then they'd have a choice to make. Do I care about the build quality? Do I care about the time? A better example is if A now comes back and says "yes, my wall's not as good, and I take longer, but now I'm only going to charge $4000", then you've got a bigger question - is it worth $1000 to you to get a higher quality wall that's done quicker? Or would you rather save the money and lose the time and build quality? This more easily converts to a software example - do you pay a senior developer to develop your product quickly and well? Or do you save money by hiring a developer of lower skill, who will likely take longer and deliver a lower-quality product?
  - deegles 13y ago
    You're making a key assumption that a person is capable of evaluating the skill of a developer and the quality of the end-result. What if you have no background in software? If the lower-skill developer convinces you his work is better (even if it's not) you're going to go with him.
    - zevyoura 13y ago
      Even if you do have a background in software, evaluating talent is difficult; it's why the interview process can be so convoluted.
  - userulluipeste 13y ago
    "if everyone knew that B would provide a superior wall, in less time, for the same money, then they'd have a choice to make" I'm more inclined to think that people would try to bargain hard with the Bricklayer B - "$500 in two hours is a good price for you, pal". After all the thought goes that even for that price B can erect a lot of walls in two weeks (which is A's single wall building time-span), and that's... only fair, right? (in addition) Don't foul yourself that we live only under market-like laws of supply and demand, we're also social creatures that supposedly have to obey social norms. And the norms can be dictated.
omarkatzen 13y ago
Most corporate managers would observe B's rate and demand it of all bricklayers, without bothering to figure out why B built such a good wall. They'd hire cheaply (cost-cutting, HR says this is as much budget as we get) and end up with a bunch of A-type bricklayers, require B-esque timeframes from these A-type people (without bothering to train them in whatever made B so much more efficient) and get terrible walls built by mediocre bricklayers in 2 hours. That is what would actually happen.
- zeidrich 13y ago
  And then while they are employing 50 of these brick-layers and notice that their brick structures aren't being built fast enough, they will question bricklayer B again about why even though the walls aren't going up fast enough he's going home at 5 while all of the other bricklayers are going home at 9.
0xdeadbeefbabe 13y ago
Bricklayer B has a better idea, but doesn't quite have the confidence or energy to see it through to the end. Bricklayer B has an idea that his ideas are better, but they aren't really. Brick layer B is really bricklayer A. Sure it isn't simple.
starterkit 13y ago
Disagree. First, comparison is not correct, if wall could be built in 2 hours that's not a real product, even hackathons require day or more to build "semi-demo-product". I recommend you watching "Simple made Easy" by Rich Hickey. You could select easy way and do it faster, but eventually your solution will be broken. If task was sorting 10 numbers(static numbers), you have 3 options - do it manually - write small program(everything in main()) - design some architecture for APIs and do sorting which one do you prefer? your comparison is like so. P.S. I am not native speaker sorry for mistakes.
mathattack 13y ago
The challenge is that it's very hard to understand 1 versus 2. It is very easy to measure energy level and hours. Just look around, and listen. In software, it is very hard to measure productivity. Lines of code doesn't work. Function points? Nah.... Who is building whose contributions? Many of the nice things (reliability, ease of maintenance, flexibility, ease of testing) that require design expertise take years to see. Add to this that it is very hard to deeply understand complexity of problems, and if the source is the problem itself or the environment. In the end, maybe the immediate manager knows all that's required, but if you get several layers up in the management chain, eventually you hit a non-technical boss. Unless you're at a software firm with a programmer-CEO. This is why it is important for technical folks to also be good communicators, and to "Work up" well.
scrabble 13y ago
I have been "bricklayer B" in this hypothetical scenario when working at a large corporation with a terrible boss. "Bricklayer A" was constantly rewarded for working hard. I was constantly reprimanded for wasting my time since I was deemed to have a much larger "potential," despite producing more output and with a higher quality than most others on my team. This ended up with my leaving that team. So I can't agree that "bricklayer B" is always preferred, but I would say that a good manager would usually prefer that choice. Good managers are not easy to find.
- gknoy 13y ago
  I think the GP's point is exactly that: With a physical contractor, you want it done, to spec, as quickly as possible. Anyone can tell that B is a better bricklayer than A, because we can see that the same work got done, but more efficiently, and are happy because we had to pay them less. With software, it's hard for people to tell that the finished product for Team B is as good as (or better than) that made by Team A, and therefore all they can look at is often effort. They see team A responding to alerts, alarms, production issues, etc, all night and weekend, and then see you cruise out at 5.
  - mcv 13y ago
    Walls are easy to understand. Software isn't. Sometimes comparing one piece of software to another piece of software is like comparing a garden shed to a skyscraper.
    - singingfish 13y ago
      I think a software developer is more like a carpenter (and sysadmins are like plumbers, and electricians are like devops etc). I assisted in laying a 150m2 hardwood floor from a 40 year old warehouse earlier this year. There were quite a few invisible processes that were required to get the floor right. And it wasn't clear at the start that the job would be successful. But because of a very skilled carpenter, and my dedication in doing lots of prep work for him (cleaning, grading and flipping the boards) we got a result that cost the same as new boards[1] and looks amazing, and will last another half a century at least. [1] only because I got the boards for wholesale price.
AlisdairSH 13y ago
Except managers do reward hours vs work. I had a VP once who decreed that the "Productivity" rating on our annual review was to based on the average hours/week spent at work. To be deemed "Productive", a developer had to average 45+ hours/week. This had the effect of screwing over two subsets of developers: 1 - Those that were very efficient and got their work done in a reasonable amount of time. 2 - Those that didn't spend hours/week on timetracking, and just stuck on 40/week by default And rewarded those who were inefficient and took 50 hours to do 40 hours worth of work.
- yogo 13y ago
  Sounds like you do all (or most so that you always have something light to finish off the day) of your work when your mind is rested, you are energized and focused, then read and participate in online communities like HN for the rest of the time. It should always be about the work that is done, but I think the big challenge most of the time is how do you measure the work that is done in certain businesses/industries.
- joelle 13y ago
  That's horrendous.
softbuilder 13y ago
Non-bricklayers can make relatively accurate comparisons between two wall-building projects. Non-programmers, and even programmers themselves often cannot do the same thing between two software projects. Managers have the awkward job of having to divvy up work and guess that they've given everyone an equivalent workload. And there's really no way to know for sure.
- Fr0styMatt 13y ago
  "Non-bricklayers can make relatively accurate comparisons between two wall-building projects. " I would dispute the 'relatively accurate' assumption. My father works in construction and it's often the case that what me (as a non-construction worker) sees as a beautiful kitchen, he'll see as a nice-looking kitchen that's been cheaply made with quality and craftsmanship problems. I would imagine that a bricklayer has a better chance of telling you whether a wall is likely to start cracking within five years than your average person off the street would, for example. You're assuming that non-bricklayers would know what to look for to assess the quality of the wall properly or that brick walls are so simple that any untrained person off the street could figure out what all those hidden factors are. I think this is actually the exact same thinking mistake that people make when they assume that programming must be easy. It's seeing only what's on the surface and not realising there are deeper things (a previous poster mentioned 'hidden processes' when talking about laying down a hardwood floor, which is exactly what I mean here).
  - softbuilder 13y ago
    Hmm. I feel misunderstood. Let me try to cut across what we're both talking about and see if we end up at the same place: Brick walls have a very high level of observability. A non-bricklayer can look at a wall and tell if it fills the space it is supposed to fill, if the wall is obviously crooked or warped, if bricks are missing, and if mortar is missing between bricks. They can do all of this with very little expertise because they can physically inspect the wall and they have also seen many walls before and have internalized some norms for walls. Compare this with a non-programmer's experience with software. All they see is the user interface, which is usually a very small part of the whole. Software has a very low level of observability. Brick walls - typically - are also very simple systems when compared to software such as what is described in the original article. Lower complexity combined with a high level of visibility and broadly shared expectations means that lay people can make many more accurate judgements about a wall, the progress of a wall, the quality of work being done on a wall, etc. without being experts on wall building or brick laying. This is not to take away from expert tradespeople or diminish their value. It's just a completely different situation which I believe was the intent of the original analogy.
LVB 13y ago
One complexity I struggle with is developing potential. Say 'B' is really talented, but also spends a ton of time doing seemingly-unrelated stuff. Maybe chatting with friends on IRC, reading fantasy and gaming blogs, watching YouTube, etc. is part of how the they end up getting work done. But I also think about how maybe just a little less of that could result in them becoming a top performer, because they have the talent and could apply it a little more. Though I completely get that people need "down" time in this business, I've also seen people become exceptional with a little coaching about planning/focusing and time management. The topic of how much time is spent on "other" stuff is often very difficult to discuss in a way that doesn't come off as reprimanding.
- weixiyen 13y ago
  Best thing is just to be honest and truthful with everyone in terms of what the expectations are.
- habitue 13y ago
  > Though I completely get that people need "down" time in this business I can think of few businesses where workers don't need downtime.
SilasX 13y ago
It would be more comparable if you also had the third option: -- Bricklayer C: Tells you that you don't really need a brick wall, and should just stop heckling the people who go by. There's even less observable work, and even more savings.
rdtsc 13y ago
> finally builds a brick wall of passable quality [... vs ...] builds a wall of excellent quality. That is the problem. They can't see it that clearly. Everyone can see a brick wall. "Seeing" good code and from bad is not easy. So another proxy is used -- "apparent effort and time put into it". So in reality when it comes to software, bricklayer A wins quite often. Like the article said: People huddled over screen debugging dangling pointer == GOOD. Staying Friday night debugging deadlocks in threaded code == GOOD. Lots of lines of code written == GOOD. Get stuff done quicker, and then going home on time == BAD. This is a failure of management, having not insight or understanding into how programming or product works and judging complex machinery and structure by the color of its blinking lights on the console or by the length of haircut of it creator.
- vidarh 13y ago
  An example of the building kind: When I bought my house, the first thing we did was knock down the wall separating the front and back living room. We got a cheap estimate, based on the fact that the wall was just a stud wall - it had been knocked through in the past. Then I got a panicked call from the builders: Apparently the previous owner (most like, based on some other horrors) had taking out all the brickwork, without putting in a steel joist to hold the hundreds of kilos of brick of the wall on the floor above in place. The person who had done that work in the first place might very well have seemed very efficient to someone who didn't know the details. To someone who did understood fully what the job entailed, and knew what to look for, once it was out in the open again, the job was obviously not done in a safe manner at all. But once the stud wall was in place, it was not apparent that there was a problem. First when it was gone and the builders stared up at brick where they expected a steel joist was it obvious the job was violating regulations and was inherently unsafe. In software, we do the equivalent of leaving hundreds of kilos of brick unsupported all the time, and cover it up with other layers of code, to the point where it is often extremely hard for anyone to determine quality without going back and auditing every line of code and running every little piece through extensive QA. It might be a failure of management. But often this is because of woefully lacking resources - clients, whether internal or external, often don't understand the importance and refuses to pay for proper management as well as proper testing, qa and documentation. And this is allowed to continue because often it is "good enough" - just like my wall didn't wall down until the new builders had gotten a steel joist in, so often software projects survive horrific decisions or lack of attention to detail.
spinlock 13y ago
If you've ever watched a stone mason work, the tallented ones exert much less effort. My example comes from bar tending. I used to work for a high end catering company so I poured a lot of champaign. After a while, I could pour a bottle into 6 flutes and each flute would be exactly the same height. They would never foam over and it was really easy. I think the big difference is that people know that pouring six flutes of champaign perfectly is hard. They've poured champaign before and they know they couldn't do it. The same goes for laying a wall. Shit, I don't know any management types that would even do thier own drywall. They know they'd screw it up. But, these same people just assume that software is easy. I just had an interview where the CEO asked me to figure out how to scrape an ugly website. I was given an hour to determine which toolkit to use, learn how to use it, and deliver a solution.
kamaal 13y ago
I'm not sure at all here. Basically because if it takes A two weeks what it takes B two hours. Either A totally doesn't get it all, or B is just plainly cheating in some way. Contrary to whatever you may think, you will not be able to build the next Microsoft, send a probe to mars, invent the next cancer drug, build a formula one car, or build the Pyramid of Giza or anything of such class working 2 hours a day, while relaxing away your time at a beach. The world is full of examples of a Bill Gates sleeping below his office desk, Michelangelo falling from painting his way to exhaustion, or a John Carmack spending his time hacking in some isolated hotel. The stories super successful people who work exceptionally hard and very real and are a common place in our culture. I agree about quality and all that, but none of that will be sufficient for great tasks with meagerly efforts. Great things demand great effort. I'm yet to hear of successful people who have become what they are by working just 2 hrs a day. Unless they just had a wild date with luck.
- alok-g 13y ago
  The parent comment is not saying that B is working just two hours per day. Rather that B finished the task in two hours (and then likely moved on to do something else). I have by the way directly witnessed such a huge A vs. B difference in software development. It was in fact two months to two hours ratio. And yet, the A team or the management did not realize this, or even accept this after the fact.
  - kamaal 13y ago
    Well 2 hours compared to 2 months(Compared to original 2 week comparison) is an insane level of difference in quality and productivity. So huge that its either really true or some body is cheating or something is at a miss here. I am not sure why such people even remain programmers all their life. If you can achieve in hours what people take months to achieve, you should be doing very special things. Chase some really big goals. Because after all by the same logic you can achieve in an year what many people may take many lifetimes to achieve. Why are such people stuck doing some small time programming tasks.
    - 13y ago
informatimago 13y ago
What about the bricklayer who would spend 1 week thinking about a better way to build wall, and two more weeks to tune concrete formula and concrete wall casting? He would eventually raise the wall in half a day, but he'd be one week late, wouldn't he?

by jxf 13y ago

knightofmars 13y ago

I think the point missed is that you can easily look at the work done and contrast the quality of Bricklayer A's and Bricklayer B's. Concrete results will always be easy to verify and contrast immediately whereas the nebulous and vague world of software will really only show its true colors when you're ten years down the road and still able to add enhancements without crippling the system.

breischl 13y ago
Unless you've got x-ray vision, it can be pretty difficult to verify the quality of work. Is there a proper footing under that wall? Is there gravel under that? Was the mortar mixed to the proper consistency? Is there a second course of brick hidden behind the first one (wait, should there be?) and if so what's the quality of that? That's just what I can think to ask from having had one minor wall built. I'm sure a real bricklayer could do better.

greenyoda 13y ago

Exactly. I think the underlying issue, for both bricklayers and software developers, is that managers need to have the competence to accurately evaluate the work of their employees. If they can't do that properly, they're hurting their businesses and should be retrained or replaced. (Unfortunately, these managers' managers are also frequently incompetent at evaluating their work, so the bad managers keep on doing what they do and good employees leave.)

danielweber 13y ago
But that is hard! I've experienced management that could only evaluate your productivity based on hours in the office. Now, I generally did pretty well at that one, because I was doing a lot of hours, but if I had to come in late because my apartment flooded he was all grumpy, because the one tool in his toolbelt wasn't working.
- greenyoda 13y ago
  "But that is hard!" Who said that being a good manager was easy? Managers also need to work hard to deserve their high salaries. Lazy managers who can't be bothered to do their jobs properly should be fired.
  - rattray 13y ago
    How can you tell if he's an excellent manager who knows not to bother engineers, or just lazy? ;-)
    - Shamanmuni 13y ago
      Probably by talking to him. It's not hard to tell if a manager has no clue about what you do. If he doesn't, then he's probably using some silly and lazy metric like "hours in the office" or "lines of code written per day". If he does, he probably took the time to learn about your job and make a more accurate assesment of your work. Really, as a programmer you are supposed to know lots of things, learn some more and work hard; but the guy above you cannot be bothered to learn some useful skills in order to asses your work? What kind of logic is that?

jamii 13y ago

I think the explanation still functions if you also add the belief that work is largely incompressible. If most professional bricklayers take a year to build a passable house and someone tells you they can do it in two days but wants 10x the rate, that would smell a little fishy.

markrages 13y ago

Your analogy fails: There's just not a 100:1 difference in effort to lay a brick wall. Maybe 3:1. But you still have to pick up each brick, no matter how talented you are. This is why bricklaying (and other physical processes) are bad analogies to computer programs.

Swizec 13y ago
Not really. There are these things: http://assets.inhabitat.com/wp-content/blogs.dir/1/files/2010/11/new-127.jpg http://assets.inhabitat.com/wp-content/blogs.dir/1/files/201... Bricklaying machines where bricks go into a bucket and out the other end comes a horizontal wall. You could prefab this on the floor and then just put it up ... maybe, I don't know, I'm not a bricklayer.
- Sharlin 13y ago
  The image is a bit misleading. That is not an automated bricklayer, it's just a bit more ergonomic way for human workers to lay bricks.
  - deleted 13y ago
    [deleted]
  - zoips 13y ago
    http://www.dailymail.co.uk/news/article-2276585/Follow-self-road-Incredible-machine-lays-carpet-bricks-removing-breaking-hard-work.html http://www.dailymail.co.uk/news/article-2276585/Follow-self-... Seems automated from the article. Edit: As mentioned below, reading is fundamental, I should learn to do it sometime.
    - ygra 13y ago
      Well, from the same article: »All a worker as (sic) to do is load the bricks into the machine in the desired pattern and gravity does the hard work« So it is a more ergonomic way of laying bricks; you're doing it upright, not crouched down. But you still have to lay them. You can't just throw a pile of bricks into it and get a road out without workers doing anything.

logicallee 13y ago

You're wrong though, you wouldn't prefer to hire B. A will quote you $2000, $500 up-front maybe, and B will quote you $2000, $500 up-front maybe. When you realize B is talking about two hours of work, there is no way you will ever work with him. You will prefer to find some cheap shoddy solution you can supervise for two weeks. It's just how people operate. There's pretty easy proof of this. You would spend weeks of time, $8000 in recruiting expenses, trying to get a web marketing manager who can increase your conversion rate. But if there is a web site that you could allow to A/B test some change to your layout - that its operator somehow comes up with very quickly or even programmatically - you would not give them $5000 for a few minutes of work. It doesn't matter what the 'results' are, or if it's in escrow or tied to the results: you just wouldn't. You would prefer to spend weeks of time and double the money on a web marketer who doesn't work as well. And for that reason, such sites just don't exist. There is no place on the Internet you can pay someone $10K for 20 minutes of work, even if those 20 minutes are objectively quantifiably better than the results you would otherwise spend 6 months and $100K trying to achieve. Human psychology just doesn't operate like that.

greenyoda 13y ago
It takes time to learn these things. Maybe after hiring A's for a dozen jobs, it will slowly dawn on you that the value they provide for your money is low, and there's always rework and cost overruns involved. At that point, if someone you know recommends a B to you, you'd be open to trying them.
- lawnchair_larry 13y ago
  So all of A and B's clients have to learn that before things might correct. Markets can remain irrational longer than B can remain solvent.
joshyeager 13y ago
I don't think your proof works. If you spend $8000 and several weeks recruiting a marketing manager, you're paying for someone who knows what to do and how to do it, because you don't know how and/or don't have time. If you go to a web site that does A/B testing, you're going to get a set of instructions about how to install it on your site, and then it's up to you to figure out what changes you should try. You now how more work to do, and no better idea about what you should be trying. If you really do have a way to replace a full-time marketing person with an automated web site, build it. It will be a gold mine.

markkanof 13y ago

I completely agree with your conclusion that almost everyone would like to hire Bricklayer B, but I think the disconnect in most work situations comes in rewarding the value provided by that person. If for example both workers would charge 5000 dollars to build the wall, people would be much more skeptical of paying Bricklayer B, because after all, it was only two hours of work. Basically people still have trouble evaluating the value of the work done vs the effort expended to do that work.

Avenger42 13y ago
It depends - if everyone knew that B would provide a superior wall, in less time, for the same money, then they'd have a choice to make. Do I care about the build quality? Do I care about the time? A better example is if A now comes back and says "yes, my wall's not as good, and I take longer, but now I'm only going to charge $4000", then you've got a bigger question - is it worth $1000 to you to get a higher quality wall that's done quicker? Or would you rather save the money and lose the time and build quality? This more easily converts to a software example - do you pay a senior developer to develop your product quickly and well? Or do you save money by hiring a developer of lower skill, who will likely take longer and deliver a lower-quality product?
- deegles 13y ago
  You're making a key assumption that a person is capable of evaluating the skill of a developer and the quality of the end-result. What if you have no background in software? If the lower-skill developer convinces you his work is better (even if it's not) you're going to go with him.
  - zevyoura 13y ago
    Even if you do have a background in software, evaluating talent is difficult; it's why the interview process can be so convoluted.
- userulluipeste 13y ago
  "if everyone knew that B would provide a superior wall, in less time, for the same money, then they'd have a choice to make" I'm more inclined to think that people would try to bargain hard with the Bricklayer B - "$500 in two hours is a good price for you, pal". After all the thought goes that even for that price B can erect a lot of walls in two weeks (which is A's single wall building time-span), and that's... only fair, right? (in addition) Don't foul yourself that we live only under market-like laws of supply and demand, we're also social creatures that supposedly have to obey social norms. And the norms can be dictated.

omarkatzen 13y ago

Most corporate managers would observe B's rate and demand it of all bricklayers, without bothering to figure out why B built such a good wall. They'd hire cheaply (cost-cutting, HR says this is as much budget as we get) and end up with a bunch of A-type bricklayers, require B-esque timeframes from these A-type people (without bothering to train them in whatever made B so much more efficient) and get terrible walls built by mediocre bricklayers in 2 hours. That is what would actually happen.

zeidrich 13y ago
And then while they are employing 50 of these brick-layers and notice that their brick structures aren't being built fast enough, they will question bricklayer B again about why even though the walls aren't going up fast enough he's going home at 5 while all of the other bricklayers are going home at 9.

0xdeadbeefbabe 13y ago

Bricklayer B has a better idea, but doesn't quite have the confidence or energy to see it through to the end. Bricklayer B has an idea that his ideas are better, but they aren't really. Brick layer B is really bricklayer A. Sure it isn't simple.

starterkit 13y ago

Disagree. First, comparison is not correct, if wall could be built in 2 hours that's not a real product, even hackathons require day or more to build "semi-demo-product". I recommend you watching "Simple made Easy" by Rich Hickey. You could select easy way and do it faster, but eventually your solution will be broken. If task was sorting 10 numbers(static numbers), you have 3 options - do it manually - write small program(everything in main()) - design some architecture for APIs and do sorting which one do you prefer? your comparison is like so. P.S. I am not native speaker sorry for mistakes.

mathattack 13y ago

The challenge is that it's very hard to understand 1 versus 2. It is very easy to measure energy level and hours. Just look around, and listen. In software, it is very hard to measure productivity. Lines of code doesn't work. Function points? Nah.... Who is building whose contributions? Many of the nice things (reliability, ease of maintenance, flexibility, ease of testing) that require design expertise take years to see. Add to this that it is very hard to deeply understand complexity of problems, and if the source is the problem itself or the environment. In the end, maybe the immediate manager knows all that's required, but if you get several layers up in the management chain, eventually you hit a non-technical boss. Unless you're at a software firm with a programmer-CEO. This is why it is important for technical folks to also be good communicators, and to "Work up" well.

scrabble 13y ago

I have been "bricklayer B" in this hypothetical scenario when working at a large corporation with a terrible boss. "Bricklayer A" was constantly rewarded for working hard. I was constantly reprimanded for wasting my time since I was deemed to have a much larger "potential," despite producing more output and with a higher quality than most others on my team. This ended up with my leaving that team. So I can't agree that "bricklayer B" is always preferred, but I would say that a good manager would usually prefer that choice. Good managers are not easy to find.

gknoy 13y ago
I think the GP's point is exactly that: With a physical contractor, you want it done, to spec, as quickly as possible. Anyone can tell that B is a better bricklayer than A, because we can see that the same work got done, but more efficiently, and are happy because we had to pay them less. With software, it's hard for people to tell that the finished product for Team B is as good as (or better than) that made by Team A, and therefore all they can look at is often effort. They see team A responding to alerts, alarms, production issues, etc, all night and weekend, and then see you cruise out at 5.
- mcv 13y ago
  Walls are easy to understand. Software isn't. Sometimes comparing one piece of software to another piece of software is like comparing a garden shed to a skyscraper.
  - singingfish 13y ago
    I think a software developer is more like a carpenter (and sysadmins are like plumbers, and electricians are like devops etc). I assisted in laying a 150m2 hardwood floor from a 40 year old warehouse earlier this year. There were quite a few invisible processes that were required to get the floor right. And it wasn't clear at the start that the job would be successful. But because of a very skilled carpenter, and my dedication in doing lots of prep work for him (cleaning, grading and flipping the boards) we got a result that cost the same as new boards[1] and looks amazing, and will last another half a century at least. [1] only because I got the boards for wholesale price.

AlisdairSH 13y ago

Except managers do reward hours vs work. I had a VP once who decreed that the "Productivity" rating on our annual review was to based on the average hours/week spent at work. To be deemed "Productive", a developer had to average 45+ hours/week. This had the effect of screwing over two subsets of developers: 1 - Those that were very efficient and got their work done in a reasonable amount of time. 2 - Those that didn't spend hours/week on timetracking, and just stuck on 40/week by default And rewarded those who were inefficient and took 50 hours to do 40 hours worth of work.

yogo 13y ago
Sounds like you do all (or most so that you always have something light to finish off the day) of your work when your mind is rested, you are energized and focused, then read and participate in online communities like HN for the rest of the time. It should always be about the work that is done, but I think the big challenge most of the time is how do you measure the work that is done in certain businesses/industries.
joelle 13y ago
That's horrendous.

softbuilder 13y ago

Non-bricklayers can make relatively accurate comparisons between two wall-building projects. Non-programmers, and even programmers themselves often cannot do the same thing between two software projects. Managers have the awkward job of having to divvy up work and guess that they've given everyone an equivalent workload. And there's really no way to know for sure.

Fr0styMatt 13y ago
"Non-bricklayers can make relatively accurate comparisons between two wall-building projects. " I would dispute the 'relatively accurate' assumption. My father works in construction and it's often the case that what me (as a non-construction worker) sees as a beautiful kitchen, he'll see as a nice-looking kitchen that's been cheaply made with quality and craftsmanship problems. I would imagine that a bricklayer has a better chance of telling you whether a wall is likely to start cracking within five years than your average person off the street would, for example. You're assuming that non-bricklayers would know what to look for to assess the quality of the wall properly or that brick walls are so simple that any untrained person off the street could figure out what all those hidden factors are. I think this is actually the exact same thinking mistake that people make when they assume that programming must be easy. It's seeing only what's on the surface and not realising there are deeper things (a previous poster mentioned 'hidden processes' when talking about laying down a hardwood floor, which is exactly what I mean here).
- softbuilder 13y ago
  Hmm. I feel misunderstood. Let me try to cut across what we're both talking about and see if we end up at the same place: Brick walls have a very high level of observability. A non-bricklayer can look at a wall and tell if it fills the space it is supposed to fill, if the wall is obviously crooked or warped, if bricks are missing, and if mortar is missing between bricks. They can do all of this with very little expertise because they can physically inspect the wall and they have also seen many walls before and have internalized some norms for walls. Compare this with a non-programmer's experience with software. All they see is the user interface, which is usually a very small part of the whole. Software has a very low level of observability. Brick walls - typically - are also very simple systems when compared to software such as what is described in the original article. Lower complexity combined with a high level of visibility and broadly shared expectations means that lay people can make many more accurate judgements about a wall, the progress of a wall, the quality of work being done on a wall, etc. without being experts on wall building or brick laying. This is not to take away from expert tradespeople or diminish their value. It's just a completely different situation which I believe was the intent of the original analogy.

LVB 13y ago

One complexity I struggle with is developing potential. Say 'B' is really talented, but also spends a ton of time doing seemingly-unrelated stuff. Maybe chatting with friends on IRC, reading fantasy and gaming blogs, watching YouTube, etc. is part of how the they end up getting work done. But I also think about how maybe just a little less of that could result in them becoming a top performer, because they have the talent and could apply it a little more. Though I completely get that people need "down" time in this business, I've also seen people become exceptional with a little coaching about planning/focusing and time management. The topic of how much time is spent on "other" stuff is often very difficult to discuss in a way that doesn't come off as reprimanding.

weixiyen 13y ago
Best thing is just to be honest and truthful with everyone in terms of what the expectations are.
habitue 13y ago
> Though I completely get that people need "down" time in this business I can think of few businesses where workers don't need downtime.

SilasX 13y ago

It would be more comparable if you also had the third option: -- Bricklayer C: Tells you that you don't really need a brick wall, and should just stop heckling the people who go by. There's even less observable work, and even more savings.

rdtsc 13y ago

> finally builds a brick wall of passable quality [... vs ...] builds a wall of excellent quality. That is the problem. They can't see it that clearly. Everyone can see a brick wall. "Seeing" good code and from bad is not easy. So another proxy is used -- "apparent effort and time put into it". So in reality when it comes to software, bricklayer A wins quite often. Like the article said: People huddled over screen debugging dangling pointer == GOOD. Staying Friday night debugging deadlocks in threaded code == GOOD. Lots of lines of code written == GOOD. Get stuff done quicker, and then going home on time == BAD. This is a failure of management, having not insight or understanding into how programming or product works and judging complex machinery and structure by the color of its blinking lights on the console or by the length of haircut of it creator.

vidarh 13y ago
An example of the building kind: When I bought my house, the first thing we did was knock down the wall separating the front and back living room. We got a cheap estimate, based on the fact that the wall was just a stud wall - it had been knocked through in the past. Then I got a panicked call from the builders: Apparently the previous owner (most like, based on some other horrors) had taking out all the brickwork, without putting in a steel joist to hold the hundreds of kilos of brick of the wall on the floor above in place. The person who had done that work in the first place might very well have seemed very efficient to someone who didn't know the details. To someone who did understood fully what the job entailed, and knew what to look for, once it was out in the open again, the job was obviously not done in a safe manner at all. But once the stud wall was in place, it was not apparent that there was a problem. First when it was gone and the builders stared up at brick where they expected a steel joist was it obvious the job was violating regulations and was inherently unsafe. In software, we do the equivalent of leaving hundreds of kilos of brick unsupported all the time, and cover it up with other layers of code, to the point where it is often extremely hard for anyone to determine quality without going back and auditing every line of code and running every little piece through extensive QA. It might be a failure of management. But often this is because of woefully lacking resources - clients, whether internal or external, often don't understand the importance and refuses to pay for proper management as well as proper testing, qa and documentation. And this is allowed to continue because often it is "good enough" - just like my wall didn't wall down until the new builders had gotten a steel joist in, so often software projects survive horrific decisions or lack of attention to detail.

spinlock 13y ago

If you've ever watched a stone mason work, the tallented ones exert much less effort. My example comes from bar tending. I used to work for a high end catering company so I poured a lot of champaign. After a while, I could pour a bottle into 6 flutes and each flute would be exactly the same height. They would never foam over and it was really easy. I think the big difference is that people know that pouring six flutes of champaign perfectly is hard. They've poured champaign before and they know they couldn't do it. The same goes for laying a wall. Shit, I don't know any management types that would even do thier own drywall. They know they'd screw it up. But, these same people just assume that software is easy. I just had an interview where the CEO asked me to figure out how to scrape an ugly website. I was given an hour to determine which toolkit to use, learn how to use it, and deliver a solution.

kamaal 13y ago

I'm not sure at all here. Basically because if it takes A two weeks what it takes B two hours. Either A totally doesn't get it all, or B is just plainly cheating in some way. Contrary to whatever you may think, you will not be able to build the next Microsoft, send a probe to mars, invent the next cancer drug, build a formula one car, or build the Pyramid of Giza or anything of such class working 2 hours a day, while relaxing away your time at a beach. The world is full of examples of a Bill Gates sleeping below his office desk, Michelangelo falling from painting his way to exhaustion, or a John Carmack spending his time hacking in some isolated hotel. The stories super successful people who work exceptionally hard and very real and are a common place in our culture. I agree about quality and all that, but none of that will be sufficient for great tasks with meagerly efforts. Great things demand great effort. I'm yet to hear of successful people who have become what they are by working just 2 hrs a day. Unless they just had a wild date with luck.

alok-g 13y ago
The parent comment is not saying that B is working just two hours per day. Rather that B finished the task in two hours (and then likely moved on to do something else). I have by the way directly witnessed such a huge A vs. B difference in software development. It was in fact two months to two hours ratio. And yet, the A team or the management did not realize this, or even accept this after the fact.
- kamaal 13y ago
  Well 2 hours compared to 2 months(Compared to original 2 week comparison) is an insane level of difference in quality and productivity. So huge that its either really true or some body is cheating or something is at a miss here. I am not sure why such people even remain programmers all their life. If you can achieve in hours what people take months to achieve, you should be doing very special things. Chase some really big goals. Because after all by the same logic you can achieve in an year what many people may take many lifetimes to achieve. Why are such people stuck doing some small time programming tasks.
  - 13y ago

informatimago 13y ago

What about the bricklayer who would spend 1 week thinking about a better way to build wall, and two more weeks to tune concrete formula and concrete wall casting? He would eventually raise the wall in half a day, but he'd be one week late, wouldn't he?