1. I am not writing notes when reading books anymore. This is bad because knowing myself, I am not able to remember most of what I read! Most of what I read, therefore, fades into the ether in a short time.

2. I write a daily note but don’t refer back to follow-up on ideas. This means that I leave a trail of forgotten but potentially interesting ideas that I once believed I wanted to explore (since I noted it down in the first place).

3. I don’t care about linking notes at the moment because they do not enable serendipity for me. This is not ideal because I know intuitively that most ideas do not stand on their own, but instead, relates to other ideas that I have already thought about.

4. I constantly forget what my information processing workflow is. After a while, I completely lose a grip on what that workflow looks like. Once I’m this lost, I’m no longer encouraged to think about other notes when I’m writing a new note, thereby regressing to a plain note-taking process and not a knowledge management process. An interesting solution I’ve recently discovered from Bryan Jenks (using Obsidian): creating a visual flowchart depicting various types of inputs and how to process them differently according to my preferences.

5. I write weekly blog posts without consulting any of my notes except for the ones that contain ideas for blog posts. This means that I have a good process for capturing blog article ideas but I have no process at all for walking through my existing notes, a handful of which I am confident would turn out to be helpful. Those notes unfortunately just sit there with untapped potential energy.

6. I love reading but often feel like everything I read is only for pleasure or fleeting knowledge, not long-term knowledge retention and growth around the few central topics that I care deeply about at any time. This lack of confidence in my information processing mechanism quite easily translates into a kind of knowledge nihilism where I give up reading anything longer than an article for true understanding. This is a bad sign because it is demoralising and ultimately spells intellectual stagnation.

7. I do not feel like I’m growing in knowledge around any particular topic outside of work. What I learn, I learn from reading and immediately doing/applying/revising, not from writing it down and revisiting much later. But from what I understand, one of the chief reasons for having a personal knowledge management system is to build an artificial conversation partner that helps you revisit and draw connections and thereby deepen your knowledge around a topic. When I think deep about a particular topic, I do not (and have not in a long time) feel inclined to sit down at my computer with my existing notes to talk to myself.

So, what now?

I’m exploring Obsidian as a new tool to replace the current Bear app that I’m using as a personal knowledge management system. I’ve already looked into Obsidian once, but that was before they released a functional mobile app. It has a lot going for it and I’m optimistic that its design choices will help me improve my information processing mechanism.

I’ve proclaimed something contradictory earlier this year in a blog post:

Your tool is probably good enough already. Focus on making thoughtful notes.

But I’m back on the fence thinking that my current tool probably isn’t good enough to help me achieve all of the above, so it’s time to explore again.

Your product probably isn’t perfect and that’s why you need to provide customer support. This is the imperfect starting point of the whole enterprise of customer support that makes it a challenge from the get go.

I know this because I have been providing and organising customer support for one of the biggest advertising tech products in the world for the last 3 years. I’ve spent on average 8 hours every week providing direct chat support to our enterprise customers from around the world, and I spend the rest of the time building internal tools to make support scale with the company’s growth.

I’d never done support before I started in this role, and I had always thought that providing customer support is easy. As long as you train people to know your product, they should be able to provide high-quality, fuss-free support to your customers. How hard is that?

Well, after 3 years, I can tell you at least 8 hard things I’ve learned about providing customer support.

1. The product is constantly evolving. This means your supporters must not only provide support for it but continually learn how to use it. In the meantime, new questions that have never been asked before will come up, and the supporter must have direct contact with the product and engineering teams to be able to give the customer a timely answer.

2. The support team must have direct contact with the product and engineering teams to be effective. Every layer of separation between those teams will translate into hours of waiting time for the customer who is already struggling to accomplish something with your product. This proximity means that if you offshore your customer support team, you have set yourself up to receive a mob of angry customers and, likely, a lot of them will eventually churn.

3. Product teams ought to know how much customer support they generate, but it’s tricky to attribute support load to specific areas of the product when they are interconnected.

4. People often communicate poorly. Too much time in customer support goes into asking clarifying questions (if the supporter even knows to ask clarifying questions) so that the supporter and the user talk about the same thing.

5. If your company uses other teams (not just the support team) to provide customer support, organising them can be extremely tedious. Problems range from penalty-free no-shows to providing continual internal training that translates only to a marginal number of support hours.

6. Tech product bugs require technical supporters to file them. That means that every supporter hired needs to be more or less as qualified as someone who could be on your software engineering team. And most people with those skills usually prefer (and are better at) building things, not troubleshooting and communicating with customers.

7. Product knowledge is unevenly distributed among supporters, and relying on training sessions to spread knowledge is a slow process. Trying to share knowledge employing an internal wiki helps, but it also creates problems like circulating outdated information.

