On Making Tech Decisions
Adarsh.K.Kumar Aug 17
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.
1) A computer program that is used will be modified.
2) When a program is modified, its complexity will increase, provided that one does not actively work against this.
When a software is modified it's disorder or entropy tends to increase.
-Courtesy Wikipedia09:47 AM - 08 Aug 2018
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.
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.
With all that being said, I still sometimes feel that Fear of the dark !!!
given dark='make decision'