A tale of two passions

A tale of two passions

Recently, I had the chance to speak at KL Elixir Meetup and I shared our journey switching from Ruby/Rails to Elixir/Phoenix in the past 2 years. It recounts the lessons and mistakes we encountered along the way and how it has changed the way I look at problems.

Thanks to the organizer, Syamil for opportunity to engage and get to know the Elixir community in KL. Below are the slides of my talk and I hope you learned something. If you haven’t given Elixir a try, today it’s the day to start.

Veges over pills

Veges over pills

In Ancient China, medicine and doctors played a very different role. Instead of paying for the cure, the Chinese paid the doctor to keep them healthy. They adopted a more preventive approach compared to modern medicine.

Doctors are paid only if their patients remain healthy. It’s like a monthly retainer that’s paused when their patients fell sick and resumed once they are healthy again. 

Even though everyone agrees that prevention is better than the cure, not many have the discipline and conviction to follow through. It’s just much easier to passively ignore the problem and fix it later, rather than actively trying to prevent it.

The problem with problems

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.

  1. Who are the stakeholders?
  2. Who is affected by this problem directly?
  3. What is the temporary measure for now if there’s any?
  4. How critical is the problem?
  5. How soon is the solution required?
  6. What are the edge cases of the problem?
  7. Is there any hidden requirements for the solution?
  8. If yes, can we drop some of them?
  9. If no, who can we talk to about those requirements?
  10. Is there a manual solution for this? 
  11. If yes, who’s doing it now?
  12. If no one is, should someone be doing it?

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.

Don't worry about it

Sometimes you find yourself in a situation where you can't do anything to make it better. If you've explored all the possibilities and still couldn't solve the problem, then don't worry about it and let it be. We are taught how to solve problems but never learned to decide which problem we shouldn't solve. You need to realize that you can't possibly have the answer for everything.

It's okay to walk away from things you can't deal with but just don't use it as an excuse to run away from it.

Understanding the problem

It took me a while to start blogging because I was trying to solve a problem that didn't matter. At first, I was under the impression that it's hard to blog because I simply can't have that many things to talk about. So naturally, my solution was to write shorter posts like those who uses Tumblr. To make matter worse, since I'm a web developer, I decided to code my own blogging platform. Together with John, we got it up in a month or so and started blogging.

It was only a few months into blogging (occasionally) that I realized the problem wasn't the platform. The actual problem was that I didn't understand how and what I wanted to blog about. Only then I realized, what I needed from a blogging platform and switched over to Wordpress.

The lesson to be learned here is that when faced with a problem, try to find out more about it. Don't try to solve a problem without understanding it because you will be just wasting time and effort.

If you can't figure out the problem, face it directly. In my case, I should have just started blogging with any of the blogging platform out there to get a feel on what's keeping me from it. Understanding the problem is the first and most crucial step to solving it.