I’ve been guilty of boxing myself, calling myself a Java developer. A backend developer.
Courtesy of this article on unconscious pigeonholing
Microservices and Java are what I know, but I didn’t realise quite how harmful this could be, to your own mentality towards your career if nothing else. It suggests rigidity, a lack of motivation to learn or become more than I am. And I’m more than a Java developer.
Our team has been working with Kanban for more than a year now. At first, it was really tough. We’re a team of two backend developers, two Android developers and two iOS developers. I realise at this point I’m doing the same thing as before and boxing my team members to a specific role, but these are their main focuses. I’m one of the backend developers. We’re a Multi-Platform team organised with the aim that we would find it easier and quicker to work through features together. This way the APIs that the apps will be using are being implemented alongside the front end work. There are many reasons why this is a good team structure for us, but that’s another story.
Our features appear in the form of epics, and we break them down into stories, then tasks that are targeted to the individual platforms. Then we get to work. The issue is that often the backend work is less time consuming — the apps need to be able to have a beautiful front end, a functional rest client, and all the logic and processing in between. It often means that the backend tasks get done and our “Ready” column is left full of app tasks. This was incredibly frustrating. After a short time of fighting the system, I realised I was only damaging myself and my opportunities; a chance had been given to me to spread my wings and gain new valuable experience.
The next time I picked up a task, I chose one of the Android ones. It was uncomfortable at first; I didn’t recognise the tools or know the codebase inside out like I do for the backend project. But it was Java, and injection libraries like Dagger aren’t dissimilar to Spring.
I could work with this. Some help was needed at first, each time stumbling on something new. But I got there and now, 5 months later, I’m working autonomously on all sorts of Android work alongside my backend tasks.
It’s been a wonderful learning experience, and it’s made me feel so much more confident in my abilities. Not only have I broadened my coding skills and knowledge of different tools, but it’s been priceless to also get that experience of working with the client that’s actually a consumer of your API. Working with the databases, through to the microservices, and all the way to the front end offers you a new perspective and understanding that you can’t afford to turn down. It opens up your world view of the entire ecosystem of a product.
Ah, yes, the UI aspect — turns out I quite like working on the front end! Whilst coding generally is an art, this definitely appealed to my creative side. It also meant that I learned about the different challenges they face such as making sure that they keep the code clean and maintainable, satisfy the requirements from the UX team, and all the while ensuring they adhere to the Material Design guidelines. This was the biggest jump for me, and I found it fascinating (if a little troublesome at first; I was always asking “but why?”) to learn about the way that little things like shadows can be used to infer functionality and assist the user in their journey through the app.
In addition to the personal gain from this change, it also means that my team has benefited from having essentially a third Android focused developer, capable of offering new ideas, significant input on code reviews, and contributions towards the Android development of our features.
Choosing to begin my transition with an application that was written in the same language I worked with was a soft introduction that has encouraged me to explore further. Like my little personal projects during mastery days, writing a small Android app in Kotlin. Or my latest and greatest challenge to date… my decision to try and work now with the iOS codebase. Swift and Objective C are completely alien to me, but I feel more confident in my ability to pick up new tricks of the trade and get stuck in. Again, I forge forward into the unknown with the familiar uncomfortable trickle of fear on my spine; will I be able to do this? But don’t let that voice stop you. I have faith that the answer is yes, with a little help at first from my colleagues whose support is always so graciously given, so I assign the task to myself and look forward to creating that new UI screen.
Get stuck in!