8. Customer support has various aspects, and it can be difficult to keep the teams responsible for each aspect collaborating effectively. For example, you may have a Help Centre for self-help. You would probably also have support chat, which connects the user directly to a supporter. You may also have Customer Success Managers who provide support for things like strategy. You may also have a process for notifying users when the bugs affecting them have been resolved by the engineering team. All of these are pieces to the puzzle of customer support, and orchestrating a consistent support experience is vital but complex.

My wife and I just came back from a 3-day trip over the weekend to Hamburg and if I’ve learned anything on this trip, it is this: home is a fluid concept.

Two years ago if you had asked me where is home, I would have told you without hesitating for a moment: Singapore. It’s where I was born and where I grew up. It was all I knew firsthand, apart from the short overseas vacations and a 1-month summer school in London.

But since I was very young, and my mum tells me this story all the time, I would plead to my parents about wanting to study and live abroad. So I had always wondered if it was possible to recognise a different city in another country as my home.

Our trip to Hamburg ended with a night train that chugged eastwards for two hours. When we finally unlocked the door to our apartment, I felt it. An unmistakable feeling of “I am home.” That surprised me because I hadn’t expected it, but it also wasn’t a surprise to me the moment I thought about it.

Home is the space where you go to rest, where your mind and heart and soul can be quiet and completely at ease. With my wife and dog stepping into the apartment that we furnished, configured, and made together, in a city where I know I’m always a stone’s throw away from serene green spaces that are free for use (and with good weather), where any medical emergency cannot impoverish me or my family, I know I am home.

Software engineering has enabled us to live in Berlin. Picture: us on the first day of moving into our new unfurnished rental apartment in Mitte, Berlin.

I graduated in 2015 with a bachelor’s degree in environmental studies and no knowledge of how to code. Now, in 2021, I’m leading a team of software engineers based in Singapore and Finland, building internal tools for one of the largest advertising tech companies in the world.

And now I feel like I have fallen out of love with the craft. This is my honest reflection about software engineering work from my perspective after 5 years of earning a wage from it.

In 2016 I started a company called Flowriter to build a physical machine that was meant to meet a market gap: a laptop built just for writers. No more bouncing from multi-purpose modern laptops to analogue and cumbersome metal typewriters. It was to be the modern-day writer’s tool.

It got nowhere, and no wonder. I had no tech skills! I knew nothing about technology apart from how to use it in neatly packaged end-products like the iPhone and Macbook and the App Store. How was I, an environmental studies major, supposed to build a new computer-based tool?

So I enrolled in a programming bootcamp. It was wonderful. Going to class to learn about HTML, CSS, and later on JavaScript and Ruby, I experienced many revelations and felt like a wizard. I could build anything that could run on a browser and the only thing that limited me was my imagination.

When I was done with the bootcamp, I got carried away and first became a teaching assistant (yes, fresh out of bootcamp myself), and then I got a full-time job as a junior software engineer at a little known software-consultancy-trying-to-become-a-product-company company. My original goal of building a writer’s laptop was shelved and in 2019 was accomplished by a US-based company called Astrohaus, whose Freewrite product I now own. This article and many others are written on it.

I learned a lot in a very short time about software engineering on that first job fresh out of bootcamp, and it was an interesting time. It was stressful but also rewarding.

I knew I wouldn’t stay in that company shortly after I joined because I could tell it wasn’t going to grow. I mean, I was a junior software engineer and I was the main person building their product (red flag!). About a year and a half later, I left and pursued a brief teaching stint at the bootcamp from which I graduated.

This was about the time Charlane and I wanted to relocate to somewhere outside of Singapore. We shared the same dream of living abroad if not permanently, at least temporarily, so that we could transform and broaden our worldview. Singapore is but a tiny dot on the map and we knew the world had more on offer.

I remember feeling thankful and lucky that I accidentally crossed paths with software engineering because it was our key to move abroad. Programming skills were in high demand as old companies were undergoing “digital transformation” and new tech startups were sprouting up in every major city. Even with less than two years of experience building applications, I knew I could get jobs in a different country and city.

So we set our sights on the city that left a deep impression on both of us: San Francisco. We were there for our first road trip together, and I was there touring Silicon Valley startups as part of my university entrepreneurship program before she had arrived for that road trip.

The job hunt was harder than I thought, but I still had a healthy pipeline of companies who were willing to consider me and were scheduling first calls.

At this time, I was still teaching at the bootcamp and one day, I bumped into a person whom I hadn’t seen for a while on campus. His name was Jun Kai, and he was, like me, a graduate from the programming bootcamp.

I asked him what he was doing on campus and he told me that he was recruiting fresh graduates to join the company he’s working for. Casually, I asked him if the company had an office in San Francisco and just as casually, he said “yes.” The company, he told me, is called Smartly.io. Three years have passed since I started working here.

