4 ms·

> If you are afraid to associate a decision with your reputation then somebody will make the decision for you. It is better to make a wrong decision early than

> If you are afraid to associate a decision with your reputation then somebody will make the decision for you. It is better to make a wrong decision early than to put that decision off to a future time. A wrong decision in the short term results in learning that can result in corrective decisions that would otherwise be absent. While I agree with everything else you said, I can't disagree with this more. If someone else is more qualified or better able to make a more informed decision than you are, then let them! Why worry about whether it was you or someone else who made the decision, when the real focus should be on maximizing the right decisions. Furthermore, how do you know that a wrong decision early is better than putting a decision off until a future time? While I can think of some cases where this is true, I can also think of a LOT of cases where this is absolutely untrue. Some wrong decisions can be very damaging and irreversible. There are also many decisions that don't affect anyone adversely the later they're made up until some ultimate deadline (like turning in homework when you're younger, or filing applications for an RFQ, or many other similar things); the only reason to finalize decisions for these kinds of things earlier than necessary is to ease your own cognitive overhead rather than actually being better for anyone else. The hard part about making decisions often isn't just the decision itself, but also in understanding the risks and trade-offs of making a potentially wrong decision now, versus making a better informed decision at a later time, and deciding which is the better approach for any given decision that needs to be made.

austincheney 6y ago
> If someone else is more qualified or better able to make a more informed decision than you are, then let them! That is called delegation of responsibility. If you are not qualified to make a certain professional decision or if such a decision exceeds your delegated responsibility then you need to bring somebody else in, possibly a supervisor. That consideration is itself a decision and it should not be delayed. https://en.wikipedia.org/wiki/Delegation https://en.wikipedia.org/wiki/Delegation > Furthermore, how do you know that a wrong decision early is better than putting a decision off until a future time? Exactly. You have no idea until you can determine the result. If you fail early and have the awareness to recognize that failure you are in a far stronger position for all forthcoming decisions. If you wait to make that decision all the time between now then remains an unknown and you also aren't completing any resulting actions. So not only does risk increase but your productivity proportionally decreases. It makes sense to wait on a decision only when that decision is both critical and costly and even then the only advantage on waiting is to perform further investigation. There is no advantage in hesitation only for the sake of hesitation, because then you are allowing external factors to influence the conditions away from what you currently know. > The hard part about making decisions often isn't just the decision itself, but also in understanding the risks and trade-offs of making a potentially wrong decision now This isn't something that software developers are well equipped for. Other industries have specific processes and criteria for evaluating risk in a uniform and standard way as well as the processes to apply the proper controls. These are basic trade practices that are often affirmed through education and licensing with bodies of enforcement. Software, on the other hand, does not have a commonly recognized ethics enforcement/evaluation body to define these trade practices. In practice most of this is outsourced to security professionals, for example people holding one of the various ISC2 certifications: https://www.isc2.org/ethics/ https://www.isc2.org/ethics/
- JangoSteve 6y ago
  > That is called delegation of responsibility. If you are not qualified to make a certain professional decision or if such a decision exceeds your delegated responsibility then you need to bring somebody else in, possibly a supervisor. Delegation more often happens toward subordinates than supervisors, but I don't see how that's relevant. My response here was to your statement that, "If you are afraid to associate a decision with your reputation then somebody will make the decision for you." I was pointing out that someone else making the decision for you isn't necessarily a bad thing as you seemed to be implying. > That consideration is itself a decision and it should not be delayed. You seem to be arguing here just for the sake of arguing, even if it means arguing against your original point. By the same logic you're using here, the decision to procrastinate can itself also be a decision, which is actually the entire point of my post. > Exactly. You have no idea until you can determine the result. If you fail early and have the awareness to recognize that failure you are in a far stronger position for all forthcoming decisions. If you wait to make that decision all the time between now then remains an unknown and you also aren't completing any resulting actions. So not only does risk increase but your productivity proportionally decreases. Your reasoning seems to rely on the premise that you can only learn by making a decision, which isn't true at all. You can also learn by research, which you have more time to do by delaying a decision. Even without research, there are many things you can learn just by allowing more time to pass and more events to unfold without any deliberate action on your part. An example of this could be something like submitting an application that's ready today for an RFQ from a large potential customer that isn't due for another month. Then, 2 weeks from now you find out from an acquaintance who used to work for that customer that they always valued some other piece of information being included in the RFQ submissions they review. I can't tell you how many times I've run into similar situations, and procrastinating improved the quality of the final result. Similarly, most of the time, you'll only ever have more information available to make decisions the longer you wait, not less. > It makes sense to wait on a decision only when that decision is both critical and costly and even then the only advantage on waiting is to perform further investigation. There is no advantage in hesitation only for the sake of hesitation, because then you are allowing external factors to influence the conditions away from what you currently know. You're arbitrarily asserting here that external factors can only influence the conditions away from what you currently know. External factors can also influence conditions toward what you currently know. Furthermore, the longer you wait, the more you'll know, which means the more informed your decisions will be. > This isn't something that software developers are well equipped for. Other industries have specific processes and criteria for evaluating risk in a uniform and standard way as well as the processes to apply the proper controls. These are basic trade practices that are often affirmed through education and licensing with bodies of enforcement. Software, on the other hand, does not have a commonly recognized ethics enforcement/evaluation body to define these trade practices. In practice most of this is outsourced to security professionals, for example people holding one of the various ISC2 certifications: https://www.isc2.org/ethics/ https://www.isc2.org/ethics/ I have know idea what point you're trying to make here or how it's at all relevant. At the end of the day, I've had enough good decisions come as a result of waiting to make them when I can to know that what you're prescribing isn't a universal truth, which was the point I was trying to make clear. I've also had plenty decisions turn out to be the wrong decisions, which I would have known if I'd waited another day or two to make them, further reinforcing that quick decisions aren't always better than delayed decisions. Again, the hard part is figuring out when it's better to make a quick decision and when it isn't.

