This tweet from my friend Igor Wojda triggered this article. What he said is true but for some reason, I immediately thought about this in a different way. Retention. I’m a manager now 😁

Part of what makes programming exciting and difficult is that most of the time we’re doing things we’ve never done before 👨‍🏫

— Igor Wojda 🤖 (@igorwojda) May 24, 2020

This is one of the reasons why even in a company with great culture and people, it can still be hard to hold to some talent. Regular and exciting work is crucial to keep people. If we can’t offer it on a regular basis to savvy engineers they will start looking for alternatives.

Having a high-quality and predictable codebase it’s great for productivity. Even for performance, no questions about that. There are a ton of benefits of such a codebase:

• More testable
• Easier to maintain and scale
• Less time spent grooming new tasks, everyone knows how to tackle most problems
• Easier adoption and navigation for junior engineers and new starters
• Increased productivy and throughput
• Fewer bugs and a better performing product
• And many more benefits…

But, and there’s always a but, what if it becomes too predictable? What if writing new features becomes a boring and repetitive task? That doesn’t sound exciting, and it can be a dangerous place to be.

A team can spend some exciting time coming up with a nice architecture and nice ways of working. But when that’s done, the day to day work can become repetitive very fast. While the journey to get there can be exciting, it has an end. Refactoring the rest of the codebase to use the new architecture can already be a daunting task. More senior engineers will soon be looking for the next exciting task/challenge.

With feature work, you can have some bursts of exciting challenges. If a new mobile/web feature requires a piece of custom UI or animations. If the backend team needs to integrate data from a few different services into one single stream of data. But if this is all you have, it might not be enough depending on the size of the team. You can’t have every engineer participating in such initiatives. Managing that exciting challenge rotation can be tricky on its own.

This can be a great time to check motivation levels on the team. If one or more people always jump in and volunteer to work on these tasks, that’s a sign you should not ignore.

In some companies, people can move between different teams/squads/tribes (so many names these days 😁). As a manager, you are responsible for your engineers' career development. And if they have a better opportunity on another team you should encourage and help them make that move. No one likes to lose people, but it’s better if they stay in the business than leaving. They might even come back on a future rotation.

This is why it’s important to allow teams to explore new technologies and frameworks. The code we write today is our new legacy. It might not need love tomorrow, next week, or even next month or year. But we will need to replace/tweak it at some point. Leaving teams space to refactor and explore it’s great to keep the product and the codebase in a good state. But it’s also a great way to keep your engineers engaged and motivated.

A team working at a consistent pace delivering value to your users it’s great for the business. But that doesn’t guarantee it’s 100% happy. Going back go Igor’s tweet. What makes it exciting for engineers is doing things that were never done before. If nothing else, we for sure like a challenge 🙂.

If you’re an Android Engineer, you should check Igor’s Android Showcase Project. On his words: “Showcase is a sample project that presents a modern, 2020 approach to Android application development with up to date tech-stack.”