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

I get it barely done, technically fulfilling the requirements. How much more I clean up depends how much more time my PM has left me in the sprint. Since I'm constantly bombarded by questions, appeals for help, requests to approve pull requests, last minute changes, various meetings etc., that usually is not much, if any, time.

>>Mc91+p6
Have you tried taking the time instead of asking for it? It works surprisingly well in my experience, with very little pushback (and when there's pushback, it's important to understand why and address it). The first few months you focus on delivering value without rocking the boat. You probably don't have enough context to make any meaningful changes anyway. Then when it's time to groom stories, you select the time it takes to do a proper job, to make I improvements, and as long as it's not ridiculous, who's going to challenge you on it, and based on what?

Of course, you need to pick the right battles. Sometimes that hack to fix a production issue will stay like that for ages, and the proper fix will never be done, and that's the way it is.