How tabs are killing your productivity

We work, socialize and learn on the internet. As the devices and the mediums to do these converge to a single set (your phone, your tablet and work PC are almost the same) it is becoming increasingly clear that we need to manage our time better to get things done.

There are more articles and books than one can count on how to “get things done” or “X habits of successful people”. It all comes down to self-discipline. Prioritize and execute, in that order, until the last task standing is down. Reading all this great advice, we beat ourselves up that we lack the disciple to focus. But how can you resist the temptation of curiosity? If you are like me, your hands probably go to the link and you click “open in new tab” just to come to that page little later. By the time you are done reading the article or blog post, you have a burning desire to read the original piece that tempted the author to write the reply you just read.

Yes, the content is there waiting for you in a tab for you to read. “No big deal”, you tell yourself. “I will focus on the task at hand and come back to it later in the day”. When later in the day comes you already have gone through this a few times and by 3:37pm your browser probably looks like this.

Screenshot 2015-02-03 15.50.06

Meanwhile, subconsciously, the buildup of emotional weight of those tabs sitting to be read is actually preventing you from focusing 100% on what you were supposed to do. Eventually you convince yourself that you have “ADD”. If you are suffering from “ADD” in this form, try this:

Next time you have an urge to open a link in a “new tab”, ask yourself whether or not that link is worth $5. If you start treating your time as a quantifiable, tangible asset, you may end up focusing better on the task at hand. If you need some assistance to tame your tabs, check out this Chrome Plugin called xTab. It limits the number of open tabs to keep you in check.

While you are at it, you can read about Adam Stiles, the guy who invented the tabs!

 

How do you test your data model?

Past couple of years have been all about the switch to NoSQL databases such as Mongo, Riak, Volt etc., and I see tremendous benefit in using these databases for the right job. However, regardless of relational or not most databases suffer from the same problem: bad database design.

When you see an application (regardless of whether it’s mobile or web based) that takes a long time to do something, the bottleneck is almost always data access layer and/or the database.  When you look under the covers the design looks like this:

 

Taken from: http://www.kkstudio.gr/#the-uncomfortable

Taken from:
http://www.kkstudio.gr/#the-uncomfortable

 

In this situation you get two types of answers based on the scale/mindset of the organization you are in:

  1. If you are in the enterprise:  “we need to buy new hardware and upgrade our <insert RDBMS company name here> licenses” or “we should install a cluster”
  2. If you are in a smaller organization or start-up: “we need to replace the technology because the new database is X times faster since it has eventual consistency, no ACID, writes to the cloud, or any other magical advantage.”

The real issue is usually not the technology, most of the time it’s the application of the technology that the design team used. Before jumping the gun and getting into the gnarly details of how to migrate the technology, organizations need to look into how they can avoid the situation in the future.

So, what can you do to prevent “bad data model design”? Asking a single question has worked for me time and again. Next time you are in a project just try asking your “data team” the following question:

How are you testing your data model design?

Invariably, this will get into a discussion of the scenarios that the database is intended to support and with some effort you can bring the data team to think about “test driven data modeling”. Hopefully, since the rest of your team is already following the TDD best practices, at the end you will get one coherent design that is meant to solve the same problem rather than satisfying the engineers’ hunger for complex modeling.