Optimising My Life

Be Humble

I was about 20 years old the first time I managed employees. I had already been a developer and a business owner for several years by then.

I’ve always been acknowledged by everyone as being quite smart. Unfortunately, that made me a bit arrogant. I thought I knew everything there was to know about writing code. I was certain that even if I didn’t, there would be few who could teach me something new.

Luckily for me, I was humbled fairly quickly. I learned simple ideas such as early returns from junior developers I hired. This changed my perspective entirely.

I am now happy to admit my ignorance. I am open to learning from anyone. I no longer assume people with less experience can’t teach me anything. In fact, I find it very likely they can.

My point? You can be very good. You can be exceptional. You will still slow your growth if you don’t stay modest. Respect everyone. Be humble.

Be A Karen

When dealing with retailers, service providers, government offices and corporates I often feel small. They have plenty of manpower, automated systems, lawyers and seemingly unlimited resources.

So it’s easy for me to give up when they take my money where they shouldn’t, or refuse service. Forget about that £5 over-charge. Say goodbye to the £10 fee for an automated renewal you never wanted. Pay for a repair of a faulty product.

But it doesn’t have to be this way. If there’s something I learned from experience, it’s that you should never accept these injustices. Report the issue. Ask for a refund. If you’re not happy with the response, complain. Escalate to a manager.

Corporates and large bodies may have policies in place and some tolerance for pushback. So can you. Don’t let it go. The more of us who push back, the more careful they will be about pulling those stunts.

So yeah, it’d funny to see a Karen blow up. But Karen may have a point.

Get Off The Script

I just called a broker about a mortgage. The person on the other side of the line was extremely nice. We had a pleasant conversation, and I really felt I was getting a personal service. This was great.

And then, half way through the process, she started reading the marketing spiel off her script. About a minute’s worth of pure praise of their service, with statistics and random figures. The personal touch magic wore off immediately.

Now, I know it’s not her fault. She was instructed to read that speech to me. The problem is with whoever it was who thought that was a good idea. I’m sure they feel it’s important to convey their success rates to new clients. The problem is, this isn’t the way to do it.

Be creative. Give your representatives key points they should convey during the call. Don’t sabotage their efforts to give a good service. Let them be honest, and kind and sympathetic. A marketing script is none of that. Don’t kill the magic.

Help Me Help You

There are services we all use. Services such as Amazon, Netflix, Spotify and so forth.

All of these services spend tremendous efforts into giving us a personally tailored experience. An experience that would match our personal preferences.

Unfortunately, nothing comes for free. If we want an experience that is really a good fit for us, we have to put in some work.

All of these services rely on data they collect to make adjustments for us. We can modify much of this data to get better results.

So what should we do? Upvote content you like. Downvote content you don’t. Go through your activity history. Remove any items you are not interested in.

Pretty soon, you’ll start noticing the suggestions you’re getting become more relevant. Content will become less spammy.

A tailored experience is a better experience. Consider spending the time to make sure you get one.

Clean Android

As an Android developer, I spend a lot of my time worrying about app architecture.

Android has a long history of attempts at a convention. We’ve had Activity god classes. We then had fragment god classes. Along came MVP (Model-View-Presenter) with its presenters, which really improved things, but often led to god presenter classes.

More recently, Google introduced the Android Architecture Components, and we started using MVVM (Model-View-ViewModel). Somewhere along the transition from presenters to view models, I started seeing attempts at implementing clean architecture.

The problem with clean architecture is, it’s a bit of an abstract concept. If you read the Clean Architecture book, you are left with a vague notion of how a clean architecture would be implemented.

So it took a few iterations until my colleagues and I finally found a consistent architecture that works.

And this, very briefly, is how I now implement a clean architecture feature in an Android App:

I start with the domain. This is where my use cases are, as well as my domain models and my repository interfaces. Because it should not be coupled to anything in data or the UI, my domain layer is very straightforward. Repository interfaces are designed ignoring any APIs I would need entirely. They describe precisely what I need to present something to the user. My use case output is as simple: it defines all the data that should be presented to the user.

I wrap it up by stubbing my repositories, so that my upcoming presentation could start utilising the domain layer.

Once the domain is in place, I can proceed to my data and presentation layers.

The data layer contains repository implementations, data sources and mappers from domain to data and from data to data sources (APIs, databases, etc.) and vice versa.

I start by implementing my repositories. These are the entities that would eventually grab me the data I need and persist the data I need persisted.

