I recently stumbled upon Someday is Today and read it cover to cover over the weekend. The book was really fast paced and obnoxiously prescriptive; which is not the type of book that usually appeal to me.

Most self help books use this style of writing, where the story telling resolves around four simple steps: 1) The author tells you how miserable he once was. 2) He then tells you how successful he is now. 3) He tells you what worked for him or how he became successful. 4) He assumes that everything that worked for him will also work for you and if you don’t follow his advice you will never be successful in life.

It’s the same writing style most self help authors use. It’s also the same style most so called coaches and gurus selling YouTube courses on how to become a millionaire use; which is why I am not a big fan of this style of writing.

Fundamentally, there is nothing wrong with this style. A lot of TED talks also follow this style. I’ve myself written a book in this style back when I was younger. But as I grow older, I tend to lean towards a calmer, suggestive and research oriented tone rather than prescriptive voice when it comes to the articles, posts or books I love to read or write.

The steps involved in the suggestive (rather than prescriptive) style of writing usually are: 1) Here is one problem I was struggling with. 2) Here is what I tried that did not work. 3) Here is what I tried that I think may have worked; though I am still not hugely successful. 3) Here is some science behind it. 4) See if it works for you; no worries if it doesn’t. Results always vary. We are all different. I don’t have all the answers.

Someday is Today uses the former, self-help based prescriptive style of storytelling and generally speaking I would have stopped reading the book after it’s first chapter; but I continued because of a strong central idea that the book was built around. The idea that creativity is messy; creativity is a game of inches. That and the fact that the author is an excellent story teller.

In the end I was happy I read the book in spite of multiple over the top ideas that I did not agree with. By the time I was done, I had a few solid takeaways from the book. Nothing I did not know, but the information I already knew was crystalized into mental models and insights I could remember and reuse at will.

You can read the book if you have the time. Overall it’s a good book that provides a lot of insights about productivity. The book is really well written and dances on the fine line between healthy and highly toxic productivity without ever brazenly crossing that line.

For example, the author talks about reducing your shower time to less than ten minutes to increase productivity and you are left wondering how far this productivity rabbit hole goes. Should you stop taking showers every day to be productive? Should you just shower every other day? Once a week? And even if you do that, is that what we want to advice others and then insinuate that if they spend more than 5 minutes in a shower, they are “idiots”?

But then there is a lot of good advice in the book. For example, the author talks about why he chooses to be a primary school teacher and doesn’t run after promotions and corporate jobs because being a primary school teacher gives him time to be productive in areas that matter to him. If there is a fine line between healthy and toxic productivity, this book walks smack on that line without ever crossing it. It makes you uncomfortable, it also inspires you and best of all it makes you think about what productivity means to you and what regrets you might have as you approach the end of your life.

Here is my book summary of the central ideas and all the key takeaways that I found not only appealing but really useful:

You can download a PDF of my book summary here if you would like to keep a handy reference. You should definitely give this book a read. If you are too busy to read it now, I’m hoping the one pager will still give you all the insights and the key takeaways that I found particularly useful and make you a bit more productive.

I first started programming at age 10. I personally don't recall 'studying' programming languages formally. Most programming languages that I picked up, much like the five spoken languages I am comfortable with, I picked up by trying, tinkering, and applying them to solve real-world problems.

Lately, I've been mildly obsessed with the idea of learning new things. Recently, I learned how to juggle, I learned how to touch type, I learned how to play the piano and I learned how to drive a stick shift. Lessons learned from all of these adventures, translate well to learning something technical too – Whether you are learning how to play the piano or deep dive into machine learning, the basic steps to learning are the same 1) Break down a daunting topic into smaller topics; 2) Focus on one topic at a time and get the resistance out of the way to make practicing easy; 3) consistently learn every day – 20 minutes to an hour for a couple of months 4) profit.

However, when it comes to technical topics, apart from the steps mentioned above I've always followed a specific style of learning that works for me. I like to call this the Scattered Onion style of learning.

It's clearly something I did not invent (And ChatGPT tells me it's not even a real thing) but it is a style of learning that comes naturally to me. Ask ChatGPT what the Onion style of learning is and it provides this explanation:

In some contexts, when people refer to the "Onion Style of Learning," they may be alluding to a layered or gradual approach to learning, where one starts with a basic understanding or foundation of a topic and then gradually adds more depth and complexity, much like peeling the layers of an onion. In this interpretation, learners start with fundamental concepts and build upon them as they gain proficiency and expertise.

When I want to pick up a new topic, the steps that I follow are structured and simple. Every time I effectively end up learning a new topic I find myself repeating these steps. Each step is like pealing a layer of an onion. The steps/levels/layers of learning are:

Level 1: The Conceptual Layer – Answering The "What It Is" Question

For me this is foundational. I respect folks who can reach chapter 1 of a technical topic and move on to chapter 2. For me, the ground-level familiarity of a subject is much more important. This is very similar to the Feynman Method of learning where you a) pick a high-level topic b) understand it and try to explain it like you are teaching it to a child c) review and refine that understanding d) document that explanation and revisit it frequently.

