When I started my professional career as a developer, I used to like being a solo-player developer. Since I’m self-taught and I had to learn programming alone and by myself for years it was fine.
A few years later I learned that you can boost your career when you play for your team.
In my first experience as an Android developer, I just wanted to write code and ship apps. It was great, I managed to ship my first app from scratch in a company I worked for but suddenly we started getting crashes.
I was desperate. First app. First crash. Then I continued shipping fixes and new features and also started getting new crashes. This is fine, this will happen with any app, that’s the kinda experience every mobile developer will face.
I was alone and I had to figure out how to prevent such problems for my future creations: I learned about Testing.
When I tried to test my code on this company they refused because “writing tests takes so much time”. They said it 4 years ago but I’m pretty sure today there are still some developers that think the same. Let me try to change your mind.
My first experiences with writing tests resulted in: “ it’s so boring” 😑.
You write that complex feature with networking, caching, presentation layer, and so on. And then you remember you need to write tests and this is really boring and everyone would feel lazy to do so, right?
At least I can speak for myself… this is exactly how I feel and there is nothing wrong with that. Tests are boring until they are not: let me introduce to you Test-driven Programming or TDD. ✨
When you read these words you may think this is such a complex technique but it doesn’t need to be, we can just start simple with it.
TDD was the key for me to start loving tests and it is also the reason I’m writing this article here. I don’t want to go too far on it but there are 3 fundamental laws for this methodology:
It may seem complicated at first but we can simplify: write a failing test > make it pass > make it better > repeat.
As you probably already know, I wasn’t really a fan of writing tests but since I started doing TDD I love doing that.
The fact is that whenever you need to write tests after your implementation has already been written you’ll probably tie your tests to your implementation just to make them pass, and this is wrong since your tests should never depend on implementation details because they will likely change.
The scenario above is error-prone and also boring. When you start writing tests first, you have less cognitive overhead because you know exactly what you need to do to make them pass.
From my personal experience with this methodology, the benefits I can list are the following:
You may have started to wonder why a development methodology has helped me to improve some of my soft skills?
Basically I combined TDD with another technique that my manager at Perry Street Software introduced to me: Ping-pong Programming.
This new technique was such a success for me and for my manager because both of us could learn and teach each other. This technique encourages you to pair on your daily work and also leverages TDD.
Ping-Pong Programming (aka. Ping-Pong Pair Programming) is a type of Pair Programming that practices TDD (Test Driven Development). In other words, it is a combination of Pair Programming and TDD.
I was able to boost my career soft skills because these techniques encouraged me to teach my manager new skills and learn new things from them. They have more than 10 years of experience and having the chance to learn from them was the steroid my career needed.
The rest of the teammates also have lots of experience in different subjects so why not share knowledge with them as well?
Let’s say we have two developers called Vlad and Katarina who both write code in Kotlin and they started to work on a feature to show a list of TODOs in the app. They already have the infrastructure layer created and the only thing left is the presentation layer. They decided to start building their ViewModel.
They created this blank ViewModel class but decided to start writing the tests instead with the following schema:
Basically there are turns we need to respect in order to have a good experience for both devs. Using this technique you don’t rely on a driver and co-driver anymore, both are drivers and both will write the code.
What I really love about this is that both developers will drive and both can easily share their thoughts and opinion about what they are doing. This is exactly what I needed to evolve in many aspects of my career.
Once I had this eye-opening experience I also started to advocate for it so others can also see the benefits of doing so with their teammates.
This technique I showed above can be easily applied in loco, but since the world has gone remote (at Perry Street Software we ❤️ remote) it is also important to know that this can also be done by using some available tools such as:
Previously we were using Pop for screen mirroring, but it was a painful experience as we would need to switch screens during turns. Now we are trying out Code with Me from Jetbrains.
Code With Me is a new collaborative coding and pair programming service. It makes it possible for you to invite others into your IDE project, and work on it together in real time.
No need to share screens anymore, just invite others to join the IDE and they can start writing code on their own machine. Available for both Android Studio and Intellij IDEA. We also started to try Around for pairing sessions because we use this tool in our daily work for live communication.
I hope somehow this article will help you find an alternative to improve your career in both hard and soft skills. This helped me a lot and learning these techniques above turned out to be a game-changer for my career.
I’m pretty sure it’ll also do the same for you as the cost to start doing it is $0 and all you need is a bit of patience. Knowledge is free so let it flow and share it with others. 🦅
If you’re a mobile or server developer who enjoys architecture and is interested in working for a values-first app company serving the LGBTQ+ community, talk to us! Visit https://www.scruff.com/careers for info about jobs at Perry Street Software
Lucas Cavalcante is a developer for Perry Street Software, publishers of the LGBTQ+ dating apps SCRUFF and Jack’d, with more than 30M members worldwide.
Software Engineer @ Perry Street Software.
Love podcasts or audiobooks? Learn on the go with our new app.
Berlin Tech Blog (by eBay Kleinanzeigen and mobile.de)
Malik Al Ichsan
Software Engineer @ Perry Street Software.
Text to speech
Development on steroids: Ping-pong Programming and TDD – Medium