The Journey; Amateur to Expert and the mistakes

Photo by Jefferson Santos on Unsplash

Among the people who love to code, there are amateurs and experts, and then there are people who are on the journey towards becoming an expert. I think I have been on that journey for a few years now. For me, the expert developer is not someone who knows a framework/language in and out but someone who knows how to approach a specific problem. Being an expert is not about knowing the solution to every problem but understanding how to learn, adapt and implement. So when does someone become an expert developer/ Engineer? I guess you will only know when you are one. But do not get caught up on that, enjoy the journey and strive to become a better developer every day.

When you are 9 - 12 months into your career, you generally go past the beginner’s level and start the growth phase. You would have accumulated enough knowledge to grasp advanced concepts, and this typically is when you would make some fundamental mistakes. The growth phase is tricky; you get exposed to a lot of ideas, best practices, and methodologies. You read a lot, hear from a lot of peers and experts. This information overload can be little overwhelming for some people. You try to do a lot of things and can miss out on some fundamentals. This write-up is about few such mistakes that developers in their growing stages make and how you can avoid it.

Constructing a Mind Map

Before you rush to fire up your favorite IDE, consider having a clear picture of what problem you are trying to solve and how you are going to do it. What are the drawbacks of the current system? And how can all that be dealt with, while at the same time building the simplest possible solution?. Based on all the data formulated you prepare an execution strategy, divide it into submodules, estimate and schedule the timeline.

And once you start working on it, always have the mind map of the product you are going to build, the bigger picture, dependencies and general whereabouts. Imagine you are designing and creating a new payments system for your product, it’s always helpful to keep in mind a visual representation of logic and data flow of the new framework and how it interacts with the current invoicing and tax systems.

Simplicity over Contentment

Often, it so happens that the problem you need to solve is elementary and straightforward. You collect the requirements from the business team, and you plan and estimate few hours of work, and it’s good to go. It’s then, that crazy ass egoistic mind of your ’s start to play games. How can I implement something so simple?. My code cannot look so dull! After all, we are engineers; we love building complex sophisticated solutions.

So convinced that the output cannot be, or rather should not be simple you carry forward with an unusual method of implementation and end up with unmaintainable code and you, of course, achieve a sense of accomplishment. However, at this point, you have already forgotten that you should solve complex, sophisticated problems rather than be making your solution another problem.

Premature Optimization

Optimization without first measuring is almost always premature. But I think that Donald Knuth’s above statement gets misinterpret most of the times. It should not be an excuse for writing poor code. I believe the comment should be more suited as premature micro-optimization is the root of all evil. We still need to do the macro optimization with good architecture, database design, data flow, etc. Almost 90 percent of the optimization should happen at the architecture level. Even while deciding the algorithm and data structure, you should make informed decisions. Things like choosing an O(log N) algorithm instead of O(N²) are often worthwhile and should be considered early.

Optimization almost always involves a cost of time and maintenance. Hence it is wise to identify the problem and analyze it before working on it. Taking two weeks to optimize a function which runs once a day by ten milliseconds is not an optimization, it’s overkill!. That being said micro-optimizations are not always bad. But doing it at the wrong time in the development cycle may severely affect your productivity.

Make it Work, Make it Right, Make it Fast — Kent Beck

References

• Structured Programming With Go To Statement
• Kent Beck
• Premature Optimization -1
• Premature Optimization -2