3 ms·

I think the use of "god-forsaken clusterfuck" was hyperbole, but frankly, if you're working on software that's necessary to enable the holiday rush, doing whate

I think the use of "god-forsaken clusterfuck" was hyperbole, but frankly, if you're working on software that's necessary to enable the holiday rush, doing whatever you have to do to get it out on time and then redoing the whole thing over the next 4-6 months is probably still the cost-effective solution. Engineering exists in corporate contexts to serve the purposes of the organization. If you believe that the entire focus of any engineering project should be crafting theoretically-robust software, you're either going to have retire early and pick it up as a personal hobby or go into academia.

pdimitar 10y ago
> you're either going to have retire early and pick it up as a personal hobby or go into academia. That's a strawman crafted by introducing a false extreme dichotomy. I don't think anyone claims they want to produce "theoretically-robust software". 99% of all programmers I've ever met and spoke with in real (or virtually), agree there's no such thing. What's discussed here (which admittedly is off on a tangent derived from the OP) is questioning the value of rushed software. There's a balance to be struck there and bending over to the managers and always trying to squeeze more in less time is always ending up in flames. 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.
- 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 ago
    I 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.

pdimitar 10y ago

> you're either going to have retire early and pick it up as a personal hobby or go into academia. That's a strawman crafted by introducing a false extreme dichotomy. I don't think anyone claims they want to produce "theoretically-robust software". 99% of all programmers I've ever met and spoke with in real (or virtually), agree there's no such thing. What's discussed here (which admittedly is off on a tangent derived from the OP) is questioning the value of rushed software. There's a balance to be struck there and bending over to the managers and always trying to squeeze more in less time is always ending up in flames. 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.

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