- Insights This article was written by a TIA community member. Insights pieces undergo the same rigorous editorial process that newsroom-produced articles have.
How learning to code changed the way I think as a startup founder
Last year, I decided to start Seek Sophie, an online travel platform. As neither my co-founder nor I had a technical background, I decided that I should learn coding so I could build the platform from scratch. At the time, I had no idea what the difference between a WordPress site and a website from scratch was.
Friends told me I was being silly. I was a first-time startup founder already grappling with a whole load of unknowns, and yet I was choosing to take on another huge unknown. Why was I not staying within my area of competency (i.e. the business/corporate side of things)?

During those early months of learning, it just seemed obvious that a founder of a tech business should understand the business’ foundation.
I kept tossing around this question in my head: If I were starting a hotel business, I wouldn’t feel the need to learn civil engineering. But why did I feel the need to learn coding for my online business?
Five months after I learned how to code, we launched seeksophie.com. In the process of building the site, I had my answers.
1. It’s not about the code, it’s about a way of thinking

On the first day of my coding bootcamp, our instructor told us that they weren’t teaching us code, they were teaching us how to think. I liked the sound of that, but I was skeptical. Pretty quickly, I realized that the world of coding was different from anything I had ever known before.
In my years of schooling and corporate law career, the focus was often on finding the right answer. Because there’s a right answer, there’s also a wrong answer. With that mindset also came perfectionism and shame associated with not getting the right answer.
Coding was different. Because everyone’s codebase is so different, what works for one person’s code may be pretty different from what works for someone else’s. So, there is no one single right answer, but different right answers for different codebases.
Then, there are the bugs, which are integral to the process. Debugging is a core skill for developers. When bugs are seen as a natural part of a process rather than anathema, this removes the fear of bugs—or failure. All the focus then gets channeled into doing the detective work for debugging instead of dealing with the shame of failure.
As I iterate our site to achieve product-market fit, I don’t get attached to a perfect solution nor get bogged down by the shame of something not working out. I just see the whole process as detective work . If this new feature doesn’t increase the conversion rate, I’ll just find another way.
2. How good a cake is depends on the quality of its ingredients
When building a product, there are many micro-decisions that need to be made (how the information architecture is designed, which third-party APIs to use, how to manage app memory, etc.). These micro-decisions will ultimately impact whether the business’ vision is achieved in the short or medium term.
3. When our users say jump, we only ask how high
4. Jumping off a cliff and waiting for “the one”
5. If we speak the same language, maybe we’ll all get along
6. If we survive to fight another day, we have a chance of making it
Stay updated on the go with our mobile app.
Get latest insights with smoother, more personalized experience through TIA mobile app.






