4 ms·

Thing is, they do, but not in the ways you would expect. Cadavers on medical schools. Wind tunnel modeling. Computer-aided designs. The main difference to thos

by tmcb 7y ago

Thing is, they do, but not in the ways you would expect. Cadavers on medical schools. Wind tunnel modeling. Computer-aided designs. The main difference to those is that the software industry can indulge on testing its own assets with little to no cost, and especially if that does not impact your ability to generate revenue.

mdorazio 7y ago
There's a rather big difference between breaking things in a test & learning environment (all of the examples you provided) and breaking things in a production release.
- tmcb 7y ago
  There is also a big difference between a profession that respects the intelligence of their peers and one where people assume that their peers are ignorant and lack common sense. Surgeons must act fast and be good at multitasking. I bet they are not in a forum discussing if those traits make them vulnerable to hasty decisions and to loss of concentration on the task at hand.
  - mdorazio 7y ago
    I'm genuinely not sure what your point is. Can you explain it? The two surgeons I know generally have extreme trust that their tools, monitors, etc. will "just work" when and where they are needed, every time, and that those things have been properly vetted by the medical industry and community prior to going into a live hospital environment unless it's specifically known that they are testing something new.
    - tmcb 7y ago
      It is an analogy. I will move on to another one. Competent developers, on the other hand, have extreme trust on the judgment of their peers. They know they won't break the production build at will; if they ever do, they will use all information gathered to improve the team's infrastructure and their own development process. They are not afraid of using the term, because breaking things is the most valuable thing that you can do for your learning, but, most importantly, they realize that other people's lives and goods are potentially at stake, and act with due diligence. So, "break things" is not an excuse to break the production build at will and move on to the next task. If competent developers ever find themselves in a team that does so, they try to educate the team and, if that does not work, GTFO.
Finnucane 7y ago
Right, because who cares if it's broken crap as long as it's generating revenue.
- tmcb 7y ago
  This sarcastic remark is entirely misguided. Broken crap does not generate revenue; working code does. But, oftentimes, no code is as effective as broken code, and takes longer to fix. This is when you should use your judgment. “Break things” is not the same as committing faulty code, it just means that validating some of your hypotheses in a controlled environment may have a higher cost. Just to make things clearer, I am a programmer myself, and have never been in a management position before. My overall impression is that I learn faster when I make mistakes and need to fix them. Expecting otherwise would contradict most of the experts on human learning.
- scarejunba 7y ago
  Actually, exactly. I'm in the business of writing software that's useful to people. The way they tell me it's useful to them is by paying me. At any point you may determine it isn't useful to you. Just don't pay me.

by tmcb 7y ago

mdorazio 7y ago

There's a rather big difference between breaking things in a test & learning environment (all of the examples you provided) and breaking things in a production release.

tmcb 7y ago
There is also a big difference between a profession that respects the intelligence of their peers and one where people assume that their peers are ignorant and lack common sense. Surgeons must act fast and be good at multitasking. I bet they are not in a forum discussing if those traits make them vulnerable to hasty decisions and to loss of concentration on the task at hand.
- mdorazio 7y ago
  I'm genuinely not sure what your point is. Can you explain it? The two surgeons I know generally have extreme trust that their tools, monitors, etc. will "just work" when and where they are needed, every time, and that those things have been properly vetted by the medical industry and community prior to going into a live hospital environment unless it's specifically known that they are testing something new.
  - tmcb 7y ago
    It is an analogy. I will move on to another one. Competent developers, on the other hand, have extreme trust on the judgment of their peers. They know they won't break the production build at will; if they ever do, they will use all information gathered to improve the team's infrastructure and their own development process. They are not afraid of using the term, because breaking things is the most valuable thing that you can do for your learning, but, most importantly, they realize that other people's lives and goods are potentially at stake, and act with due diligence. So, "break things" is not an excuse to break the production build at will and move on to the next task. If competent developers ever find themselves in a team that does so, they try to educate the team and, if that does not work, GTFO.

Finnucane 7y ago

Right, because who cares if it's broken crap as long as it's generating revenue.

tmcb 7y ago
This sarcastic remark is entirely misguided. Broken crap does not generate revenue; working code does. But, oftentimes, no code is as effective as broken code, and takes longer to fix. This is when you should use your judgment. “Break things” is not the same as committing faulty code, it just means that validating some of your hypotheses in a controlled environment may have a higher cost. Just to make things clearer, I am a programmer myself, and have never been in a management position before. My overall impression is that I learn faster when I make mistakes and need to fix them. Expecting otherwise would contradict most of the experts on human learning.
scarejunba 7y ago
Actually, exactly. I'm in the business of writing software that's useful to people. The way they tell me it's useful to them is by paying me. At any point you may determine it isn't useful to you. Just don't pay me.