Put simply, when I am picking up a topic my first attempt or layer of learning involves understanding what the topic is about. Take, for instance, Machine Learning. If you are reading this take a pause and try and answer the question "What is Machine Learning?" – not with the intention of answering the question, not with the intention of convincing someone that you know what it is, but really answering the question with the level of insight that will explain all the complexity of machine learning to a 12 year old who will just not be intimidated by technical jargon and will keep on asking you questions till they understand.

And no, a lame answer like Machine Learning is where machines can think like humans, does not qualify simply because you are explaining a complex topic to a 12-year-old. I've tried this with so many programmers and when I start asking them questions on some of the simplest topics, their explanations often start to break down. Most programmers today cannot answer fundamental questions like What really is object orientation, or what are interfaces; or even how simple loops work; not because they don't have an intuitive grasp but because they have never really given the question much time to think and develop their own insights to explain it simply. I don't blame them for it. Simplicity is hard. Understanding something in a way that you can explain it simply is harder.

Level 2: Where To Use It And More Importantly Where Not To Use It

After you can explain what something is, the goal is to take your understanding to a level where you not only know where to use the technology but where not to use it. After all, when the only tool you have is a hammer, everything looks like a nail. There are countless people (even really senior folks) who go completely blank in my interviews when asked the most fundamental questions about where you should not use a tech. For instance, a candidate who goes on and on about the Actor Model – starts fumbling all over the place when you ask them when they should not use actor-model or when someone is listing the benefits of messaging and you ask them to talk about a couple of situations where message queues are a bad idea. Again, I don't blame them for this. In today's world where we are all in a rush to pick up the next big thing, pondering about where it should not be used seems like a waste of time. But in reality, if you consider yourself a technologist, where not to use a tech, is as important as where you should use a technology.

Level 3: Drive The Car (Use the tech competently enough)

If you've ever driven a car hardly ever open the hood, you know exactly what I am talking about. Most programming languages have their nuances. But to start using them you don't need to know the nuances. You just need to know enough so that you can start using them. This is your gateway into mastery – because once you start driving the car a lot, sooner or later you may have a flat tire and may have to learn how to replace the tire; which over a period of time will make you wonder, how the hell does the wheel really work and why it took mankind 200,000 years to invent the freaking wheel? As you get familiar with a framework or a language you start asking questions like "Huh! I wonder how that works?" – but that comes later – In most cases though, you can simply be a good enough driver and still get from point A to point B. As the creator of the C Programming langue Dennis Ritchie is said to have put it:

The only way to learn a new programming language is by writing programs in it.

It's not true for only programming languages but for anything. Spoken Languages, driving a car, writing a book, playing a musical instrument. You become good at most things by not just learning, but doing them and actively engaging with them.

Level 4: Look Under The Hood – An Intuition about The Internals

Once you get sufficiently good at a tech, programming language, or platform and have used it enough you are bound to hit a few hiccups. You might come across JavaScript doing some pretty funky stuff for instance and you may be curious about what is going on. This is like changing the spark plug or your car, being able to replace the tire, or reading about the basics of a combustible engine.

Most people will stop at this level. I suggest you do too. Being at this level will put you way above most of the crowd, will end up making you look really smart (which may not be relevant), and will make you hugely productive (which is relevant). The good thing is, you can be at this level with a LOT of different topics and things. That will also allow you to connect the dots from other fields and draw learnings from completely disconnected things. Going any deeper, unless you are really passionate about a specific tech is a waste of your time.

Level 5: Inch Towards Mastery – The Ability To Make Your Own Car

This bit comes organically after years of commitment and most people don't really need to worry about this in all fields other than one of their own choosing. This is where you make a contribution to a Linux Kernel because you don't agree with the way it does memory management or you write your own language because you feel that none of the languages out there fit your requirement. This is where papers are supposed to be written, genuine patents are supposed to be filed and larger contributions are made to the community. This is a stage where you don't just drive a car or fix it's components, but can design and build your own cars. Mastery comes at a price so be very selective about topics where you want to achieve world class mastery.

The Central Idea Behind Stages

What's important to note here is that these are all different stages of learning. At every level, you are not learning new topics. Instead, you are going deeper into the same set of topics you started off with but are literally "digging deeper". So, if your topic was the Rust programming language – you would start off with: Layer #1: What is Rust? Layer #2: Where Should I use it and where should I not use it? Layer #3: How I can write a couple of system utilities using it? Then proceed to write a few low level utilities using it! Layer #4: Finally understand the nuances of the language – for example how the Borrow Checker really works.

Once you have done all of these and looked under the hood for a sufficiently vast array of topics connected to Rust, give yourself a pat on the back or a nice little intrinsic reward, consider yourself at level 4, and move on to the next topic. Level 4 is where you want to stop for most topics.

If you genuinely love the topic, you can take steps towards deliberately spending another 10,000 hours on it, and you will eventually achieve mastery in it – but pick that topic wisely because you don't have infinite time on this planet.

Approach And Process

For me personally, when it comes to layered learning, Approach that I take and the process that I follow is also equally important. Each person is different. These are a few other important tips work really well for me:

