I recently finished reading Range - Why Generalists Triumph in a Specialized World by David Epstein. It wasn’t exactly a new topic. It was recommended in Bill Gates' blog so I was curious about it and picked it up. The book talks about (hyper)specialization vs broad thinking in career as well as life. I had read one perspective about this in other books like ‘Talent is Overrated’ by Geoffrey Colvin, and Cal Newport’s ‘So Good They Can’t Ignore You’.
This book offers a different perspective. It’s quite a myth-buster about the 10000 hours theory or deliberate practice. It explains how the hyperspecialization of narrow skills can be harmful to your long term growth. David kept me engaged throughout the book, even though sometimes the content kept on dragging the same message. It also felt relevant to my experience in life and career. I have been a sort of generalist, trying out different things like software engineering, solution architecture, or pre-sales over the last 20 years in my career. I intentionally avoided sticking to a single tech stack or framework or career track. And sometimes felt bad (or incompetent) being a jack of all trades type of a person. Turns out it isn’t bad to be that guy. In a way, I felt vindicated of everything I have done so far.
The key messages that stuck with me were about the experimentation and match quality - the term used to describe the fit between work someone does and their abilities. Everyone progresses at a different rate, so feeling behind doesn’t help much. Most likely you don’t know where exactly you are going. In this situation, the proactive pursuit of match quality, experimentation with different things, learning and adjusting as you go is the best approach. Comparing yourself to (cherry-picked) younger people doesn’t help either. Instead, compare yourself to your yesterday’s self and see how you are progressing. Epstein provides a good framework and reason to encourage range (rather than depth) over different areas of interest and stay curious.
As noted above, some of the repetitive content could’ve been edited to make it more concise. But other than that it was a fun and enjoyable read.
I like to keep my code clean, understandable, and readable. It helps the next person who will take over my work. I try my best to avoid any trouble reading, maintaining, and updating the code.
There are recommended and well known best practices about organizing Mule code. It involves better structuring of the project, maintaining configuration files, hiding or securing sensitive information like passwords and API keys, transaction management, or reconnection and caching strategies.
The lesser-known trick is about externalizing SOQL and SQL queries. Before I knew this trick I organized my SQL queries in properties files, and used spring placeholders like ${account.query} or dataweave Mule::p function to inject or read the queries in the code. It is not an elegant approach. It made the properties file difficult to manage and read. Then I discovered ${file::} notation to inject the queries. It offers a much better way to externalize the queries.
Using this notation is easy. In your Mule app, organize your queries in the src/main/resources folder in their own files as shown below.
Once you organize your queries properly, injecting those queries is easy.
This organization helps in keeping the XML configuration file readable and easily maintainable.
I discovered that the easiest way to start drinking more water is to always keep a water bottle with me. Before going to bed, I keep a bottle of water next to the bed. The idea is, when I wake up, the first thing I see is the water bottle. I drink that bottle before getting out of bed. This system helps me get a significant headstart in meeting my daily water drinking quota.
A few years back I was consulting for a client in Minneapolis. I traveled every other week to Minneapolis to work from their office. I worked with them for almost a year. It was fun and enjoyable work. During that time I developed a good camaraderie with my colleagues there. When I started working with them I noticed that they had a similar - effortless - system to drink more water during office hours.
Our office in Minneapolis was a repurposed shopping complex. It was a huge single-story building with a large parking place all around it. Our sitting arrangement was based on the ‘open office’ concept. In this arrangement, each team would get a or working area - but not individual cubicles for each team member. This improves the collaboration and communication within the team. Our working area was in one corner of the building. It was diagonally opposite to the cafeteria, which was located in another corner of the building. There was a water fountain nearby our working area. My colleagues followed a system to only get water from the cafeteria, or the water-fountain near the cafeteria. Like clockwork, we used to get up every couple of hours, walk to the cafeteria, refill our bottles, and get back to the desk. Without consciously putting any effort, or setting specific goals, this simple system ensured that we drink enough water throughout the day. The other advantage was getting some sunlight and fresh air when the weather was nice. Or simply getting out of the chair and get our bodies moving. Drinking more water also ensured more restroom visits, so that was an additional ‘get out of the chair’ bonus. When I was not in the office, and working from home, I didn’t drink enough water. I did not have an effortless system in place to develop this habit.
My brain is lazy. It wants to conserve energy. And so instead of looking at each problem and providing an appropriate solution, it falls into usual patterns. To develop a good habit, I need to have an effortless system. It should be simple. e.g. Keeping a water bottle with me.
