An issue I’ve been facing lately… how do you switch off at the end of a workday? When is an appropiate time to end the workday? Let’s say you work 9 to 5, is the day done for you come 5pm? or like me do you think about work or a particular problem for the remainder of the evening.

Whatsmore I have my work commitments and I have my own personal projects. Finding time for the latter is tough. Usually by the end of the week I’m pretty burnt out and don’t program all weekend. So I’m left to work on my own projects in the evening, sometimes after a particularly stressful and difficult day at work. In hindsight this probably adds to the burnout feeling come end of week.

To add insult to injury and to call back to something I mentioned earlier, I can find it hard to switch off. I don’t like leaving something unfinished. Seasoned developers and devops guys will probably tell me to breakdown large tasks into smaller ones so that each small task is a win and you can leave feeling good about the days accomplishments. I sometimes find this hard, especially in my personal projects. They’re often pretty large scale. It’s hard to know what to plan when you don’t really know the full scope of the project or how you’re going to achieve it.

On Being Unable to Disconnect

During my final year at university I occasinally played the mobile game Coin Master. It was huge at the time, millions of downloads, TV ads etc.

The game’s developers shared in game rewards on their social media platforms and via a daily newsletter. I thought it would be cool if there was an app that aggregated these and delivered them to the user.

So over a few days I developed non stop making this app. I was pretty familiar with developing Android apps in Java so the app was finished up and running within a matter of days.

I was so focused on this idea and getting it to market that I only stopped programming to sleep. I barely ate, didn’t socialize and certainly didn’t give myself some time to just breathe.

The app went on to be a HUGE hit and commercially did very well for me. But this is where my stuggle with disconnecting from work began. The fear I wouldn’t be first to market or that I was missing out on days of monetization pained me. Part of me probably thought that I should capitalize on this wave of motivation before I lost it and the app fell into a pit of started but never finished projects.

Learning and Developing

About 10 months ago I started work on MetroBee. It’s a metro tram tracker app for Manchester and it’s written entirely in Kotlin.

I’m fairly new to Kotlin and prior to this project I’ve only written one app in Kotlin, and that was Ember.

Ember is a dating companion app. It shows you pickup lines in the familar Tinder swipe format. Swipe left on ones you don’t like and right on the ones you do. Liked Embers stay in your saved section. Additionally theres a section of the app for puns based on peoples names. Such as What's the difference between a wasp and a bee? A wasp is mean and aggressive whilst Abbie is sweet and cute. You get the idea.

Ember was a cool little tech demo of various Android technologies that helped me understand the language a bit more. When learning a new language you normally start of with a Hello World program or something small like a calculator. I don’t ever take this approach. I want to make software that’s cool and useful to people. Usable, marketable products in a way. Ember while functional is a mess in the background and full of bad practices and poorly written code.

So about 6 months into developing MetroBee I found myself in a similar position to Ember. I’d underestimated the scope and complexity of the project. Along with poor planning I was out of my depth. While I’m not gunning for MetroBee to be adopted by thousands of users I want it to be a project and codebase I’m proud of. Something to show on my portfolio. So I decided to start from scratch and rewrite the app with the new practices I’d previously learnt. Now 10 months in and the scope increased again and the code is a mess… again. It’s frustrating.

MetroBee will be fully open sourced once I’m happy with the app and codebase. Until then you can follow the project at metrobee.app and on this blog.

On the Job

For the past 3 years at work I’ve been expanding upon and developing two Xamarin Android apps. With Xamarin support ending in May 2024 I pushed management to adopt native Android over migrating to .NET Maui.

I can’t speak too much on what I’m working on but right now I’m developing the second iteration of our customer facing app Solar.

This second iteration is written in native Android Kotlin and the main issue I’m facing right now is implementing an access token refresh system. This problem is unlike anything I’ve ever faced before. Gone are the plug and play APIs such as Firebase and in are custom internally written APIs. I think developing this app whilst still learning Kotlin fundamentals is quite a big ask of myself and deadlines from management loom. But I like a challenge despite how much stress and frustration it causes me.

Days come and go and sometimes I get nowhere. Trying to retrofit some very well written example code from Stackoverflow into my less well written app. I go home and think of new ideas, new approaches, new solutions to my current problem or sometimes it clicks and I want to jump straight back in and try it out. But I can’t and I shouldn’t.

Wrap up

So thats where I’m at. I’ve got a lot going on and sometimes it feels a little all too much. Perhaps this blog will keep me on track. I understand the importance of having time away from programming. It’s not healthy to work from the moment you wake up to the moment you sleep 5 to 7 days a week. But I’ve got things to make, stuff to learn and a career to advance.

I think the driving force behind this always on mindset is my fear of losing motivation. It’s certainly happened many times with MetroBee. Hitting what seems like an impossible problem and being forced to finish for the day by what is only the dawning of responsibilities for the next coming day. To then lack the motivation to continue when you know the task is so great.

Thanks for reading,
Matt.


Next Article: Kotlin Android - Access tokens, Token expiration, Refresh tokens. Retrofit Interceptors and Authenticators, and Kotlin Coroutines


<
Blog Archive
Archive of all previous blog posts
>
Blog Archive
Archive of all previous blog posts