#1 Be Scattered - There are lots of folks who like to start one thing, finish it, and only then move on to the next thing. I respect these people. Power to them. My mind however is not that disciplined and structured. Being scattered is fundamental to my learning. On any given date I might be doing research on encryption algorithms for a patent disclosure, working on improving my lousy chess skills, learning Rust, dabbling with building a recommendation engine using a neural network, reading a deep psychology textbook and writing about what I learned from reading fictional story. On any given date, I have over a dozen threads open to choose from. Being scattered means that you are never bored. And you never have to force yourself to learn one thing. Don't feel like going deep into Gradient Descent? You can just have fun learning the complexities and variations of the Sicilian Chess Opening today and come back to Gradient Descent tomorrow.

Being scattered and having multiple threads of items always open means 1) you're never bored, 2) you never have to force yourself to pick a topic you don't like on any given time - you have a variety of things to pick from based on what you feel like working on that day and 3) as your interests evolve there is a democratic election of ideas that compete for your attention based on what you love doing where the best ideas or the ideas you are most interested in eventually win, which means a more fun filled life. There is a lot to be said about the science of being scattered. It is a whole new post in itself.

#2 Be Intentional – For me, when something gathers my interest and I decide to give it precious hours of my life, I must decide up front how many layers of that metaphorical learning onion I intend on pealing. So if you are starting to learn the piano at age 40, aiming for level 5 and aspiring to become a professional pianist may be an impractical idea. Being able to play a simple song by ear? That's a much more practical goal. Before you start learning how to play the piano, you know that you want to get to level 3 and then once you are there, you can either continue to stay there as a hobby and inch forward slowly for fun or just quit and move to something else.

#3 Be Mindful Of Diminishing Returns: In most things, 40 to 60 hours of deliberate practice will get you to level 3 which is when the laws of diminishing marginal returns start to kick in and unless you are really serious about the topic, it's time to drop out or just stay at that level for fun or effective productivity. There are a lot of people who know how to drive a car but know nothing about the mechanics of a car. They spend their life happily staying at level 3, without ever looking under the hood. Of course, if you are genuinely interested in the topic you can always probe deeper, but at every step it's important to be intentional about what you are trying to achieve. Once you are at level three every step forward requires considerably more effort. The fight against diminishing marginal returns is worth it, only for topics that you absolutely love.

#4 Define Your Learning Portfolio – What is your role? What do you do for a living? How important is depth for you? How important is breath? That decides your depth portfolio. For example, I work as a professional software architect. For me understanding a vast variety of tools, frameworks, and technologies is really important. As of today, if I list down all the topics in my resume and make a nice little pie chart of what my portfolio looks like it would look like this:

At any given time, when I am picking up things; 30% of my knowledge base is at level 2. I'm constantly reading about new technologies and frameworks being released, finding out what is new, what the tech does, why I should know about it, where I should use it, and where I should not use it. Not everything I read requires probing deeper than this.

Another 50% of my knowledge portfolio sits at level 3 – I can productively use the framework, write code, and solve real-life problems with it but I may not ever look under the hood actively (unless I want to solve a specific problem for which I am forced to).

The other 15% is where I am at Level 4 – where I am actively looking under the hood – and there are only 5% of the topics where I have a desire to get to a master's level. These are topics I've been reading about, engaging in and actively participating in for over 15 years, and have no intentions of quitting. I'm not saying your portfolio might be the same as mine, but it's important to know what your learning depth across topics looks like and that you be intentional about it.

The most common pushback I hear from folks when it comes to the topic of learning something new, pursuing a hobby or just being curious about topics is – "I don't have time". With layered learning you don't need a lot of time if you are intentional about which layer you want to operate in for any given topic. For example, it hardly takes 1 to 5 hours to peal the first layer of the metaphorical learning onion for any given topic and get to level 1. Have a couple of dozen learning threads open in your life, intentionally select the level you want to be on each thread and every day just pick anything from those dozen threads that you feel like studying on that day; give it an hour. That is all you need. The topic can be anything. Whatever you feel like picking up from a pre-decided list of topics you have on your list. Don't feel like going deeper on that topic the next day? No problem, pick something else from the list and come back to this topic whenever you feel like it. Once you get into scattered layered learning, picking something new will never feel like a chore again. It'll be fun, engaging and the resistance should lower considerably. Plus you'll start going deeper into topics that you genuinely care about. Go pick something new to learn and try to peal a few layers of the metaphorical learning onion. I wish you good luck.

A couple of years ago I utilized a set of simple underlying principals of learning something new to learn how to juggle. Within a week, I was able to comfortably juggle three juggling balls.

Next year I used the same principals to learn how to draw faces and drew the face of a loved one which others were able to unanimously recognize. Within a week I learned how to touch type and within a month, crossed a typing speed of more than 100 words-per-minute.

This year, I had two life skills in my bucket list –

1. Learning how to drive a stick shift in the crowded streets of India. Learn this to a point where I can confidently drive where I want to go; without consciously thinking about it.
2. Learning how to play the piano and play one song by ear – no notes to refer, no looking up the song on YouTube, no reference. 

