3 ms·
>I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth.
by cookiecaper 10y ago
>I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth.
I think the problem is you're conflating a recognition that software needs to get done and shipped with the surrender of good craft. Good craft _necessarily includes_ a recognition that your purpose of an employee is not to write beautiful software, and then to move on to make something good within reasonable time constraints anyway. Not perfect, not without warts or things to improve, but good.
When your chain of command knows you understand your job is to serve the company and not to indulge in impractical engineering excesses, they'll trust you much more and be more willing to give you the freedom you need to do something well. Balking any time they ask for a timeline is not the way to establish this.
- pdimitar 10y agoI think we might've misunderstood each other because I agree on all your points, plus I think I never constrasted deadlines with good results. That's the keyword indeed -- good software. Not amazing. What I kind of got from your previous comment was that if you resist being micromanaged, you're not a good professional. Apologies, it seems I misunderstood. IMO a good professional has to also know to hold their ground here and there. Nobody respects a bottom-licker who bows down at every request, that's basic human nature and no formal processes can nullify us reacting animal-like in these situations sometimes. I find that when I argue with my superiors that I am given too unrealistic of a deadline and argument myself well, their respect for me actually grows and they start trusting me more and pester me less. One of them told me "I love it that you don't bullshit your way out of meetings where you have to make a tough sell" and I think that sums up my approach best. TL;DR -- if both sides are willing to compromise to find the best value for the programmer's time and managers do NOT relentlessly insist you do things in the shortest time possible, then things go really well.