zlacker

>>todsac+(OP)
Not a huge Steve Jobs fanboy, but I always liked his quote[1] about craftsmanship, sweating the details, and giving a fuck:

“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

I think software as a whole suffers greatly from this "well, I got it barely done, technically fulfilling the requirements, so my work is over" attitude.

1: https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...

>>ryandr+n4
I've been giving a lot of thought to how engineers are different in this way. Assuming everyone has similar motivation and work ethic, I think it boils down to what satisfies you — or more precisely, what irks you the least.

For some engineers, the thought of leaving some things undone gives them the icky feeeling, while the thought of not completing a challenge in an expected timeline doesn't bother them. For others, it's the opposite.

I think this holds true even for personal projects, where there's no manager or sprint to impose a time constraint.

>>hanspe+8t
That's an interesting idea to think about: if the thought of not completing a challenge in an expected timeline bothered me so much that I took every step to meet the timeline, and leaving something undone didn't give me a very strong icky feeling, what would I do differently when things inevitably turn out to be more complicated than I originally thought? Turn in my code in a non-working state and say it's done?

>>subarc+x11
In the extreme case, I guess so. The other extreme is the person that will never complete a task as there's always some detail to refine.

But it's a spectrum where most people are somewhere between the extremes.