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.

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.

I did a video on configuring Neovim on Linux to make it work like Visual Studio while doing .NET development. You know, intellisense, that nifty break point based debugging, the code refactoring options and everything else that you get with Visual Studio or Visual Studio Code, but only with Neovim on Linux.

My point? The OS space and the IDE space has been democratized. It’s a level playing field between companies and developers now have complete choice. Like vim or neovim for than Visual Studio? You don’t ‘have to’ use Visual Studio to do .NET Development. When that happens everyone wins, because having the freedom to choose, is a good thing.

Some folks who saw that video remarked that they love the idea of using neovim as a powerful IDE but aren’t ready to switch the OS and move completely to Linux yet. Like I said, the OS space is democratized. So if you want to mix and match and do .NET development on Neovim and still use Windows as your operating system, power to you. This post will give you some pointers in that direction.

You start by installing Neovim on Windows from here.

Like Linux you now have package managers in windows. Neovim is available both on chocolatey and winget  so whatever package manager rocks your boat, you should be able to install neovim using a single command. Instructions here.

Unlike Linux, the neovim initialization file in windows is @ C:\ Users\ [Your_User_Name_Here]\ AppData \Local \nvim \ init.vim (without the spaces).

The file for my configuration on windows 11 is here. You can download it, tweak it and place it in the folder above to quickly configure your neovim. Don’t forget to do a “:PlugInstall” to install all the plugins configured in the file automatically.

I’ll not cover the different components you need for .NET development on Nvim. This video already covers that. Let’s just focus on the changes when it comes to windows.

You’ll probably need to install python for Nvim for some of the plugins to work. You do that by installing python, pip and then doing:

pip install neovim

Once you do that, most plugins that depend on python should work.

Strangely enough, unlike Linux, McAfee on windows sees FZF as a virus and blocks it. I let the guys at FZF know, turns out they have worked on getting this whitelisted, but McAfee continues it’s little quirks; so your milage might vary. For me McAfee still has an issue and because my organization enforces McAfee, I had to move to ctrlp for searching files. The overall idea is the same, Fuzzy search for file names.

Then, I had to strip out Ag, because there seems to be no support for Ag on windows. The documentation for using Ag in windows is practically non-existent. So fuzzy search inside files is a problem and doing “search in entire solution” (like I often do in visual studio) is hard. We have to tackle this separately using something else. Enter Ack.

The plugin installation for Ack is here and the ack installation is here. The URLs have detailed instructions on how to install for windows. You have to install Perl for this to work if you don’t have that already. Once the Ack Plugin is installed you should be able to Fuzzy search contents inside all files in your current folder or solution by doing Ack [search_term]. For example below I am doing a search on the word manger inside my entire codebase using

:Ack manager

I see the line items (with files names) where the search item was found and I can navigate to each of the search result by using my arrow keys and preview it using enter / return key.

So far if you’ve followed my entire series of videos on this topic and used my configuration file you should be able to write .NET code on neovim inside of windows. You should have full intellisense, code refactoring options like you have in visual studio, fuzzy logic based file navigation, fuzzy file search and even debugging.

Oh, and don’t forget to get a nice nerd font with ligatures to make that console and your Neovim based IDE prettier.

Again, if you haven’t seen the full video series on dotnet developing using neovim, I highly recommend you watch that here. Rest of the steps for setting up neovim as the IDE for .NET are the same in windows even though the videos use Linux.

With just the tiny tweaks described in this post .NET Development using Neovim pretty much works, even on Windows. All the richness of C#, familiarity of Windows and the productivity of Neovim. Enjoy.

The Indian government recently rolled out an excellently made website for scheduling vaccines for all Indians. However a lot of private hospitals are following irregular or different times during which they open slots and because of the demand of vaccines the slots often fill up literally in seconds of opening up.

Today if you are looking for slots manually you are at a huge disadvantage compared to folks who might have automated the process.

Here is a quick python script we wrote to continuously poll co-win servers every x seconds and play a music file on your disk as soon as a slot meeting the criteria is found.

I know a lot of bots are available in telegram but most of them are closed source and by the time they notify you, it’s often already too late. This is open source, free, can run on your laptop / desktop (anything that runs python and play sound files, like a raspberry pi, technically should be able to run this), can be configured to run on parameters you like and can notify you instantly by playing music of your choice.

