Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That reminds me of an old story about how different people can look at the same job in different ways:

A man came across three masons who were working at chipping chunks of granite from large blocks. The first seemed unhappy at his job, chipping away and frequently looking at his watch. When the man asked what it was that he was doing, the first mason responded, rather curtly, "I’m hammering this stupid rock, and I can't wait 'til 5 when I can go home."

A second mason, seemingly more interested in his work, was hammering diligently and when asked what it was that he was doing, answered, "Well, I'm molding this block of rock so that it can be used with others to construct a wall. It's not bad work, but I'll sure be glad when it's done."

A third mason was hammering at his block fervently, taking time to stand back and admire his work. He chipped off small pieces until he was satisfied that it was the best he could do. When he was questioned about his work he stopped, gazed skyward and proudly proclaimed, "I'm building a cathedral!"



But this isn't what the piece describes. The author is talking about the _feedback_ one receives while doing work. Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens. This stonemason example, while touching and certainly applicable to some situations, is just too far removed from the reality of what many programmers experience to be relevant here.


I was addressing what the parent comment (from peeters) insightfully observed about the original article's four-step workflow description: getting to the next bug and fixing it could either be thought of negatively ("damn, I have another bug in my code") or positively ("I've solved this problem and made some forward progress"). Whether you find this negative or positive is a function of your mental state.

This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.

During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).


The author explicitly says that fixing bugs feels good. But the point (as I see it) is that the workflow often obscures the larger positive goals of the endeavor and tends to burn people out, and that's a net negative. You can argue that it shouldn't, but I don't think you can argue that it doesn't.

Everyone wants to be that 3rd happy mason. But that story doesn't tell you how to do that, it just suggests that it's a better way. Saying that it's just a function of your mental state is tautological.


The story tells you explicitly. Don't stare at your watch, think about the product vision.

Every day I go to work to fend off spies who want to steal your data. Protecting the powerless, defending your freedom! I will never meet you, and I will never even look at the treasure I am defending, and most of time is spent fixing broken configs, but I am doing it for a good cause, and at the end of the month I enjoy my paycheck too.


>Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens

Even the smartest people I know write imperfect/buggy code, especially the first time around. If you don't take it personally - as you shouldn't - I don't see the issue.


I don't understand the issue either. A compiler warning or exception report is immediate and precise feedback. What could be easier to deal with impartially?

The bigger picture of course is that criticism, whether it comes from other humans, machines, or oneself, is the only way to improve anything. If you want to create anything worthwhile you have to have some mechanism to improve. Why would we want to bury our heads in the sand just so that we never have to hear a critique?

I suppose you could get a rote job on an assembly line and spend your free time watching TV and you'd never have to hear another complaint, but that sounds like an absolutely miserable life to me.


Yes, feedback is helpful and you shouldn't take criticism personally. No disagreement. But feedback that's mostly focused on small problems is draining and criticism is draining. If that's not the case for you, awesome. It's the case for some people. Try to empathize with them. The article articulates that draining feeling and I find that pretty insightful and useful.


Best comment I've read in a long time. Thank you very much Yoda.


I rather like this and would love to appropriate it. Is there a correct attribution to use?


It's an old story that probably pre-dates programming and I've seen it several times in different places. I have no idea what the actual origin is. I just searched the web for "I'm building a cathedral" and used the wording I found here:

http://bestpracticesforbusiness.com/2010/05/07/purpose-in-mo...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: