3 ms·

Eh, I do similar work, but find his whining tone intolerable.

osivertsson 12y ago
Yeah I agree the tone gets tiresome. Just explain it with a higher signal-to-noise ratio and avoid pausing all the time to whine. Developing software in a corporate environment under the constraints of capatalism often means average management and average coders both with a tight deadline. Trying to take shortcuts in such an environment is only human nature, and getting non-optimal designs and implementations then should be no surprise.
- nitrogen 12y ago
  We should be understanding of mediocrity, but we should never accept it as given. As an industry we need to do better -- push back on unrealistic expectations, demand the necessary resources, understand business needs and when they are unjustified.
  - osivertsson 12y ago
    Well said, and in my experience the best way to achieve all this is to let devs have direct contact with end users. Getting the knowledge first hand on what problem they are really trying to solve with your help, and how small tweaks here and there can make them more efficient etc. really gives most devs a sense of urgency. What is required is done, but no more since devs want to put the new version quickly into the hand of the users in the hope that they'll like it. The complete opposite is fixed requirements specifications and many layers between devs and users. This will get expensive and easily quite mediocre when devs know they are not really building the product the end user needs since motivation so easily falters in such an environment.
AlyssaRowan 12y ago
I found it pretty amusing. You should know well that reversing really really ugly "here be dragons" code is full of even slightly more frustration than writing it. It's reasonable to communicate that frustration. Hopefully we can avoid it in future, a little bit. I assume that the comment at the end - that this vendor tool was probably a hurried, barely-documented port of a DOS tool (which would have been safer 'because DOS doesn't do anything') - is probably right on the mark.

Yeah I agree the tone gets tiresome. Just explain it with a higher signal-to-noise ratio and avoid pausing all the time to whine. Developing software in a corporate environment under the constraints of capatalism often means average management and average coders both with a tight deadline. Trying to take shortcuts in such an environment is only human nature, and getting non-optimal designs and implementations then should be no surprise.

nitrogen 12y ago
We should be understanding of mediocrity, but we should never accept it as given. As an industry we need to do better -- push back on unrealistic expectations, demand the necessary resources, understand business needs and when they are unjustified.
- osivertsson 12y ago
  Well said, and in my experience the best way to achieve all this is to let devs have direct contact with end users. Getting the knowledge first hand on what problem they are really trying to solve with your help, and how small tweaks here and there can make them more efficient etc. really gives most devs a sense of urgency. What is required is done, but no more since devs want to put the new version quickly into the hand of the users in the hope that they'll like it. The complete opposite is fixed requirements specifications and many layers between devs and users. This will get expensive and easily quite mediocre when devs know they are not really building the product the end user needs since motivation so easily falters in such an environment.

AlyssaRowan 12y ago

I found it pretty amusing. You should know well that reversing really really ugly "here be dragons" code is full of even slightly more frustration than writing it. It's reasonable to communicate that frustration. Hopefully we can avoid it in future, a little bit. I assume that the comment at the end - that this vendor tool was probably a hurried, barely-documented port of a DOS tool (which would have been safer 'because DOS doesn't do anything') - is probably right on the mark.