Even if your toothbrush is newer, cleaner, fancier, more colorful, electrically powered or emits ultrasonic wave, I still prefer mine. After all, why would I want to use someone else’s toothbrush. Yuck!
This is fine if we are just talking about toothbrushes but in reality, we have the same concept towards other peoples’ ideas. We tend to prefer ideas we came up with rather than those from others. This is known as the Not-Invented-Here bias or the Toothbrush Theory.
At last year’s Team Retreat, while enjoying the breeze on Khao Lak Beach in Thailand, I told the rest of the team that I don’t care about people. We were playing Two Truths One Lie and there are times when I’m unsure if that statement was true or a lie.
Studies have shown that willpower is a limited mental resource. Every time you make a decision, it depletes that same energy resource your willpower uses and eventually you’ll give in to your desires. This is known as Ego Depletion.
The single most important advice Peter Thiel (Co-founder of PayPal & Palantir) gave to Brian Chesky (CEO of AirBnB) after he invested $150M in the company was, “Don’t f**k up the culture”.
He didn’t say “Don’t waste the money” or “Don’t buy a Ferrari”. What he is implying is that you need a good culture to build a successful company. But what the heck is company culture?
On the first Tuesday of every month, for more than 3 years now, I have had the privilege of meeting some of the most talented and inspiring people in our city — Kota Kinabalu. All thanks to WebCamp KK.
WebCamp KK is a community of people from different backgrounds and industries who are passionate about what they do. These are the ones that inspire others into action. The ones who believe in sharing and helping each other improve our city.
What started as a simple gathering of like-minded people, has now turned into a movement that sparks connections, spawns communities and continues to be a source of inspiration for many.
Early this year, in an attempt to shape and define our company culture, my co-founder John and I came up with a set of guiding principles for the company.
We decided we want our team to have the heart to serve, to communicate well, to constantly adapt to change and to make each other better.
Most of us are quite familiar with the idea of setting goals. When you are younger, your teacher may have asked bout your ambition. What do you want to be when you grow up? When you attend your first job interview, the interviewer may ask: Where do you see yourself in next five years? And when you are in the workforce, your bosses and managers will ask for your annual goals.
Setting goals let us focus on what we want to achieve. It gives us motivation and a sense of purpose. It is also a way for us to measure our progress. Having a goal is like having a sense of where you want to go and a way to track your progress towards that direction.
The Lean Startup is one of those books that changes the way you approach, validate and build a product. It encourages an iterative process of experimentation and validation to learn more about customer needs and reduce risk and waste of resources.
In other words, it is about learning and getting as much feedback as you can from the user and use that to guide your product development process. Too often, startups spend their time building the product in isolation without any contact with users until release.
We have built quite a few apps over the years at Flexnode and Showtimes.my is one our favourites. It is also quite popular with around 200k hits monthly. Unfortunately, the 5 year old app broke and stop working recently, so John and I decided it is about time to rebuild it.
Since we are rebuilding the app, it is the perfect time to do some work on the dated design. Having used the app for years, we are quite familiar with the shortcomings. In this post, I'm going to walk you through some of our initial thought process we had when building the original app and what we are changing in the redesign.
As a software engineer or developer, our main job is to solve problems. The solution may come in many forms like automation or abstraction but ultimately we are writing code, designing architectures and engineering solutions to solve problems.
Either because of our formal training or the engineering culture, we put too much emphasis on how we solve a problem than the problem itself. We are all on this quest to seek and ultimately build the holy grail solution. The solution that would end all problems.
Naturally, it is more exciting to talk about the solution of the problem rather than the problem itself. After all, we usually have more control over the solution compared to the problem. But in order to come up with a solution that works well, it is crucial for us to first understand what exactly we are trying to solve.
The first step towards solving a problem is not applying, designing or building solutions but to gather as much information you can about the problem. Only after you have a clear understanding of what you are trying to solve can you come up with a solution that works well.
The problem with problems is not the difficulty in solving them but rather the lack of understanding and clarity on what is it that we are trying to solve. If you can’t seem to wrap your head around the problem space, try asking some of these questions.
There’s a saying that the best line of code is the line not written. In this case, the best solution is the one not built. If you can render the problem obsolete simply by understanding it, you basically solved it without having to build anything. That is the real holy grail solution.
This is a technique I learned over the years from project management gurus to manage time and boost productivity. Instead of letting a task or agenda take as long as it needs to be completed, you set a hard deadline or “time box” for it.
A simple example would be the time limit we have for our daily meetings where we time-boxed it to 10 minutes. This means the meeting can not last more than 10 minutes and if it does, we just end it right away. This is very useful to make sure we don't waste everyone’s time and get straight to the point.
The Pomodoro technique also employs this strategy by time-boxing your task into 25 minutes interval separated by short breaks. (e.g. 3-5 minutes) This teaches you to break tasks into small chunks that can be accomplished within each interval.
Timeboxing has been very useful in software development. The limit forces you to aim for some sort of deliverables when you approach the deadline. It prevents you from spending too much time on a particular task and affects the deliverability of others tasks in the pipeline. The notion of a sprint in Agile/Scrum is basically a timebox of 1-2 weeks.
Keep meetings short by timeboxing them.
Plan and schedule tasks that can be completed within a fixed time-frame (e.g. a sprint of 2 weeks)
This is not only useful for your work but also serves as a time management tool in your personal life. Start timeboxing your life and you may discover that you can get more things done.