The Github URL contains the script source, Installation Instructions and documentation on all the variables you can customize.

Hope this makes tracking and scheduling vaccines that much easier.

Genuine thanks to the Indian government and Co-win team for keeping the API’s not just open, but easy to understand and really clean so that writing scripts like this one becomes possible.

The other day someone was talking about pair programming at work, and someone said, "I already pair 5 hours of my day every day helping others".

Help Time - is a time in your schedule that is usually not accounted for. It's really hard to plan for and it usually begins any time someone walks to your desk and says, "Got a minute? I need your help."

And that's paid help. One of my bosses believed that as seniors we get paid to help. His belief was simple:

It's a silent part of our work profile. We are paid to help, mentor and train others. You should have an open door and an open heart when someone walks up to you for help specially at workplace.

To an extent I agree, but when your entire day goes in helping others put out the same kind of fires, it's often time to introspect philosophically if helping folks is really helping them? Or just making them dependent on you and boosting your self ego? Is that what you are really getting paid to do? When it comes to professional life, help without training and mentoring usually harms both the giver and the taker.

Then there is unpaid help. Someone, somewhere, who is remotely related to you, whose laptop just broke down and merely by the virtue of the fact that "You are in IT" you are expected to replace their RAM.

You know, the kind of help we all know about.

A lot of folks and self help gurus speak at length about the power of No. 'Just say no' is what almost every book out there says. But no is not always an option. Specially for people who are reluctant at saying no. As a regular nice guy (or girl) your chances of being exploited using the help bait are much higher than a jerk who can say no and get away with it.

There is nothing wrong with helping, but there are a few simple things you can do to not bite into the help bait more than you actually want to. Here are some:

#1: Help using advice, direction or artifacts: Advice and direction are easy to provide. A five minute conversation which says 'look at this' or 'google that' and you give the seeker a general direction he or she should go towards. If you want to be a little more involved give them an artifact which others can reuse. Scott Hanselman has an excellent post on the topic of building reusable artifacts while helping others, so I won't repeat that material.

#2: Help but in a timeboxed duration: Sometimes advice, direction or artifacts aren't enough. There are times when takers will seek for explicit customized help. For example that uncle of yours's who wants a full blown accounting system and he is expecting you to build it for free. This is where you don't have to say no to helping, but make it very clear that you would love to help but you're busy (see point #4 on excuses) and so you're only going to be able to do X.

This X, could be as simple as - "I won't be able to design an entire application for you but I can connect you with someone who does this really well and at a reasonable price. I'll also be there in the first half hour meeting to connect you two and then you guys can negotiate a rate and take this forward. It's the only person I know so I won't be able to connect you to others but you can look at others online if you don't like this guy."

Whether you are helping your fellow developers or personal acquaintances, time boxing your help time is a good idea and when that time runs out, schedule for a different day in your calendar. The other day a school friend called for a help he needed and I told him I'm completely booked (again, see point #4 on excuses) but, "let me get that done for you by Friday late evening". There was a slight awkward silence because he just needed an hour of my time and he was probably expecting immediate help, but he was finally ok with Friday late evening and we both were happy with the arrangement. As much as I wanted to help him on the same day, I couldn't help it. My help time quota for the day had already run out. When you run out of money you can't spend more. Time is no different when you budget it.

#3: Recognize Patterns: If the same person calls you from help regarding the same kind of thing over and over he isn't seeking help. He is just exploiting you. For example I had an acquaintance who had a habit of visiting strange sites and getting his machine loaded with malware ever couple of months.

The first time it happened I showed him how to reimage his machine and a couple of weeks later he called me again, stating his machine was infected again, how he wasn't feeling confident reimaging it himself and would 'prefer' I do it. I told him I wouldn't mind doing it but in that case it would have to wait for two months since I am badly tied up with this huge project I had taken up and may have to fly out next week.

Next day he called me about a small question when he was stuck trying to do it himself. I answered the question and he was able to get it done.  Win-win.

Recurring patterns for same kind of help isn't someone seeking for help. More often than not it's someone exploiting you and sucking your time to feed their own agendas and their own laziness. They aren't bad people but when you help them with the same problem again and again instead of empowering them to fix it themselves you are feeding their laziness.