Driving

Driving was the easy bit. It is all about spaced repetitions and frequency. When you start, driving a stick shift is excruciating. Over and above everything you need to learn to drive an automatic transmission, you’re dealing with the clutch and the gear. If the manual stick shift car you are driving doesn’t have hill assist you are also dealing with the mechanics of the hand brake and a strange combination of gas pedal, clutch and hand break; particularly while driving on slopes.

But the fundamental principals of driving are simple. You learn how each of these bits work, you find a place to practice and you repeat. Every single day. You do that for a day, a week, a couple of weeks and then somewhere a switch flips and you don’t even realize that you are driving. Suddenly you are having a full blown conversation with your family in your car as you drive even in a really crowded street. The mental circuit required for driving is internalized. Driving just moved from the upper and more conscious layers of your brain into your basal ganglia.

For me, the act of driving a stick shift was internalized in a couple of months. Within a few weeks, I was driving on highways, I was driving dozens of kilometers and in a couple of months, I was at a point where I didn’t think twice before taking my car out to drive where-ever I wanted to go.

But did I fully accept that I can drive? That’s the complicated bit.

As a matter of fact, even today, after months of driving and having no hesitation in driving, if you ask me if I know how to drive, I would have to take a pause and think before I responded in the affirmative. But I have no hesitation in taking the car out and literally driving dozens of miles. I basically learned how to drive, sooner than my brain had accepted fully that it knew how to drive; which was really creepy.

Piano

The theoretical moving bits of learning how to play the piano are really even simpler. I just focused on playing the melody / notes of the song and did not worry about learning the chords. The goal was not to be a musician, but to get to a level where I can enjoy some personal time with the piano and play any song I wanted. To learn, you start out by:

1. Looking up a song on YouTube and you memorize the notes.
2. As you play it you learn that each melody is composed of a sequence of keys, if next note is a higher pitch than the one you are playing, it’s ahead of the current key – how ahead; is defined by how higher the pitch is; and there are no negative marks for trying and failing. If it’s a lower key, it’s behind the current key.
3. Now you look up a few more songs on YouTube but this time you don’t memorize them. You use the video as a reference. See the song and play it on the piano, once; by looking at the video / tutorial. Come next day and you would have forgotten the song completely; but this time instead of looking up YouTube you try to guess the keys. It’s a bit or memory, bit of playing by the ear. Soon you’ll realize that if you forget a song, you can make up missing bits, by ear.
4. Repeat. Create a library of songs, but do it such that you don’t have to refer to sheet music or a YouTube video more than once. If you forget the songs the next day you should be able to get to the forgotten keys by ear. Get a library of songs big enough that it would be impossible to memorize; and that is when you will slowly start playing by the ear; but only when you forget something.

I reached and remained in this stage for months. I would look up a song, play it and then never forget it. If I did, I would make up the parts in between. I had given up the idea of playing without looking up the notes or sheet music even once. And then one fine day, in my living room, I felt like playing a song I did not know, so I gave it a shot. I was certain I would fail, and that I would have to look up YouTube or sheet music once, but the creepiest of things happened. I played the song; and my nephew who was in the same room, instantly recognized the song I was playing. It took me a few minutes to make the song, but I was able to play it without any reference. Just like driving, I learned how to play the piano, before my brain had fully accepted that I knew how to play the piano. Clearly, my brain was taking longer at accepting that I had learned something than it was taking in actually learning that thing.

The Brain

The same thing has happened with me multiple times now. Even today my brain has not fully reregistered that I can juggle comfortably and I have to take a pause before I tell someone that I can juggle; but I can juggle three balls; comfortably; for a long time; without stopping. The same with driving. The same with piano. Which of course led me to ask the million dollar question:

Is our learning speed limited by our belief systems around how fast or slow we can learn something? Are our brains taking too much time before they allow us to accept that we’ve finally learned something? Is our productivity also limited by our belief system around how productive we can be?

And I was not looking for a stupid, “you can do it” styled answer from another YouTube guru. Because, when you research answers like this one, the internet rewards you with a lot of it is voodoo science ideas like affirmations and the power of positive thinking. I was looking at solid scientific studies around this topic. Research that has been done on how the brain’s belief system works and how it empowers or limits us in the endeavors we undertake.

The Sandford Prison Experiment

Assume that you are a psychologist, and device a small experiment, where you pay students fifteen dollars a day to participate in the “psychological study of prison life”. You randomly divide the groups into prisoners and guards (without telling the group that the other group is a bunch of students too) and you give your guards real uniforms and give them strict instructions that prisoners should not escape. How do you think the guards would behave over time? When phycologist Philip Zimbardo conducted this little experiment, the participants who believed that they were guards became so brutal and barbaric in the treatment of the prisoners; that the experiment had to be stopped in five days. The surprising part? Reports from the study indicate that the participants playing prisoners in fact had become abnormally submissive and were tolerating the abuse being dished out to them simply because they were playing the role of prisoners. The Stanford Prison Experiment was a chilling experiment how regular people can become abusers or victims simply by temporarily tweaking their belief systems.

