Product Engineer, Moi

tldr: I switched careers. I am now an Android developer in a small team at a mid-sized organisation.

In early 2012, I taught myself some Javascript and created my first Chrome extension, AutoConvert.

It was a simple tool to fulfil my specific need—automatically convert units between imperial (the somewhat idiotic unit system that my host country uses) and metric (the much more sensible unit system I grew up with). The code was beginner-level, the design non-existent, and I’d heavily relied on Bootstrap and jQuery. But I’d hit on a user need, and the extension got a little over 15,000 users at its peak.

Encouraged by that first step, I learnt more about Javascript development and other libraries, and created a few more Chrome extensions to satisfy my other itches when the need arose.

Sometime in 2014-15, I took a free, self-administered course on Android development on Udacity. I wanted to fulfil another personal need — create a native Android app for a platform we were using at the time, iDoneThis.

Java was a lot harder, more verbose, and fairly rigid coming from Javascript. Android was way more restrictive as a platform compared to Chrome and the Web. Eclipse was a memory and CPU hog compared to SublimeText. Android apps were harder to develop and iterate. After iDoneThis, I didn’t develop another Android app for a couple of years.

In 2017, I started developing my next Android app — Todo.txt for Android. This was again based on scratching a personal itch. I’m a todo.txt user, and the OG app had stopped working after the original developer didn’t update it when Dropbox changed their API. This new app too started as a Java codebase. But on the, now, 3 year long journey of developing and updating the app, I learnt a lot of new technologies—converted the codebase to Kotlin, replaced AsyncTasks with Coroutines, adopted the MVVM arch with a single Activity, learnt to write and always add unit tests.

Kotlin combined with Android Studio and the Jetpack architecture components brought both speed and structure to my (and the app’s) development. I developed three more Android apps. On the web side, VS Code and Javascript libraries helped me get more productive.

In late 2019, I was frustrated with life in general, consulting in particular, and looking for contentment. After a lot of thought, and encouragement from R, I decided to give a year to attempt a career switch: to become a Product Engineer.

I was indifferent between Android and Web development—I enjoyed both equally. But I knew that I needed to learn a lot on both, particularly technologies and processes used by engineering organisations that I hadn’t needed to use as an amateur solo developer. So I devoted the rest of 2019 and 2020 to filling the gaps. I discovered, learnt and adopted, amongst others, Webpack, Retrofit, Promises, Android library modules, cloud functions with Firebase, Firestore, Gradle tasks, VS Code tasks, Data Binding, and many others. I adopted the Github PR process despite being a solo developer—opened the PRs, reviewed them myself, then merged them in.

Some things I considered but chose not to pursue—CI/CD and dependency injection being top two. Unlike the other technologies/processes, the cost-benefit proposition for these was vastly lopsided as an individual developer and at my apps’ scale.

I also started applying for developer roles, all the way from entry-level associates to senior lead developers. I got a few interviews. As the year went on, I went further in some interview processes. Finally, in October, I was offered a job as an Android developer at xxx1.

I completed my 3 month probation earlier this month, and was welcomed aboard as a permanent employee. I’m now officially an Android developer.
Continue reading Product Engineer, Moi

New beginnings

On Monday, I start a new job and a new career. I’m a bit excited, and quite scared. (R is trés excited, not scared at all)

The fears

The first fear is from all the documentation, processing, and related formal requirements. That’s a foreground worry, as I’m working on it at the moment. It’s also the simplest, since if it becomes an issue, it’ll be placed right up in front of me to deal with.

The big worry is the background anxiety from the transition to this new career.
This is my first job in this field. At 41 years old. I’m starting from the bottom rung (good), but at a big, established organisation (scary). They have experienced people, processes, and the thing I’ll work on will reach out to millions of people (trés scary). I am not sure if I’m qualified for the work they expect (I was surprised to even get the first interview call). I’ve never worked on something at this scale. I haven’t worked on anything that complex. I haven’t worked in this industry at all. The likelihood of my completely bombing is fairly high. At the first job. In a new career. At 41. There may not be another restart option.

I love to work from home at my own times. I’m a strong advocate for remote working. In this case, however, I miss not being in the same shared office. Looking at everyone’s faces directly would have provided a good gauge of how I’m doing. Working remotely, online, removes that direct, immediate feedback mechanism. I’m dependent on other people to be kind enough to provide quick, direct and honest feedback. (And hopefully, to work with me at helping me improve.)

Another worry is that this career switch means I am permanently trading in the old career. There won’t be any going back. It’s a different ladder now. A ladder, as R says, I enjoy more. But also one that doesn’t go anywhere as high or as fast as the previous ones. The ceiling is strong and near in this career. In the previous one, sky was the limit (given willingness to get burnt). The change means saying goodbye to many things. And saying hello to occasional, depressing bouts of ‘what if‘.

The joy

There’s also joy. I’m going to be doing something that I enjoy doing. I’m going to be part of a team, and have an opportunity to make some stable connections outside of home and running. I’m going to be working at an organisation that I like, on a thing that I really like. Unless I bomb early and completely, I may even be able to make some things better. And, if I survive, I’ll get to learn. A lot. In areas that interest me. That learning, along with having stable team mates, is probably my biggest incentive. (R has a different one.)

Definition: Flexible working hours

What does it mean when the job description says “flexible working hours”?

Old definition:

We, the firm, are flexible on the hours you want to work. You choose the hours you want to work, we just want the work done.

New definition1:

We want you to be flexible, to work the hours that we want. Don’t expect fixed, or predictable hours. Be ready to work when we say, for how long we say.


  1. Mostly seen in the startup and on-demand (Uber/Deliveroo) sectors.