In this post, I will share some lessons that I took while reading this amazing book. The book It's not a recipe for time management nor a self-help book. It's about how to become an Essentialist. A book that teaches how to maximize your time doing what matters for you. I can say that is one of the best books I have read and that I fully recommend. The books say:
“Remember that if you don’t prioritize your life someone else will.”
Read that book give me a clear overview of how much time we lost time doing useless stuff. I took some lessons from it and can be applied to software development.
Lesson #1: Less can be better
The true Essentialist pursues this principle. It´s not how to get more things done but getting the right things done. How many times we are tented to add just more one feature ? or design and implement something that we thought was useful but the user never used.
Often one decision that we make leads us to a dozen future decisions. In software development, this concept is closely related to the agile principle 'Less is more'.
Lesson #2: Apply the Essentialist approach
Explore and Evaluate
Spend as much time as possible evaluating and exploring the options. Listen to the user and coworkers, spend time questioning, thinking and debating. Exploration is not the end of the road, but the way to select the important things.
Eliminate
Eliminate activities and effort that you are not sure whether it brings value to your product or end-user. Sometimes is hard to cut things off, we are tented to add cool features. But remember Less but better!
Execute
Remove the obstacle and making the execution as easy as possible. Spend the necessary time to set up the necessary environment before start the work. The CI/CD pipeline should be ready, the old unit tests working, the user's stories defined and so on. This will prevent stops during the development and make the coding more enjoyable.
Lesson #3: Keep the focus
Avoid any task that is misaligned with what you are doing or the goal you are intending to achieve. Keep the focus on doing what you plan to do. Do not refactor an unrelated set of classes when it is not related to what you are doing. Or prefer to report a bug than fixed without telling people about it.
This post was originally released on my Blog. If you have any doubts or questions feel free to drop a comment here or reach me out on Twitter @educostadev.
Top comments (0)