The Fastest Mile

For hundreds of years in the sport of competitive running, based on the human anatomy, it was believed that human beings are physically incapable of running a mile in under 4 minutes. On May 6th, 1954, Roger Bannister, a middle distance runner, who had come really close to the 4 minute mark but failed, was supposed make one more attempt to break the 4 minute mile challenge. But because of the headwinds of 25 miles/hour Banister had made up his mind to not run and try again on a more opportune moment. Moments before the race however, the winds, dropped, and Bannister decided to run. That day, he ran a mile in 3 minutes and 59.4 seconds. Suddenly the popular scientific belief that the human body is incapable of running a mile in less than 4 minutes was shattered. And now that the sports world believed it is doable, the record was broken again, and again, and again. Today, a 4 minute mile is commonplace phenomenon in world class middle distance runners. The Latest record stands at 3 minute 43.13 seconds. Bannister’s run makes us wonder what changed? Did humans evolve rapidly or develop some genetic mutation that made elite athletes who till that day, had never been able to run a mile in under 4 minutes, now suddenly run it in much sorter time? Of course not. What happened is their belief systems changed. Their brains gave them permissions to run faster.

Other Studies

The famous experiment on learned helpless by the father of positive psychology, Martin Seligman, famous study on fixed mindset vs growth mindset by Carol Dweck, and the famous literature on the Luck Factor where participants saw more opportunities around them just because they believed they were lucky are all concrete studies conducted with scientific rigor which tell us that we are just as limited by our mindset (if not more) than we are limited by the hard the physical realities around us.

Why A Realistic Expectation Of Time It Takes Is Important.

When I was young, I worked with someone who would often use the phrase, “Nothing in life happens as fast or as slow as you think it will”. This phrase applies massively to learning new things. We grossly misestimate the time it takes to learn things.

At first, we fail, because we grossly underestimate the time we will take to learn something. And when we fail, we then grossly overestimate the time that thing will require and we give up.

On one hand we give ourselves a week to learn data science and then get disappointed that we’ve even forgotten the basics of statistics that we learned in high school. Then we go to the other extreme, think it will take years to learn, tell ourselves, “what’s the point?” and quit.

When we think of learning an artistic skill like playing a musical instrument, drawing or juggling it’s the same. We think we’ll just buy the piano and start playing it. When that doesn’t happen in a week or two, we get bored, we think it will take years and give up.

In reality however, I’ve seen that the focused deliberate practice of 20 to 40 hours (spaced over 20 to 40 days) is enough to make you reasonably good in any skillset you would like to dabble with. It won’t make you an expert, but it will bring you to a level where you become way better than someone who has never tried it and good enough to keep your brain engaged enough to keep tinkering with the skill, stay interested and learn more in months to come.

So the next time you want to learn something, Give yourself 30 minutes of deliberate practice in the morning and another 30 in the evening. Repeat it for 30 days. Do it with an open mind and you’ll be shocked to see how rapidly Neuroplasticity works. Soon your brain will start giving you permission to start playing the piano or start drawing, design a complex statistical model for that tiny little data science project you had in mind, start programming in rust or do whatever it is that you want to do. And the sooner your brain gives you the permission to believe you are getting actively better, the sooner you learn things.

The trick to allowing your brain to give you this permission is timing. It is most likely to happen if you have realistic expectations around how fast you are going to pick up things and how much effort will be required. Remember, nothing in life happens as fast or as slow as we think it will, particularly when it comes to learning something new.  Now go pick up something new and interesting, set realistic expectations around how much time you are going to invest, engage in sustained deliberate practice and watch some magic happen. Of course it won’t happen as fast as you expect when you start, or as slow as you expect when you are about to give up. With this new insight in mind, go on, give something new a try. I wish you good luck.

Ever since I started using a computer I've always used three fingers on each hand to type. At 60 to 70 Words Per Minute (WPM), I've always been, what I like to call a self-taught typist with a respectable typing speed.

I always wanted to learn how to type faster and be one with the machine. The keyboard is one ubiquitous way we engage with our machines and our typing speed should not come in the way of expressing our thoughts. This is one reason why I always wanted to touch type and type faster than 100 words per minute.

Last year I learned how to juggle and described some of the principles of learning anything new using juggling as an example. I also tried to apply those same principles and learned how to touch type. With touch typing, things were a little tricky though.

The most annoying part? If you are at a respectable speed (50/60/70 WPM) using your customized typing style with just two or three fingers, learning how to touch type will set you back when you start and that will be extremely frustrating.

From a learning perspective here is how learning how to touch type is very different than picking up a new skill (say, for example, learning how to juggle):

