Hacker News Reader

Comment by jxf | Hacker News Reader

> 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

View on HN

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.

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?

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.

Even if you do have a background in software, evaluating talent is difficult; it's why the interview process can be so convoluted.

"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.

I would hire Bricklayer B on an hourly basis.

Bricklayer B now takes 2 weeks as well.

Of course; otherwise he would be punishing himself for his efficiency.

I beg to differ, Bricklayer B would reject the job on account of being too busy doing work that paid a sum reflecting the value provided rather than reflecting the sociopathy of the employer.

Or.. B demands a higher payout. That reduces his customer base without affecting his revenue significantly. With fewer customers he has more free time on his hands, in which he invents robots that build brick walls. He now lowers his hourly rate.

This is totally true, and as the original article mentions:

"Unless you can afford to have two or more competing teams solving the same problem, and c’mon, who would do that, you will never know."

So, the above metaphor is almost always impractical, and it's hard to tell what the alternative is to the one bricklayer you have.

...I wonder how many times competing teams have been used for something? It actually sounds fascinating.

The mythical man month never mentioned that. It mentioned multiple implementations of one architecture, but that was for hardware IIRC.

AFAIK it is used in failsafe systems: you have two systems who deliver the same output, but are developed independently.

Hardly, faster time to market is a value multiplier, not a loss.

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.

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.

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.

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.

You wouldn't pay $8000 if you got the exact same end-result in 20 minutes from someone who 'knows what to do and how to do it' (a hypothetical.)

Think through the pricing model of the hypothetical web site you propose in the last sentence - that is my point.

Seen how much people pay for enterprise levels in Omniture?

I'm not saying that there isn't a person out there who can revolutionize my marketing in 20 minutes. I'm saying that I have no way of evaluating someone's marketing skill in just 20 minutes. That's why it's expensive and time-consuming.

If a web site charged $500 and was very easy to implement, I could do it as an experiment and not lose much if it failed. If it succeeded, that web site could charge me again and again to keep doing it, and I would be happy to pay.

But if I have to spend $8000 and several weeks up front, I'm going to be very cautious. It doesn't matter if that money and time are spent hiring someone or purchasing and installing an automated tool.

Note that I defined/proved the non-existence of a market at $5000 (in exchange for 20 minutes of any operator's personal time) and you countered by claiming a (possible) willingness to pay at $500. Thus proving my point. It doesn't really matter what reason you gave, which in your case was trust. Ordinarily that could be countered with escrow or a lack of up-front payment, but this still does not happen, that market still doesn't exist. You can't pay someone whatever revolutionizing your marketing is worth, after you've given them a chance to do so in just 20 minutes and seen, "yep, that works". Doing so would feel wrong to you.

"I'm not saying that there isn't a person out there who can revolutionize my marketing in 20 minutes" - I'm saying you wouldn't pay them to do so in line with what doing so would/should be 'worth' to you. There is no market to pay to revolutionize your marketing in 20 minutes, at a pricing that is based on what it should be worth for you to do so. Doesn't exist. You wouldn't pay it. Imagine what "revolutionaizing your marketing" means, image what "revolutionizing your marketing" would be worth to you - do you have that figure in mind? Now imagine paying that to someone for 20 minutes of their time. You wouldn't. Neither would anyone else. That market doesn't exist.

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.)

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.

"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.

How can you tell if he's an excellent manager who knows not to bother engineers, or just lazy? ;-)

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?

A good manager still knows what their employees are working on - not necessarily in detail but they should be able to describe the user side of the project comfortably and have some idea about which parts are the most challenging.

That's the Zen of good tech management!

How would you suggest that they measure how hard I've been thinking? Or whether the direction of my thinking will pan out?

They shouldn't measure either of those things: they should find a valid proxy for those things, such as the output you produce. Frankly, if they're measuring the process instead of the output, then they're likely to just ultimately be micro-managing.

A decent manager should make themselves available to the team, but not interfere with the team unless something's going wrong, or appears to be going down the path of 'going wrong'. They should measure the team by their output, and use that to determine whether things are going wrong, or are about to go wrong.

Attempting to measure a team by their process makes the assumption that the manager is capable of understanding both the current process, and the maximally optimal process against which to compare the current process. It's far safer for both the manager and the team for the manager to avoid such endeavours, and instead measure the output itself against the optimal version of the output, because the output should meet business/product goals against which it can be assessed.

Agile PM would actually put process first and simply measure output because poor processes impact everything else and give you no chance of sustained success. You should be trying to optimise the conditions for optimal outcomes via facilitation. That's the reason you measure, to understand and improve your success as a facilitator for the whole team, not to track individual productivity. You shouldn't reward or penalise anybody on outcomes themselves but on ability and diligence (which should be blindingly obvious to a technical manager given any degree of engagement with the development process).

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.

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.

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.

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.

Neither software nor architecture are easy to understand.

The wall example is similar to "Write a simple calculator capable of doing addition, substraction, division and multiplication". Anyone can tell if that software works as expected or not and have some idea if it's well done or not.

