Google is one of the biggest, the coolest and the most profitable companies in the world. Probably the main reason for being at the top is their ability to innovate continually. According to Gopi Kallayil there are 9 core rules that drive Google’s innovative culture:
- Innovation comes from anywhere
- Focus on the user
- Aim to be ten times better
- Bet on technical insights
- Ship and iterate
- Give employees 20 percent time
- Default to open processes
- Fail well
- Have a mission that matters
Some years ago, the National Science Foundation estimated that our brains produce between 12.000 and 50.000 thoughts per day. According to other studies, this number could be even increased to 70.000. In parallel, other studies determined that between 75% and 80% of our thoughts are negative. Assuming these as valid numbers, this means we have between 2000 and 10000 thoughts that are neutral or positive in a day.
As part of my work, sometimes I need to memorize some speeches or some presentations and in order to do that, what I frequently use is one technique called: Memory Palace (which originally comes from an ancient method called Method of Loci).
The approach of this technique consists on basically breaking down your speech into the main concepts you want to talk about and you try to look for a visual image for each of the concepts. It is very important that you have a vivid image for every concept you want to memorize because it will be much easier to retrieve it from your memory later. Once you have all your images, you mentally place them in a place that you know perfectly that we’ll call your “memory palace”.
To be honest, I think sheer will power is a bad idea. You start trying to do useful things using your will power and then you realize it’s like a gas can that gets empty very quickly along the day. I mean, if you’re doing something against your emotions, if you’re doing something that you don’t like to do, in the beginning you will do it without any problem. You will fake yourself, you will feel comfortable doing it like you can do it the whole day… but after a while you get tired very easily and believe it’s not productive.
I was reading some time ago a book called Switch that explains the different forces that affect change. In the book they just explain how to make changes by looking at three different perspectives:
- The Rider
- The Elephant
- The Path
You know… the rider is kind of the intellectual part of the change, trying to look for reasoning, etc… the elephant is the emotional part of the change and whenever something is unclear, then it gets fearful… and the path is your environment, that can help you achieve the change or not at all. Well, in my case, my elephant is very fearful to accept that anything needs to be done just through sheer will power. I get fearful very easily and that doesn’t help much.
My proposal is that you look for ways to make it easier, to put your passion in as many things as you can, because if you have that tank of will power, it needs to last for the entire day (I presume that during the night it gets filled up again). If that’s the case, then you need to use it wisely along the day because there are so many things that require will power that do not depend on you. You can end up the day frustrated, anxious and feeling uncomfortable with yourself.
On the other hand, if you are aware when you’re using this energy and you try to limit the usage of sheer will power as much as possible, it’s the same as if you’re piloting an aircraft and you’re trying to glide it so that it doesn’t consume any petrol.
To programmers, benefits of source control are obvious. Revision history, revert and recovery, team work, build and continuous integration tools integration, and so on and so forth. No one is questioning usage of source countrol any more. It all boils down to a simple rule: if it is not in source control, it does not exist. Build and continuous integration tools expect it to be in source control. If it is not there, it will not be built. If it was not built, it will not be deployed. If it was not deployed, it will not be tested. If it was not tested, it will not be put to production.