1. The Fear Or Unlearning: With touch typing, you have to unlearn what you already know and take a lot of steps backward. The moment you start to touch type, your typing speed will drop like a rock. If you've never done touch typing, the moment you swap your typing style with touch typing and start using something like the typing club, your typing speed will most likely drop, from 50/60/70 WPM to 20 or even 10. That genuinely freaked me out.
2. No Turning Back: Once I ‘mostly’ started using the right finger on the right key for a few hours, I realized that I was forgetting my old style of typing and my speed had fallen to about 30 WPM. Given that I had started forgetting my old typing style, this meant that there was no going back. I was in this middle place where if I didn't get better at touch typing, I would be stuck with 30 WPM for life! This freaked me out even more. This also meant that, unlike juggling or driving, typing will have to be a skill I learn using an immersive approach rather than a gradual one.
3. Immersive Learning:  This was different than juggling or learning how to drive where you can just spend 30 to 40 minutes a day to slowly rewire your brain for a couple of months and let those neural pathways get formed naturally. With touch typing, I knew that I could not afford to be unproductive at work for weeks and so if I was not back to my old speeds (or at least respectable ones) over a weekend, come Monday morning and I would resort back to my old typing style. Hence, the need for immersion. I spent more than 25 hours on a single weekend using the new typing style and got back up to about 50/60 WPM over the weekend itself.
4. The Point Of Doing It Right: When I was back at 60 WPM I took a step back and asked myself, "What did I achieve?" - I mean I wasn't faster than before, so what was the point of spending over 25 hours over the weekend to change my entire typing style? The answer was fatigue. With my earlier typing style, I experienced hand fatigue in just about four to five tests. Now I could do a typing test over a few dozen times and feel zero typing fatigue. Later I did stumble up research which explained why distributing the typing load over ten fingers makes it easier for you to type and why you experience less fatigue.
5. Switching Gears From Immersive To Gradual Learning - With 60 WPM I was now ready to switch to the new typing style permanently and switch gears to gradual learning to increase my typing speed further. With just 4 to 5 typing tests during breaks everyday, I was on to 70 WPM the next month and 90 WPM in a couple of months. 90 WPM is where I hit a wall but my goal was to hit 100.
6. The Law Of Diminishing Returns - At 90 WPM I could feel the law of diminishing returns kick in and I had to work extremely hard to gain even a couple of words. Focus on accuracy and spend hours on it, because when you are typing 90+ WPM you cannot afford to correct your mistakes.
   
   
   I had to learn and use shortcuts like CTRL+Backspace to delete the whole word instead of deleting one letter at a time and use other similar shortcuts and techniques and put in hours of practice over the weekend. Finally last weekend I reached a level where I could, for a reasonable number of tests, break the 100 WPM barrier to confidently say that it was not a flook.

The Point? There are two. If you are a programmer or closely work with a computer, you should give touch typing a shot, because you may have your typing style and you may be decently fast, but if you are not using all ten fingers, touch typing helps you type faster with lesser fatigue to your hands which is a good thing in the long term. And second, touch typing will introduce you to some aspects of learning that picking up a new skill like juggling or driving may not teach you.

The new experiences of unlearning, freaking out, adhering to right techniques, believing in the process, immersive learning etc. that you have as you touch type will transition to other learning endeavors that you engage in future. Today, this is where I am:

At 104 WPM (my fastest typing test thus far on 10fastfingers), I'm not just better at typing than I was before; I am better at learning new skills than I was before. If you have your very own typing style and you don't use all your fingers, may I suggest you give touch typing a try? It may not make you the fastest typist, but It'll teach you much more than just typing.

The other day someone asked me why I was going through masters curriculum at this age. Their argument:

Most of what you are learning is theoretical and useless. What’s the point of revising data-structures at this point in your life?

Then last week, someone at work was working on a specific problem. In the last release they had 21 check-ins and one of the check-ins had introduced a bug. The team was trying to find which check-in introduced the bug.

To find the erroneous check-in, they were applying each check-in one at a time to the old codebase and then running the application to see if the bug could be reproduced. When I heard that they were doing that I spontaneously responded with:

You’re trying to use linear search algorithms to solve a problem that would be solved much more efficiently and with much less time complexity using a simple binary tree search.

What I meant was that instead of taking each check-in one at a time applying it and then running the code, the team could have just taken the first 11 check-ins together, applied them on the server in a single shot and then tested. Either ways, if the bug was found or not in the first 11 check-ins, we would know if we should look at the left side of the tree or the right side of the tree and with that one attempt, we would have eliminated 10 tests right away. That’s 10 times of applying check-ins, firing a build, running the code and trying to reproduce the bug.

Put simply, you merge 11 check-ins in a single shot and run. If you find the bug, the bug lies in one of the check-ins between check-in 1 to check-in 11 and if you don’t find the bug you know the issue lies with check-in 12 to 20. And then you repeat this process depending on which side of the tree (1-11 or 12-21) the bug lies in. Exactly how the binary tree search algorithm works.

During the times of Covid a collogue of mine had pointed me to an article that showed how you can apply binary tree search to do effective Covid testing and save a bunch of testing kits. It’s the exact same logic. If you have 100 blood samples, mix the first fifty samples and test. If you don’t find Covid in the mixed sample you’ve just saved yourself 50 test kits. If you do find Covid, mix the first 25 samples and do another test. Again, binary tree search.