A similar comparison would be a team designing and building a fully functional house on a budget. In that example it's not easy at all to assert how well they are working, as happens in software development.

I don't think it's nearly so hard to understand.

Does the software solve your problem? Then it's good software. If not, then what are you paying the programmers for, anyway?

But some problems can be solved in a day, others require an immense amount of work. Not everybody can tell the difference.

There is more to bricklaying than shacking bricks. Go look at old structures. You'll see some in Rome where the bricks are still standing 2000 years later. Now look at a typical American patio that cracks in four years and starts to shift. Most people just see bricks, but there are many other factors that will determine if the wall stands the test of time.

To be fair, it's perfectly possible that the typical Roman patio cracked and warped in four years. We don't see the things that didn't survive.

This may be true, and while I am no archeologist, the summer I spent digging up Roman stuff disagrees. Their style of bricks, more like tiles, is very strong. I'd guess it relates to the ratio of tile to mortar.

I don't see how that disagrees substantially. If there was substantial variation in projects (intentional or unintentional), both could easily be the case.

Pre 1940s brickwork is all pretty great in my opinion. I have way too many recycled bricks, for paths and gardens. Some are in place, others waiting to be used. They look great and often have names, places etc stamped into them. The brickwork on Edwardian houses, above doors and windows for example, is great. All the angles and precise corners. And all done with hand tools. The best bit is that they wear in. A bit of grime and weather and they look even better. Compared to modern bricks which fall apart when the surface fails or turn out to be made of concrete, old bricks are fantastic. Bricks are another of my strange obsessions. I'll go back to my corner now...

Please don't go back to your corner. If you can, put up a few web pages about bricks. I think the world could use them. I live in a newly built house (+-6 years) and we have a fake brick facade plastered to the front of our house. I have been thinking recently: "Why didn't we just use real bricks in the first place!?!"

I remember a surprisingly interesting website on nails (and I think screws too) and the defects in them from manufacturing problems. The guy was an expert on the manufacturing process. Your giving me ideas now. The ends of bricks on our house (which is as basic as a 1940s house gets, no fancy brickwork here unfortunately) have finger prints in them. I stumbled across some at a demolition yard with the owner cleaning up a load that were apparently made by prisoners a long time ago - a special triangular symbol was stamped into them. That's when the obsession started. Just picked up a few nice ones with a giant W stamped into them which would never normally be seen as its on the top where the mortar goes. The building was demolished in the Christchurch earthquake, so its got that bit of history as well.

It's not all roses pre-1940. I live in a house built in 1880. Some of the brick used in the foundation is of pretty low quality. So much so that their cores seem to be nothing more than compacted brick dust.

There was an article that mentioned ancient roman concrete survived so long not because it was STRONGER (it's about 10 times weaker than modern concrete) but because it survived the elements better. At least partially, because it was made with volcanic ash. I'd bet the same, or a similar, circumstance is the case with the bricks.

Indeed, the post is about crappy management and little else. This is the real story - we talk about scarcity of engineers but it's as nothing compared to the scarcity of effective technical management, which is an industry scandal IMO.

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.

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.

That's horrendous.

> 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.

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.

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.

That's why you need to find a bricklayer with a O(1) bricklaying technique.

I think you actually get at the crux of the issue, inapt comparison to programming though bricklaying is. If the analogy is going to carry, we should be able to describe an interview process that will distinguish the 2hr vs. 2wk bricklayer. Yet even in programming, this reverse-engineering of interview techniques doesn't exist.

That's because being convincing at interview is much easier to learn than writing good code or laying bricks fast. So for a bad coder (or bad bricklayer) it makes sense to train for interviews instead of training for the actual job.

One thing that is hard to work around is where the interviewee must demonstrate their skill first hand (e.g. implement FizzBuzz followed by strcpy and a binary search.)

Many common interview questions are too indirect (Show me a certificate; Answer this trivia question about a Java API from 1997) or misguided attempts at personality tests (How many sewing machines are there in West Virginia) all of which one can prepare for without having the actual ability to do the job.

These kinds of questions can still work, as long as they have not yet made it into "How to succeed at interviews" type books. Or when the applicants you want to filter out cannot resist outing themselves even with training (e.g. "Tell me about a time when you have been wrong / publicly changed your opinion" will probably always be a useful filter.)

Deploy a single large brick? ;)

How are people still talking about manually deploying bricks? Amazon Wall Services has solved this problem!

Yes, but how many drones is it going to take ? Will the drones have flocking behaviors or just a line into the distance ?

Not really. There are these things: 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.

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.

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.

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.

There are many, many "bricklayers" out there who actually end up not laying the wall at all. They work hard for weeks perhaps months but eventually give up, sometimes leaving a half-finished wall that is so shoddy it needs tearing down by a more experienced professional before they can put up a better wall.

They may well have been paid in part already for work and you're left with nothing to show for it. In many cases they'll leave and find a new "victim" to work for.

