Good ol' Last Responsible Moment (LRM). I remember when an old boss of mine tried to explain this concept to me; I certainly didn't grasp it's importance right away.
To Ben's point around convincing others, I think it all goes back to knowing that you don't know enough and being able to explain that uncertainty to others. This should hopefully help drive establishing better requirements early on so you can actually make the right decision. And if that cannot be answered, it could be a good sign to GTFO before everything falls apart or you have to deal with mountains of tech debt with little to show for it.
As to the problem of knowing when you don't know enough, that is a hard problem. Like you said in your post, one of the better method is to simply always be critical of your quick decisions. The cost of double checking your thinking early on is so minor compared to dealing with the fallout later on that it should really just become part of your own SOP.
The cost of double checking your thinking early on is so minor compared to dealing with the fallout later
That's a great way to put it. I find it's sometimes easy for me to get anxious taking a few days or a week to make what seems like a simple decision. It might feel simple at the time, but you're exactly right. There's a cost to double checking and a cost to living with that decision. Double checking is almost always cheaper. Oftentimes, what seems like a simple decision can spread rapidly throughout a code base to a point there's no turning back.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good ol' Last Responsible Moment (LRM). I remember when an old boss of mine tried to explain this concept to me; I certainly didn't grasp it's importance right away.
To Ben's point around convincing others, I think it all goes back to knowing that you don't know enough and being able to explain that uncertainty to others. This should hopefully help drive establishing better requirements early on so you can actually make the right decision. And if that cannot be answered, it could be a good sign to GTFO before everything falls apart or you have to deal with mountains of tech debt with little to show for it.
As to the problem of knowing when you don't know enough, that is a hard problem. Like you said in your post, one of the better method is to simply always be critical of your quick decisions. The cost of double checking your thinking early on is so minor compared to dealing with the fallout later on that it should really just become part of your own SOP.
That's a great way to put it. I find it's sometimes easy for me to get anxious taking a few days or a week to make what seems like a simple decision. It might feel simple at the time, but you're exactly right. There's a cost to double checking and a cost to living with that decision. Double checking is almost always cheaper. Oftentimes, what seems like a simple decision can spread rapidly throughout a code base to a point there's no turning back.