#4: Plan our excuses ahead of time and practice with loved ones: I have a collection of excuses predefined for all occasions. A few of these are ones that can be pushed back or questioned, which lets me validate how serious a person is. For example, "I've got  a meeting during office hours but can we sit at 10 in the night and work at it?" - If the person' isn't serious he would usually refuse that offer. If he accepts the offer I can always tell him I got another call at 10 and help him the next day. Win-win.

Then there are excuses in my quiver that just cannot be challenged or negotiated with. For example, "I can't, I'm doing a course on machine learning and have my exam scheduled on that day". I've researched into which course, which exam and have rehearsed this excuse a thousand times over so I don't feel reluctant using the excuses. Be careful when using this though, since in most cases you aren't even obligated to give an excuse. Just saying "I have other important work (or personal) commitments" convincingly should be enough.

As geeks helping folks who are stuck is second nature to us. We see something broken and want to fix it. A lot of folks actually thrive on this weakness of ours. Practicing excuses and having a pre-planned list of excuses for each occasion in your repertoire helps a lot, especially if you are not great at saying no assertively. That's a skill I need a lot of work in.

Helping someone is a noble act and there is nothing wrong with helping people. It's a form of altruism. And like every charity, when it impacts your own well being it becomes dysfunctional. You can only give a small portion of what you have, and when it comes to time, it's really important you put a stake in the ground and pre-decide what percentage of your time you want to dedicate to helping others.

If it's a loved one you can give them a lot of time, if it's acquaintance who is a perpetual taker you may choose to give him nothing. There are no right answers but whatever you do, you should be doing it deliberately. Every time someone requests for help you shouldn't be taken off guard and end up providing hours or your precious life just because you were guilted or emotionally arm twisted into it.

Timeboxing help and picking who to help and how much to help, is an art you master and as you master the art you actually get better at helping people you really want to help and providing help on things you really care about. Go on, plan your help time deliberately and provide help that really matters to people who really matter to you.

I'm incompetent. On days I feel like a absolute looser who is unable to focus and get anything done. On other days when I am productive, I see others around me being incompetent and I get urges to tell them to snap out of it and get them to get some real work done.

In my entire life span, I can count the consistently productive people I've worked with using fingers on my one hand. And just to be absolutely clear, I'm not one of them. Oh and when I'm not productive, I've got thousands of excuses about why I'm unable to give my best.

The other day I downloaded a version of ionic and out of the box and it wouldn't compile a hello world project I stubbed out using it's own CLI. I felt angry at the incompetence of developers who were building the ionic framework and had the audacity to throw a crappy build out there under the name of iterative development!

Then I went looking for some help and someone had already whined about it on the ionic git repository, where someone else had given them an ugly patch to unblock them. So I applied the same ugly patch myself and life moved on.

On a different day, I was trying to get .NET core 2 application migrated to .NET Core 3 and it was just annoying. Were the developers at Microsoft incompetent? Or was I just having a bad day? Or, was I incompetent for not going through all the breaking changes between two version and writing planned code rather than doing reactive development every time something broke? I told myself I was just having a bad day and pushed on applying one fix after another and migrating the code over to the newer version of the framework. This was defect driven development but I got a lot done. Maybe I was incompetent but I was productive.

Then, the other day, I got on an elevator, and pressed the button to go to the sixth floor, the elevator literally bounced around a bit, then went to basement at full speed, then shot up at full speed all the way to fifth floor instead of sixth, came to a screeching halt, opened it's door and stopped. All of us in there were shit scared and spell bound.

Then the maintenance guy shows up and tells us he had no idea what just happened but 'guarantees' it wouldn't happen again. My nerd brain is screaming to tell him that he cannot theoretically give us that guarantee till he knows exactly what happened. But as per him, 'for now' everything 'seems' fine and we could go ahead and use the elevator again. I took the stair case instead.

Like it or not, we live in a world where everything is broken. I don't know how we got there. Maybe it was materialism or maybe it was just our desire to move fast or be agile, or maybe it was just our animal instinct to win races, but we're here. And like it or not everything is either broken or will break down soon. The only question is how badly will it break down and how soon?

This also means that as much as you want your work to be reliable it is just as reliable as the underlying frameworks you use, and most frameworks you use are going to be broken at some level. Add to that, our inherent incompetence, our laziness, all the distractions, the work culture most of us are working in, the interactions you're having at work, the number of meetings we're expected to attend  and the amount of grunt work that we're expected to do. On any given day if you can get anything done, you should give yourself a pat on your back.