austincheney 6y ago

> If someone else is more qualified or better able to make a more informed decision than you are, then let them! That is called delegation of responsibility. If you are not qualified to make a certain professional decision or if such a decision exceeds your delegated responsibility then you need to bring somebody else in, possibly a supervisor. That consideration is itself a decision and it should not be delayed. https://en.wikipedia.org/wiki/Delegation https://en.wikipedia.org/wiki/Delegation > Furthermore, how do you know that a wrong decision early is better than putting a decision off until a future time? Exactly. You have no idea until you can determine the result. If you fail early and have the awareness to recognize that failure you are in a far stronger position for all forthcoming decisions. If you wait to make that decision all the time between now then remains an unknown and you also aren't completing any resulting actions. So not only does risk increase but your productivity proportionally decreases. It makes sense to wait on a decision only when that decision is both critical and costly and even then the only advantage on waiting is to perform further investigation. There is no advantage in hesitation only for the sake of hesitation, because then you are allowing external factors to influence the conditions away from what you currently know. > The hard part about making decisions often isn't just the decision itself, but also in understanding the risks and trade-offs of making a potentially wrong decision now This isn't something that software developers are well equipped for. Other industries have specific processes and criteria for evaluating risk in a uniform and standard way as well as the processes to apply the proper controls. These are basic trade practices that are often affirmed through education and licensing with bodies of enforcement. Software, on the other hand, does not have a commonly recognized ethics enforcement/evaluation body to define these trade practices. In practice most of this is outsourced to security professionals, for example people holding one of the various ISC2 certifications: https://www.isc2.org/ethics/ https://www.isc2.org/ethics/

JangoSteve 6y ago
> That is called delegation of responsibility. If you are not qualified to make a certain professional decision or if such a decision exceeds your delegated responsibility then you need to bring somebody else in, possibly a supervisor. Delegation more often happens toward subordinates than supervisors, but I don't see how that's relevant. My response here was to your statement that, "If you are afraid to associate a decision with your reputation then somebody will make the decision for you." I was pointing out that someone else making the decision for you isn't necessarily a bad thing as you seemed to be implying. > That consideration is itself a decision and it should not be delayed. You seem to be arguing here just for the sake of arguing, even if it means arguing against your original point. By the same logic you're using here, the decision to procrastinate can itself also be a decision, which is actually the entire point of my post. > Exactly. You have no idea until you can determine the result. If you fail early and have the awareness to recognize that failure you are in a far stronger position for all forthcoming decisions. If you wait to make that decision all the time between now then remains an unknown and you also aren't completing any resulting actions. So not only does risk increase but your productivity proportionally decreases. Your reasoning seems to rely on the premise that you can only learn by making a decision, which isn't true at all. You can also learn by research, which you have more time to do by delaying a decision. Even without research, there are many things you can learn just by allowing more time to pass and more events to unfold without any deliberate action on your part. An example of this could be something like submitting an application that's ready today for an RFQ from a large potential customer that isn't due for another month. Then, 2 weeks from now you find out from an acquaintance who used to work for that customer that they always valued some other piece of information being included in the RFQ submissions they review. I can't tell you how many times I've run into similar situations, and procrastinating improved the quality of the final result. Similarly, most of the time, you'll only ever have more information available to make decisions the longer you wait, not less. > It makes sense to wait on a decision only when that decision is both critical and costly and even then the only advantage on waiting is to perform further investigation. There is no advantage in hesitation only for the sake of hesitation, because then you are allowing external factors to influence the conditions away from what you currently know. You're arbitrarily asserting here that external factors can only influence the conditions away from what you currently know. External factors can also influence conditions toward what you currently know. Furthermore, the longer you wait, the more you'll know, which means the more informed your decisions will be. > This isn't something that software developers are well equipped for. Other industries have specific processes and criteria for evaluating risk in a uniform and standard way as well as the processes to apply the proper controls. These are basic trade practices that are often affirmed through education and licensing with bodies of enforcement. Software, on the other hand, does not have a commonly recognized ethics enforcement/evaluation body to define these trade practices. In practice most of this is outsourced to security professionals, for example people holding one of the various ISC2 certifications: https://www.isc2.org/ethics/ https://www.isc2.org/ethics/ I have know idea what point you're trying to make here or how it's at all relevant. At the end of the day, I've had enough good decisions come as a result of waiting to make them when I can to know that what you're prescribing isn't a universal truth, which was the point I was trying to make clear. I've also had plenty decisions turn out to be the wrong decisions, which I would have known if I'd waited another day or two to make them, further reinforcing that quick decisions aren't always better than delayed decisions. Again, the hard part is figuring out when it's better to make a quick decision and when it isn't.