A bad plan is better than no plan
A long time ago, in a company far, far away, when I had only a couple of years of experience, I was sure I knew what the "right" way to code was. Each time I would learn a new rule, I would accept it as a divine truth. SOLID, Clean Code, "Tell, don't ask". I JUST read it, and I would immediately use it in my code and argue with others that this is the only way to write code.
Later in my career, when I had deepened my knowledge of coding principles, I had also learned new perspectives about coding. I have become less decisive. I still appreciate those principles, but I know there is more than one way to write good code (or architect a system). When discussing designs and architectures, I wouldn't rule out something immediately just because it wasn't the way I have learnt to do it.
Unfortunately, people link decisiveness with correctness. I got more appreciation from my colleagues and manager while I was a zealot than when I became more pragmatic. I was more vocal in meetings, stating the right way to solve the problem. Arguing why this is the best solution. But once I become more pragmatic, I would be less active in those meetings because I could appreciate the nuances more and would take more time to compare the suggestions, but at that time, the meeting ended. I seemed more engaged in my early years and more apathetic later.
Today, I am trying to lean more toward the fanatic state of mind. It helps me think faster, since I don't have to over-analyse each solution, but rather choose the solution that better meets THE principles. And it usually gives a good solution and a solution that people can relate to. It also makes me sound more decisive since I can better explain the reasoning behind my choice.
In conclusion, find yourself guidelines that you feel comfortable with and stick with them. They are not perfect, but perfect is the enemy of good.
Comments
Post a Comment