Boost your development skills by teaching and learning with your teammates.
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.
🥺 That crash… that damn crash
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.
Tests + TDD = 💛
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:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail, and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
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.
Benefits of TDD
From my personal experience with this methodology, the benefits I can list are the following:
- Less cognitive overhead
- Faster development on mobile: I barely need to open my emulator when I write tests for my presentation logic. I trust them and once I finish the feature, I’ll run the app. No more need to open the emulator just to test my presentation logic.
- Continuous Refactoring
- Boosted my Leadership, Mentoring/Teaching, and Product Ownership soft skills.
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.
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.
private val repository: TodosRepository
They created this blank ViewModel class but decided to start writing the tests instead with the following schema:
- Katarina: write the first test
- Vlad: make it fail
- Katarina: make it pass
- Vlad: make it better
- Vlad: write the second test
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.
// Todo(id: Long, name: String)
private val fakeRepository = FakeRepository()
private val viewModel = TodosViewModel(repository = FakeRepository())
// Katarina's turn
@Test fun `should return a list of todos`()
val expected = listOf(
Todo(id = 1, name = "First"),
Todo(id = 2, name = "Second")
viewModel.todos.test().lastValue(), // TestObserver
"Todos does not match"
// interface TodosRepository
class TodosViewModel(private val repository: TodosRepository)
// Vlad's turn
// + val todos: Observable<List<Todo>> = Observable.empty()
// Katarina's turn
// + val todos: Observable<List<Todo>> = Observable.just(
// + listOf(Todo(id = 1, name = "First"), Todo(id = 2, name = "Second"))
// + )
// Vlad's turn
val todos: Observable<List<Todo>> = repository.fetchAll() // ...
// repeat with Vlad writing test now
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.
- Ping-pong programming improves the relationship between peers.
- Learn new technologies with your 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:
- General purpose: Around or Pop.
- Code with Me from Jetbrains: Kotlin, Android or any language that IntelliJ IDEA supports.
- Live Share @ VS Code.
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. 🦅