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
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
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
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
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
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
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,
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.
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-hole2. 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
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.
- Incidentally, this was just after I’d again started applying for consulting roles. At the time of this offer, I was interviewing for this role, a lead developer role, and a head of business/strategy role at an old startup client. ↩
- In my previous industry, this ratio would usually be reversed. Which makes me wonder about a version of the old poker saying: If I haven’t met an a-hole yet, am I the a-hole in the team? ↩