Of course we don’t hand write code for binary tree search in the real world when we are coding these days. Most modern day languages provide us out of the box search functions which use the most efficient algorithms under the hood.

But that doesn’t mean we can’t see binary tree search as a thought construct. Real world Binary tree search based use-cases exist in our day to day life, and identifying them, helps you solve these problems way faster, even when the problems have nothing to do with writing code. Problems that benefit from binary tree searches, are all around you. The real question is, can you spot them?

Oh and yes, there is a point of revising some of your data structures at any point in your life because that knowledge itself is not as useless or impractical as you might think it is.

An old Chinese proverb reads:

He who knows not and knows not that he knows not is a fool, avoid him.

In reality however, most of us, don't know. And we don't know that we don't know. What a professional phycologist would call, “lack of insight”. Putting it colloquially, when it comes to skills and competence, most of us suck. And we don’t know that we suck.

And why do we lack insight about how good we are at most things? Because the neural circuits required to become good at a craft are the exact same circuits required to qualitatively judge how good you are at that craft.

Put simply, if you don't have the brain circuits to draw well, you also lack the neural circuits to help you evaluate just how bad you are at drawing. This also means that if you learn just a little bit of drawing, you start believing you know a lot about drawing and your brain starts to think of yourself as an artist. This happens because with your limited knowledge of drawing, you can only see painting with limited scope of putting the brush to paper and you still don't know the intricacies of the craft.

As you spend years drawing, the nuances of the craft open up to you and for the first time you start realizing the vastness of what you don't know. The irony here? It is only when you become a decently good artist, that you realize that you are a really bad one. In the chart below for example, you don’t reach the “I know nothing about this” realization till you are substantially competent at a craft.

This is why as people become better at any craft their self rating in that craft keeps coming down. The less you know the craft, the higher you rate yourself in it. The more you know the craft, the more you know what you don’t know and the less you rate yourself.

There is a name for this. It's called the Dunning Kruger effect.

It's why managers with literally no organizational skill, can give you a long lecture on how you should organize your tasks better. It's why CEOs and founders, give coding advice to programmers who have coded for two decades, without blinking an eye or without realizing the inherent underlying irony and humor in the entire situation. It's why the most unproductive guy in the room usually goes around telling everyone how unproductive they are.

The effect may seem funny at one level, but ignore it and it has the potential of ruining companies, relationships, careers and even destroying lives. Its why the movie The Big Short (loosely based on the book which in turn is based on real life housing industry collapse) begins with the caption from Mark Twain:

One way to overcome the Dunning Kruger effect, is to have actively develop insight of how we can all fall prey to the effect. Mindfulness, and simply accepting that the effect is a scientific reality and happens to all of us, is a good starting point.

For example, I had driven for few years in the US; but I recently learned how to drive in the streets of India and after a month of practice, I genuinely started believing I knew everything my driving instructor knew. Then one fine evening, I had to brake a manual stick shift car on a hill slope without using hill assist. That’s when I realize how misguided my evaluation was on how much driving I really knew.

Another approach, is respecting results and payouts. Put simply, don't pass judgements on working styles of people who are more effective than you and particularly those who are paid more than you are in a given field.

The simplest way to start this practice, is by stopping to give commentary on how that expert soccer, baseball or cricket player ‘should have’ hit the ball, next time you are watching a match and they miss scoring.

Then take the concept to your professional life.

For example, stop passing remarks on how your multi-millionaire CEO should run his company and instead try to learn from him on how he runs his company and makes millions.

Working with an expert designer? Don't tell him to change the color of your website to light blue because dark blue just doesn't "feel right" to you. You feel you have a sense of esthetics, but in reality it's just Dunning Kruger effect at play, making you think that you are a designer. You’re not. You know nothing about the science of esthetics. Something your designer has probably read and practiced for years.

Instead, ask questions. Why did he pick dark blue? What was his rational? What basic rules of designing has he used. Practice humility. Learn from him rather than trying to teach him the craft he has already practiced for multiple decades and you know nothing or very little about.

Insight, humility and genuine curiosity are three biggest weapons you have against the Dunning Kruger effect and given how dangerous this effect can be to your professional and personal growth, I suggest you use all three.

More and more cell phone manufacturer are maximizing their profits at the cost of the customer. Cutting down chargers and cutting down on headphone jacks are two new trends. But one trend that annoys me most is loading of bloatware by the manufacturer. Preloaded software which the users simply cannot uninstall. If you are stuck with a phone where your manufacturer decided that they want to push additional bloatware on your phone because they are giving you a phone at a slightly cheaper price, you have three options:

1. Live with the bundled apps and services – In which case you have a slightly annoying experience; and in all likelihood whatever little you saved in cash, you will end up paying for with storage, battery life, the control that you have over your own device and your own privacy.
2. Load a custom ROM if your phone supports it – In which case a lot of apps (banking and otherwise) will crib about your phone being rooted or having a custom rom and you won’t be able to use those.
3. Debloat your phone with ADB – In which case you get to remove most of the bloatware the manufacturer added to your phone, by tethering it to your laptop and firing the ADB commands from your laptop.