We live in a world where incompetence is the norm. Everyone around you is incompetent. You are incompetent and so am I. And there are only two ways to deal with this incompetence:

Embrace Incompetence and Design for Resilience.

Start your day with realizing the potential of incompetence you have and set smaller goals and turning productivity into a game. If you have a todo list that expects you to do more than 2 hours of real work on any given day you are just going to be disappointed end up feeling like a piece of crap.

Know that you are incompetent, the frameworks you work with are unreliable, your work culture is broken and above all the folks you work with are going to struggle with these exact set of issues of incompetence as you are struggling with and they too will have mood swings and productivity cycles like you and you have to deal with all of that; not to mention your phone buzzing and email streams to distract you. So just aim to get less done without feeling guilty about it. You'll be happier.

If you want any mental sanity in today's world have really low expectations about your own productivity and productivity of folks around you.

Then when you get 3 hours of work done in a day you feel good about it rather than feeling like crap. And then when your dopamine circuits kick in, instead of being being constantly depressed about being non productive you can be happy and slowly push the two hour check list to a higher hour count because you are now gaining self confidence and control.

Put simply, design your life around unreliable things and build resilience into your work routines, the quality of work you do and even your social interactions. Life today is literally a game of inches and instead of hoping to walk a focused yard, it all boils down to your ability to grab and collect those little wins and inching forward. Embrace incompetence and grab whatever tiny inches of productivity you can grab out of your own life.

Draw Incompetence Boundaries

An elevator bouncing and going to the basement when you press 6 on the dials is acceptable. The same elevator crashing and killing people isn't. They told me that the elevator has a safety mechanism in place and it could dance around all it wanted but the likelihood of us dying in an elevator crash are very low:

The only known occurrence of an elevator car free falling due to a snapped cable (barring fire or structural collapse), was in 1945. A B25 Bomber crashed into the Empire State Building, severing the cables of two elevators. The elevator car on the 75th floor had a woman on it, but she survived due to the 1000 feet of coiled cable of fallen cable below, which lessened the impact.

The elevator manufacturers have clearly drawn a line on what's acceptable level of incompetence.

My general rule is, incompetence is fine as long as it's not costing someone their life, a physical injury, mental trauma or their hard earned money. That's where my boundaries are at. Anytime there is even a remote chance that any of these are violated, I have to shake my incompetence off, get some serious work done and take extra measures to try my level best to ensure that this doesn't happen. Absolutely, no excuses allowed. Fortunately most of us work on CRUD apps where the bugs we introduce are such that we can just go "Oops! Sorry!" - fix them and move on.

Also, It's good to have boundaries around just how much incompetence you will  tolerate from yourself. For me those boundaries are pretty relaxed but every once in a while I'll snap and will send a virtual check of hundreds of dollars to my mom stating that if I don't complete this task by a specific time and send her proof of it's completion she is free to encash the check and just take the money. She is not supposed to give me a chance to produce any excuses or explanations. Do you know how many time's she has had to encash the check because of me not fishing the task on time? Zero.

Suddenly, I've taken my incompetence which was causing me some minor annoyance and turned it into incompetence that's going to cost me enough money to make me uneasy. Lo and behold, things get done. Not in months or weeks, but in days and sometimes hours.

The other important thing to realize is that the only incompetence you can address or fix is your own. Trying to fix anyone else's incompetence is a recipe for becoming an as$hole. Every loud obnoxious jerk at your workplace believes that his or her coworkers are incompetent and he / she is just trying to help them get rid of their incompetence when in reality he / she is just being an as$hole.

The other day I was watching a video about a mass murderer who was being put on the electric chair but it was taking some time. This dude got so annoyed at the incompetence of his executor that he yelled something to the effect, that his executor was incredibly incompetent and in that much time he himself would have killed half the city! Once you start looking at incompetence of anyone other than yourself and start acting on your urges to 'fix them' you have taken your first step towards being a prick because now you're seeing someone as a lesser person.

Long story short incompetence is all around us and we live in a world where there are very few people or things that work consistently. You can either bitch about it and use it as an excuse to get nothing done, brood over it and be an arrogant pompous prick who thinks every else is incompetent; or embrace this incompetence and ship anyways. I don't know about you, but I prefer the later.

