It's been few weeks since a new post was published in the series of learning from mistakes. In the first two posts, we went through what could go wrong if you jump into coding without understanding the problem statement and start making too many assumptions.
The next thing on the list is a very common mistake that even experienced programmers make—and that is—not thinking about alternative solutions.
Once you have a clear understanding about the problem statement, you start designing a solution around it. I've seen that quite often, programmers start implementing the first solution they derived for the problem. I've to admit, I've been into this category for initial years in my career, until one day where I had to fill in design document template where there was section titled—rejected alternatives—and that helped me understand that I am doing something wrong.
Thinking about alternative solutions enables you to reduce the chances that you may fail to notice something important—as you will be thinking about different options in the given context, and asking questions to get more details. It also helps you figure out what is important to the end user. For example, in some cases—UI design is less important for end of day batch jobs, but focus needs to be on performance of processing data.
It could also help you avoid reinventing the wheel and you may just need to integrate with some existing component, it all depends on the context though. My point here is to try thinking about alternative solutions, ask questions, talk to people who are experienced in that domain— be it a technical or functional.
It also helps your stakeholders understand why the solution you are proposing is best fit as compared to other alternatives.
Have you been making any of these mistakes?
Top comments (0)