Given the three choices, ABD is a healthy middle ground. The overall process is rather simple.  To start, you turn on developer mode on your phone and enable USB Debugging in your developer options. With that done, you just download the ADB zip file, unzip it, add it to your system PATH, and assuming that you have USB drivers for your phone installed on your machine, you should be all set.

Connect your phone to your computer using a USB cable and you should see it if you fire “ADB devices” on your terminal.

Now that you’re connected, you can literally shell into your phone by using “ADB Shell” and you can see what you have on your phone by doing a “pm list packages”

Once you spot the package you want to remove, you can remove packages (even most ones that are bundled by the device manufacturer) using – “pm uninstall -k --user 0 [package-name]” (without the square brackets).

The overall process is really straight forward, but if you don’t like the idea of firing these commands manually, turns out, there is also an Open Source UI based Debloater that does exactly this using a simple intuitive UI.

The Universal Android Debloater actually gives you suggestions regarding which cryptic app-name maps to exactly what features on your phone, so you know what you are removing.

It also recommends removal of certain apps and services, which I like to review closely before removing. And then, I typically switch to unlisted categories, search everything by the name of manufacturer, review which one of those services I don’t need, and get rid of them. No, I don’t think anyone needs a proprietary app-store just to make their phone manufacturers feel better. Most folks, will be surprised by the level of telemetry and tracking software these manufacturer are installing on your device. All of this, comes at the price – shorter battery life, storage, overall sluggishness of your phone and your privacy. If you go through a typical list you’ll be surprised to see the kind of crap some manufacturers pre-load on their devices. The debloater should allow you to get rid of most of this stuff.

Milage might vary, depending on what and how much you remove, but I typically notice anywhere between 500 megs to 1 GB of storage reclaimed, battery life shoots up dramatically and the phone is a lot more responsive.

Now a days I’m comfortable with it enough to actually strip out launchers that the manufacturers provide completely off the phone and install something like Niagara Launcher. You can install any light weight minimalist launcher of your choice.

Some folks go extreme and strip out everything, including play store and google services to turn their android phone into a dumb-phone with limited pre-installed apps that they need. Folks have claimed to get a week of battery life with extreme Debloating. But like I said, milage will vary.

For me, I do a conservative de-bloat and just remove the things I don’t need. My phone goes from a day of battery life to around a day and a half. That’s still 50% battery gain, around a gig of extra space and a snappier phone in general which is slightly more private. But what’s most satisfying, is the power to decide what apps are loaded and run on the device.

Like all good things, de-bloating comes with it’s risks that mostly revolve around overdoing it, so always backup your data before you start. That way if you remove something you actually need or mess up something, you can reset your phone. What you remove, comes back on factory reset since the actual installers in android reside on a dedicated system partition. That is what makes de-bloating slightly safer than dumping a custom rom. This also means once you reset your phone and restore your data you can be exactly where you were before you started de-bloating.

If you are still using apps forced on you by your manufacturer, being made to see ads on a phone you bought with your own money or simply want a lighter snappier minimalist version of your phone without rooting it or loading a custom rom, de-bloating your android phone might a relatively safer option. Go give it a try.

Overheard someone say this on a call in a café:

Why should be depend on or work with them? As a team we’re not dependent on other teams!

Even at an individual level, the Idea of a ‘self made man’ (or woman) seems to be catching on. Men and women hold their head highs when they proudly proclaim:

I’m not dependent on anyone! I don’t like depending on others. In my entire life, I’ve not taken any favors from anyone.

Even though these statements provide a sense of accomplishment, the fallacy in the idea, lies in evolution.

A few million years ago, when we were nomads, much like elephants or monkeys, we sapiens, lived and moved in herds.

And for some reason, if you were ousted or out-casted from your tribe and the herd moved on without you, no matter how powerful you were, you would, in all certainty, be lion lunch within a day. Your chance, of surviving in the wild for more than a week, without ‘depending’ on others in the herd was minuscule at best.

Everyone understood the significance of being dependent on others in the herd, we acknowledged that dependence and we reciprocated by acting out our responsibilities and respecting the older and more powerful alphas in the group. In return for the protection they provided us, we provided them with respect, support and our protection; the interdependence loop was closed and we made it thus far in-spite of having rather weak bodies compared to any other predators in the wild.

Then came in modern media – with stories of self made men and women who don’t take favors from others and are not dependent on others. The stories gave us a dopamine spike and soon, we became echo chambers for those messages.

Dependence on each other is what fundamentally defines any relationship; be it personal or professional. I’m a programmer, you depend on me for code and in return I depend on you for my very survival and food. If we work in a team or are in a personal relationship, the dependence on each other is even higher.

If your claim to fame is that you’re ‘self made’ and that you’ve never been dependent on anyone; well, let me just say that if your ancestors in the savannahs thought like you do, you wouldn’t even have existed to have that chain of thought.

Celebrate dependence. Ask for favors. Be shameless about how dependent you are on your loved ones, your team, your company, your clients and everyone around you. And then, reciprocate. Because without interdependence, we never stood a chance. We still don’t.