I was always afraid to make decisions, even a simple one. Most of it was because I was afraid to be wrong.
What will others think of me ? + Imposter syndrome.
We discuss our ideas with our team and then come to a conclusion based on :
- Points discussed by the team/pair.
- Evaluating pros & cons.
- The collective intellect of the team.
We did the best we can, with the knowledge we had at that point in time
No person will take a decision to knowingly harm the project.
Now this decision can be right or wrong. If its wrong one must not start a blame game or point fingers. Its a sign of toxic workplace and senior folks/"manager" must identify and solve such issues at the earliest. If not, others in team who might have good ideas/solutions just keep quite and later quit because they are afraid of being shamed.
Liquid error: internal
A software as long as its used will go through continuous evolution. Now it depends how you handle the changes. If you think of short term and pushes changes with bad design and no tests because you don't have time, Its fine just ensure this tech debt is addressed as soon as your urgency is taken care of. But if one urgent/"no-time" issues comes after another and you forget about the tech-debt it will bite you back. Something is terribly wrong with project/product management in this case.
Ajey Gore@ajeygore
If you don't stop to pay the tech debt, the tech debt one day will stop you to repay it.
There will be debt recovery, and you might not want to go there.
Pay your tech debt on time!!!05:58 AM - 16 Aug 2018
Fail fast -> Learn -> Improve
Right or wrong we learn from the decisions we make.We discover data points which we didn't have earlier.But waiting without making no decision is no progress we are just delaying obvious disaster to happen.
So when we figure out the decision we made was wrong, simply take the corrective step and evolve the software. Principles that aid in this are TDD/Refactoring. If we have enough test coverage one can confidently do a refactoring. The books Test Driven Development by Example and Extreme Programming Explained by Kent Beck are really good resources for learning these techniques. Another book is Refactoring Improving the Design of Existing Code by Martin Fowler.
Now that being said, one should not make same mistake twice that's waste of time.
And if you don't know something, you should reach out and talk to people to learn from similar situation faced by them so that we don't make the mistake they might have made.
Most confusions or problems in a Software can be avoided if we just communicate/"talk" with other people "ASK" for help.
Richard Feynman@proffeynmanIt's OK to say, "I don't know." It is of great value to realize that we do not know answers!15:15 PM - 06 Aug 2018
With all that being said, I still sometimes feel that Fear of the dark !!!
given dark='make decision'
Top comments (2)
When people ask me to make decisions, they're usually looking for a simple response. Something on the order of a basic "yes/no" or "which of these X things would you pick". For better or worse, that's not my style. Never has been. So, whenever people ask me for a decision, what they usually get back is something on the order of:
...and then finally "here's what I chose based on the above". I prefer that people understand why I made a given decision. That way, they have not just the decision/recommendation but its basis. Provides more background on whether the decision/recommendation is valid for why they were asking.
Plus, it provides a measure of CYA. Months down the road you can dig up that email/Slack/etc. conversation to answer the "why the hell did we do this" question if something went wrong or went a different direction than some thought it would. =)
This is a really good point, we usually maintain Architecture Decision Records, usually in markdowns or adoc in a documentation git repo and share that in a mail.