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 xxx¹.

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

The story so far.

The organisation is fabulous. People have varied from friendly to generous. Three months in and I still haven’t met a single genuine a-hole². The organisation isn’t as well funded as other tech firms, so the perks aren’t super-great. But they more than make up for it in general culture, friendliness, training, inclusiveness, and outreach.

The small size of our team has offered me lots of opportunities to work on, and learn, across all parts of the app. On the dev tech front, DI with Dagger has now become second nature, and CI/CD is just another detail of the work day. I learnt the Use Case pattern and about the Strategy pattern. I’ve learnt new unit testing techniques, particularly using mockito and for async functions. I’m leading the modularisation of a key part of the app, and produced a feature for an internal hackday. I even introduced the team to ViewBinding and DataBinding, as alternatives to the now deprecated synthetic binding we use in the app.

I am also learning to accept the constraints of working in a larger engineering organisation. For instance, we use the older, much-harder-to-use RxJava for async operations instead of the much easier to use Coroutines. The other developers are too comfortable with RxJava, and I’ve been unable to convince them to even consider Coroutines. There’s also the learning to live with frustration of not having things go the right(/my) way. My attempts at recommending better documentation practices and some UX improvements were quietly ignored, blatantly brushed aside, or rejected with spite.

Some differences arise from personal motivation. For instance, I take pride in how the user experiences my product. That drives me to always prioritise UX improvements over internal engineering improvements. The team culture here is oriented towards focusing solely on the how the product is built. UX/UI — how the user experiences the app — are external to the engineering organisation. I’ve been instructed (directly and indirectly) not to focus on, or give feedback on the UX/UI or product direction. It’s frustrating, but I’m learning to keep my UX/UI opinions to myself. I still prefer to be a product engineer rather than a software developer, but will have to get my product satisfaction from my personal projects.

I’ve only just started. It’s been a good, rewarding start, despite the occasional frustration. I’m 1/12th into the minimum period I promised myself in this career. Here’s to hoping the next 11/12ths are just as full of learning and delivering, but with a fraction of the frustration.