Are we still talking about real bricklayers? Because I find that rather hard to believe.

Yes, there are quite a few construction contractors who require they be paid an amount before they begin work. They then either don't even show up, do an awful, intentionally half-finished job, or simply quit to never be heard from again. While anecdotal evidence, my father has been doing construction contracting for the last 17 years and runs into these types of people regularly. He often comes in and finishes the jobs that these people ran from. Usually, he just tears it apart and re-starts.

There are (in the software world) far more instances of bosses who hire you to build a brick wall without the money to do so and put you on net 60 hoping they'll somehow come up with the money by the end.

The more likely scenario in software is you get to day 45 with 90% of the wall built and the client asks you to hand over your key to the job site and stops taking your calls.

There's where most of the "half built walls" in my industry come.

I own a company that works with a number of contractors. I can confirm: this is a huge deal. The fly-by-night subcontractor is a thing. In construction there is nothing more valuable than a network of dependable skilled tradesman. General contractors will pay for good help.

I always thought "if this software thing doesn't work out, I'm gonna go be an electrician". I've now met lots of them making way more money than I am (and I'm well paid). Most of them basically have two or three customers, all of which are GC's. They've shown that they are:

- responsible (show up on time and in the right place)

- dependable (they get the work done on time and on budget)

- knowledgeable (they keep up to date with changes to code)

- respectful (they keep the job-site clean and work well with other subs)

In short, they're professionals in every sense of the word. In exchange they charge 3x what other tradesman charge. People are happy to pay it.

This.

A friend of mine is an electrician. He did his apprenticeship with a guy who worked a lot with high end residential clients (i.e. stately homes — this was in England). He says the one of the most important things that he learned was to clean up after himself — which talks to your respectful point. It made him stand out amongst his peers, and is one of the factors that goes a long way towards repeat business and referrals.

I just finished paying 2x market for an electrician who had the following invaluable skill:

1. Physically appearing at job site.

> In construction there is nothing more valuable than a network of dependable skilled tradesman. General contractors will pay for good help.

Being a software developer who just completed a substantial project (200 metres squared house on a difficult site) this was the most powerful thing I learned on the job. And now I apply it to my own code related problems. Who's in my crew? Where can I get new good crew? How do I manage dealing with cognitive overload by delegating back to other team members etc. I find the similarities/differences between software and construction crews fascinating.

I can attest to this. It's ridiculous how unreliable most contractors and tradesmen are. Our house is about 25 years old so we often need to have a bit of work done to fix things and we are often looking for various contractors and I honestly can say that about half of them never show up after agreeing to do the job. Some of them won't even answer their phone and others will try to reschedule indefinitely and still never show up.

I totally wouldn't have a problem paying top dollar for someone who is reliable and respectful of my time.

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.

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.

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.

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.

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.

I recall an analogy from Skiena [1], although this is not exactly what happened in my two-month to two-hour example. Skiena talks about a problem which appears to have exponential complexity at first, but then shows an insight that turns it into polynomial time. Consider the potential impact of this. Team Exp will be spending lots more time optimizing, debugging, writing test cases, while the team Poly will go though all of that much faster since the task is much easier now. Not just the running time is different, the development and maintenance time could be different by an order of magnitude too.

In the actual case, the team Months could not connect the dots to see that the specific problem at hand, that involved two complex things, somehow had a much simpler solution. Their code, development time, etc. looked perfectly normal from an outsider's point of view. The code was taking 40 minutes per run. I was unaware of their work and coded the same thing independently. My code was five lines core in Matlab plus overheads, or about hundred lines total. It also ran in two minutes.

In short, no one was cheating. Nothing was amiss. Just that I could connect the dots and they could not. Had I not worked on the problem, I would not have figured either.

The issue is that in the normal course of lives, two people or teams are not asked to work on the same problem in isolation. So the difference in performance does not become evident at least in the short run. This is in spite of the amount of duplication of effort that often exists.

Now this does not imply that I could do this for every task, though I do have more examples just as profound. I can often understand complex problems better and faster than other people, and then can work through them faster. But if both sides understand the problem+solution equally well, I may actually be slower in implementing at least in the initial rounds. (This is because my breadth of knowledge across technology domains is often five-ten times broader than normal engineers, which also implies that I have less practice in each domain).

And yes, I am chasing some really big goals.

[1] www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1848000693/

Just checked your profile. All the best for your Start up, do well. As with always its nice to know a fellow HN'er doing so well.

I've always thought it's the other way around. The success stories are about people who are ruthless about succeeding, who are unable to make a work/life balance because they are motivated to succeed at all costs. The crazy hours are a symptom of what makes them successful, but not the cause of it.

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.

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.

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.

"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).

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.

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.

Best thing is just to be honest and truthful with everyone in terms of what the expectations are.

> Though I completely get that people need "down" time in this business

I can think of few businesses where workers don't need downtime.

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.

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.

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.

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?

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.

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.

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.

Reply on news.ycombinator.com