The way repositories achieve this is by using data sources. Each data source abstracts a single source of data: an API, a local store or the Android API, for example. Since repositories should not be coupled to APIs either, their models reflect what the domain needs rather than what an API would provide. They mostly “speak” using data models. These are mapped from and to domain or data sources.

To wrap up my data implementation, I implement my data sources. The mappers from the data sources to the data is usually where most of the data massaging happens.

On the presentation layer I have my ViewModels and mappers to and from domain. This is where my presentation logic lives. It does not know about the UI. I usually like to imagine the UI as being a terminal, and then see if my implementation still makes sense. The ViewModel exposes function to the UI the describe the events presentation cares about. It also executes use cases and updates the view state and navigation.

Lastly, I have the UI. The UI layer is where my application, activities, fragments, custom views and mappers to and from presentation live. The fragments, activities and custom views can all act as views in the MVVM sense. They can all own ViewModels. They communicate with their ViewModels by calling the event functions. They observe the ViewModels for view state and navigation.

Everything is tied together using DI (Dependency Injection) in my main module. I use Dagger and Hilt, having had poor experience with Koin. This is what Clean Architecture refers to as the “dirty main”.

I tried to keep this explanation short. Clean Architecture is a vast topic, and its application to Android is quite complex as well. I hope this helps somebody!

_{I may get commissions for purchases made through links in this post.}

Tightly Packed

I like efficiency. Sometimes life feels like a puzzle. Solving the puzzle means achieving the ultimate efficiency.

How do I fit as many dishes as possible into the dishwasher? How do I pack everything I need in this small suitcase?

Interestingly, I found there are different solutions to those similar problems.

Just like when solving a puzzle I would start with the corners and continue to find all the edges, most solutions follow an optimal pattern.

For the dishwasher, the most efficient way I could find was to go small to large. That way, your large dishes end up covering the smaller ones.

For the suitcase, I would start with the larger items, then go smaller, filling the gaps left by the larger items.

What similar challenges have you faced? What was your solution?

Not Good Enough

I’m a perfectionist. I know a lot of people testify this about themselves. But I truly am.

Nowadays, there seems to be a trend of “good enough”. It stems from a sensible idea that the final 20% of the work will add marginal value (not to be confused with the 80/20 rule). I get that. It’s usually true.

The problem is, it’s a slippery slope. Once you start loosening your standards, they tend to dissipate. How do you measure a quality of 80%? How do you know you’ve reached “good enough”?

It seems in most cases we all err on the side of less than enough. This is what I’m not comfortable with. So I try to aim above “good enough”. I’d rather spend a little more time than absolutely necessary than a bit less.

I firmly believe mediocrity is the enemy. This is what leads to disasters where people lose their lives. It’s no joke. OK, it also means my banking app isn’t as great as it could be.

Let’s ditch the “good enough” attitude. Let’s aim higher. We can do better.

Do One Thing Well

I’m an Android user. I’m also a Windows user. I tried the iPhone, and I’ve used a MacBook for a few years. The latter two didn’t grow on me.

Different operating systems offer different experiences. Which works best for you is an individual preference. Once you get used to one, though, it’s hard to switch.

This is why most successful apps are developed natively per platform. Using the same app on a different platform will feel different. It would feel natural within its environment.

Despite those distinct differences, the dream of multi-platform solutions lives on. PhoneGap (later named Cordova), Titanium, React Native and Flutter are just a few examples.

And all of these attempts, in my experience, are doomed to fail.

You simply can’t maintain a high quality user-experience between platforms in one code-base. You can develop to the lowest common denominator. Or you can support every feature offered by every platform. Your framework will essentially be at least a step behind the native environment.

You also have to rely on fewer developers. Most developers would specialise in a native technology.

My suggestion? Don’t fall for the woos of cross-platform frameworks. Go native. Native solutions do one thing, and they do it well. You will save money in the long run. You will develop faster, and your user-experience will be better.

Together, Nothing Can Stop Us

I have owned and managed several companies in my life. I ran none of them alone.

Choosing the right partner is a challenge. My intuition led me to seek people who were like-minded. Choosing someone who is also a friend kept me in my comfort zone.

It took me many years and an insight from a valuable employee to realise I was doing it wrong.

Today I know what to look for in a partner. You don’t need someone who thinks like you. You definitely don’t need a friend.

You need someone who’ll challenge your thinking. You need someone who can compensate where your skills are lacking.

Know your weeknesses. Know your strengths. Find a partner who completes you. And by your powers combined, I am Captain Pla… Sorry, got carried away there.