Productivity as a topic has been very near and dear to my heart. Unlike most people my obsession with productivity tools, tips and techniques doesn’t revolve around the fact that my productivity allows me to squeeze a couple of hours worth of extra work into my regular workday. For me productivity is a way of life, and a way of doing more of what you want to do (or what you were meant to do) and less of what others want you to do.

Chris Bailey, as an author caught my attention because he had the courage and conviction to take an entire year off from his prime years and study productivity. The Productivity Project chronicles his learnings in that one year. The book is filled with experiments (some scientific, but most others self-applied) where  the author makes himself a guinea pig and tries out some sane and some insane productivity tips and tricks.

The book begins with practical advice and claims to be able to take you from here:

To here:

<stupid_grin>The book was a validation that I’m not the only one who is crazy enough to try and measure every single waking hour of their life! Other, sane authors have done it too. </stupid_grin>.

Where the book started grabbing my attention was the moment Chris laid out his definition of being productive. Chris describes productivity using a simple idea of living with deliberateness and intention. He explains:

I think the best way to measure productivity is to ask yourself a very simple question at the end of every day: Did I get done what I intended to? When you accomplish what you intend to, and you’re realistic and deliberate about the productivity goals you set, in my opinion you are productive.

If at the beginning of the day you intend to write a thousand great words, and you do, you were productive.

If you intend to finish a report at work, ace a job interview, and spend quality time with your family, and you do, again, you are perfectly productive.

If you intend to relax for a day, and you have the most relaxing day you’ve had all year, you were perfectly productive.

An idea the likes of David Allen have been trying to propagate for years. The book is also full of real world practical advice ranging from simple advice like Emptying your brain, using the Pomodoro, the importance of exercise, the importance of food and the perils of Attention Hijackers like mindless surfing, but the real power of the book lies in how simplistically Chris describes some of the complex things that end up affecting your productivity. Take for instance this passage on how Sugar effects your productivity:

On a neurological level, you have mental energy when you have glucose in your brain. When you feel tired or fatigued, more often than not it’s either because your brain has too much or not enough glucose to convert into mental energy. Research has shown that the optimal amount of glucose to have in your bloodstream is around 25 grams—about the amount of glucose in a banana. This exact number isn’t all that important, but what is important is that your glucose levels can be either too high or too low.

Since unprocessed foods (in general) take longer to digest, your body converts them into glucose at a slower rate, which provides you with a steady drip of glucose (and energy) over the day—instead of a big hit of energy followed by a crash. In a way, processed foods are predigested for you by machines. This is why your body converts them into glucose so fast, and why a donut doesn’t provide you with nearly as much lasting energy as an apple.

We all know processed foods harm and effect our productivity and health, but simple explanations like these go a long way in understanding what foods to pick and provide the much needed nudge to make the right decisions. The book is also filled with surprising and mind-blowing passages which are fascinating (and somewhat philosophical) to read. Take for instance this passage on the history of time itself:

If you were around before the industrial revolution ended in the early 1800s, you wouldn’t have measured time down to the minute, not only because you didn’t have the technology to do so, but also because you didn’t need to. Before the industrial revolution, measuring time wasn’t as important, and most of us worked on the farm, where we had way fewer deadlines, meetings, and events to sequence than we have today. In fact, until the first mass-market, machine-made watches were produced in the 1850s, timepieces were unobtainable by pretty much anyone except for the super rich, and most of us charted the day’s progression by looking at the sun. Because we didn’t measure time with a clock, we would speak about events relative to other events. In the Malay language, there is even the phrase pisan zapra, which roughly translates to "about the time it takes to eat a banana."

The book of goes on to describe how in merely about 150 years, we went from not caring about time to having a huge industry and pretty much most of our lives run around set timings. The book covers productivity from more aspects than any other productivity book I’ve read thus far does. Even for an avid reader of books on topics like time management, neuroscience and psychology, a lot of the concepts the book explains (e.g. removing triggers to change your habits, exercising your focus mussel etc.) are not new at all but they are explained with a unique personal insight that I enjoyed thoroughly.

After David Allen’s GTD, if you have room for one more book on productivity, this is the book you should definitely pick up. I would give it a 5 on 5!