You're not wrong ;-). There are in fact some solid arguments to ask for forgiveness rather than permission when it comes to decision making in software engineering. This comes up whenever you are faced with uncertainty, i.e. all the time. Given uncertainty, you can do two things: 1) wait for more facts to emerge and/or undertake work to reduce the uncertainty. 2) take decisive action based on what you know now.
Unless #1 can be achieved quickly, efficiently and cheaply #2 is often the better way to go because it gets you results faster (good or bad) and time spent waiting costs you in several ways that you can't compensate for by getting it right later. E.g. shipping a month late has real cost in the form of revenue not realized as well as expenses on e.g. your team and anything supporting and depending on it. Worst case you get it wrong and then adapt, which might still be faster. Finally, there is a notion of good enough. Not everything has to be perfect.
That doesn't mean you should blindly go with what your gut is telling you all the time but it does mean that being mindful that time spent debating and analyzing is not always worth it. What is worth spending time on is verifying whether you got things right or wrong after the fact. Because if you get it wrong, you still need to fix it. And to do that, you need to know you got it wrong. To know that you need fast feedback loops. Which is why CI and CD are not optional these days. They facilitate fast decision making and risk management associated with that. Getting something wrong and finding out a year later is a problem. Shipping something wrong and fixing it on the same day is much less of an issue and vastly reduces the scope and impact of any issues.
Finally, developing software is a team game. No matter what you do, get some buy in and be willing to compromise with others. The flip-side of going with your own opinions is that you sometimes have to rely on somebody else's opinion when that conflicts with your own opinions. Some of the most difficult decisions I've made were acknowledging other team members needed the space to do things I did not fully agree with. If that then goes wrong, it's just another problem you deal with as a team. You adapt and move on. Playing the blame game is generally not very productive. If things go right on the other hand, acknowledging that is actually a good thing. Simply expressing that, "hey I did not fully agree with this at the time but looks like you were right" can make all the difference when some time later you need that person's support on another opinion based decision.
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.
You're not wrong ;-). There are in fact some solid arguments to ask for forgiveness rather than permission when it comes to decision making in software engineering. This comes up whenever you are faced with uncertainty, i.e. all the time. Given uncertainty, you can do two things: 1) wait for more facts to emerge and/or undertake work to reduce the uncertainty. 2) take decisive action based on what you know now.
Unless #1 can be achieved quickly, efficiently and cheaply #2 is often the better way to go because it gets you results faster (good or bad) and time spent waiting costs you in several ways that you can't compensate for by getting it right later. E.g. shipping a month late has real cost in the form of revenue not realized as well as expenses on e.g. your team and anything supporting and depending on it. Worst case you get it wrong and then adapt, which might still be faster. Finally, there is a notion of good enough. Not everything has to be perfect.
That doesn't mean you should blindly go with what your gut is telling you all the time but it does mean that being mindful that time spent debating and analyzing is not always worth it. What is worth spending time on is verifying whether you got things right or wrong after the fact. Because if you get it wrong, you still need to fix it. And to do that, you need to know you got it wrong. To know that you need fast feedback loops. Which is why CI and CD are not optional these days. They facilitate fast decision making and risk management associated with that. Getting something wrong and finding out a year later is a problem. Shipping something wrong and fixing it on the same day is much less of an issue and vastly reduces the scope and impact of any issues.
Finally, developing software is a team game. No matter what you do, get some buy in and be willing to compromise with others. The flip-side of going with your own opinions is that you sometimes have to rely on somebody else's opinion when that conflicts with your own opinions. Some of the most difficult decisions I've made were acknowledging other team members needed the space to do things I did not fully agree with. If that then goes wrong, it's just another problem you deal with as a team. You adapt and move on. Playing the blame game is generally not very productive. If things go right on the other hand, acknowledging that is actually a good thing. Simply expressing that, "hey I did not fully agree with this at the time but looks like you were right" can make all the difference when some time later you need that person's support on another opinion based decision.