During my interview process at Smartly.io, I asked point-blank if I could be moved to their San Francisco office and they said “maybe.” The person who interviewed me said that it would be possible, but it would depend on my performance. They wanted me to work for at least a year in the Singapore office before they would consider moving me. I took the risk and accepted the offer, respectfully halting my job applications to San Francisco based companies.

A year went by and I reopened the question with HR. This was when I knew that San Francisco was not going to happen any time soon for us because of the Trump administration’s protectionist policies. I was offered two alternatives (for which I am still extremely grateful): Helsinki, Finland, or Berlin, Germany. I chose the less cold city of Berlin and have lived here for the last one and a half years.

Alright, so far I’ve described how I started on the path of software engineering and how it enabled me to fulfil one of me and my wife’s dream of living abroad, and how thankful I am. But there is one crucial part of the story that I haven’t told you: my fizzling interest in software development, catalysed by the job I ended up doing at Smartly.io.

My title at Smartly.io when I started was something that took me over a year to understand — I was to be a Service Operations Engineer. The industry did not have a title like that and I had a hard time explaining to my mum what I do. But the title wasn’t the problem. The job scope was.

I spent 20 percent of my time coding, while the remaining 80 percent of my time was always spent providing technical support to customers or training Customer Success Managers on how to do technical product troubleshooting. I learned a lot about the hard things of providing high quality customer support, but I believe this increasing distance from day-to-day programming work was what eventually helped me see that the intrigue of programming had evaporated from me.

Put another way: I found myself no longer that interested in software development. Building something new or fixing a bug is something I still find fun doing, but only occasionally.

At this time, a number of my colleagues in the same team (Service Operations) who were based in Helsinki moved to join the Engineering team as product software developers. A lot of people from our team go on to join many different teams - we even wrote a blog post about that. I stayed on, even though I know I could make the same move. A few months later, I clinched the role of team lead - the role I’ve been playing in the last 6 months.

And so, here I am, leading a team of 8 internal tools software engineers, not being very excited about software development.

I see a few potential paths forward, some involving changing roles in the company, others requiring more drastic change. Of course, there’s the option of staying in the role too, in which I think I’m doing a decent job from the managerial perspective. After all, I am able to do the job. I’m just finding myself a little less interested in doing it with each passing week.

How does one ultimately decide what the next step in their career should be? I don’t know, but I know one needs to consider his unique circumstance and priorities.

Even though this essay may appear to be somewhat depressing, especially towards the end, I must say this: I am very grateful for the opportunities that have come up because of software engineering. I know that I am lucky to have a choice. That said, having a choice means having to do some thinking beforehand so that it may become a good decision.

We decided to buy many appliances on Amazon Prime Day recently and I felt the need to justify it to myself because, well, we’ve lived a year and a half in Germany without them. So why do we need them now? Was it just because of the discounts?

To talk something concrete, let me list the things we bought: a slow cooker, two Tefal nonstick pans, a washer-dryer combo laundry machine, a night light, a weighing scale, a rice cooker, and an Amazon Echo Dot.

Now on to justifying.

For as long as I can remember, I’ve had issues with convenience. More accurately, I’ve always found that convenience is not always a good thing.

Convenience makes people lazy, inconsiderate, and ungrateful. Everything should be done chop-chop so that one can move on to the next thing, pronto. Convenience, creature comforts, luxuries… I lump these into the same bucket of things that make your life better only if you know where you are going. It’s like that Echosmith song:

Yeah, they’re living the good life, can’t see what he is going through They’re driving fast cars, but they don’t know where they’re going In the fast lane, living life without knowing

For a year and a half living in Germany, I’ve not needed the convenience that these recent purchases will afford me and my wife. So what changed?

Simple: we’re preparing for our firstborn daughter, Charlotte. And we could use some convenience to balance out the new inconveniences that any newborn child would bring into a couple’s lives!

A slow cooker is going to help make nutritious soups hands-free and keep them warm throughout the day.

A washer-dryer combo is going to shave 15 to 20 minutes off each laundry run by shifting from washing to drying automatically. This I expect is going to be particularly helpful with food-stained and poop-soiled clothes. (TK insert onslaught)

The Tefal nonstick pans, which so far works stupendously, will help us cook and wash up faster.

The night lamp is going to help us change Charlotte’s diaper without bringing on a light flood that jolts her awake if she was already sleepy. From what I’ve learned from friends of ours, this is going to ultimately let us sleep train her so that we can in turn sleep for longer blocks of time.

The weighing scale is for keeping track of our body weight as well as Charlotte’s. You know, BMI healthy living stuff.

The rice cooker is going to help us make rice and keep it warm, hands-free.

And the Amazon Echo Dot I think is going to help us play white noise in the room where she is going to sleep. I’ll be scheduling a routine for the Alexa app to do this for sure.

So that’s it. Writing this down helped justify the purchase of convenience to myself. All of this is so that we can, hopefully, help a baby grow healthily.