07 Jan 2017
By Belle
Why mentoring didn't work for me
Last year I decided to look for an iOS mentor. I was frustrated at how slowly my programming skills were progressing, and how often I was running into specific problems in my work that I struggled to solve on my own.
I put out a call for anyone interested in mentoring me and was lucky enough to get a very kind offer from an experienced iOS developer in Melbourne. For a few weeks I spent about an hour a week in this developer's office asking questions and chatting about code.
I ultimately decided not to continue with this arrangement. While I was very grateful for the opportunity, it didn't turn out how I'd imagined, and I wasn't convinced it was worth my time or my mentor's.
I'm convinced this setup didn't work out mainly because I had the wrong idea about what mentoring would consist of, and perhaps because mentoring wasn't actually what I really needed at the time. Here are some of the main reasons I decided not to continue with it.
I didn't want code reviews
I think code reviews are great. I would love to have someone look over my work and help me improve it. Whenever Josh has done that for me I've seen my code become simpler, easier to maintain, and easier for me to understand.
But when I went looking for a mentor, I didn't want someone to do code reviews for me—at least not initially. With only one hour per week to spend with an iOS developer more experienced than me, I had to prioritise. I wanted help with specific problems I was stuck on. I wanted help in the areas where Stack Overflow and Google and the Apple docs had left me without any idea of what to do next.
What I tended to get, though, were discussions about different ways to do things I'd already implemented. Or suggestions about ways to improve the code I already had. Extremely valuable suggestions, advice, and ideas. Just not what I was after.
Now, it's possible that I wasn't clear enough about what I wanted in a mentor. It's also possible that this particular developer wasn't a great fit for my needs at the time.
It may even be possible that my code is so bad that nobody could help me with anything specific until I'd unravelled all the spaghetti and removed all the magic numbers and changed it in all the other ways a good code review would suggest.
I don't know what exactly the issue was here. I just know I didn't get what I was looking for.
I'm too easily influenced
Another problem with this setup was how easily influenced I am. After an hour-long visit with my mentor, I'd come home with days' worth of refactoring to do, thinking my mentor knew best and I should do everything he suggested.
While it's definitely good to take advice and suggestions from more experienced developers, it's also important to know your own roadmap and priorities. I tend to let all my own ideas or opinions get overshadowed by people who seem to know better than I do (in lots of areas, not just development), which isn't always healthy.
I'm not learning for fun
Once I released the first version of Exist for iOS to the App Store, my situation as a developer changed. I was no longer learning and making apps just for fun. I'm now in charge of a mobile app that serves more than half the mobile users of our main product. That app is directly linked to the majority of our revenue, and that revenue is what pays Josh a salary.
That's a lot of pressure. And it means my development work is now very serious, real work.
In terms of mentoring, this particular situation made things harder, I think, than if I'd been learning out of curiosity and making apps for fun.
I didn't have the luxury of spending several days refactoring my code every week after seeing my mentor because I had hundreds of users waiting for new features and bug fixes. I had paying users relying on me.
This meant I was more impatient for help with specific problems, and it was less practical for me to spend time reviewing my code. It's not ideal to be under so much pressure that you don't feel like you have time for code reviews and refactoring (though I'm sure it's common). But I only work part-time on Hello Code since it can't pay me right now, and I'm already slower than your average iOS developer, so time pressures are huge for me. In fact, wanting to code faster is one of the main reasons I looked for a mentor in the first place.
These time pressures also compounded the bad impact of me being so easily influenced. I wasn't in a position to be spending days refactoring every week, but I was easily convinced to do just that in every meeting with my mentor.
I felt bad
Mentoring someone is a wonderful thing to do, and you can learn a lot from it yourself. But it takes up your time, it doesn't pay, and it takes you away from your real work.
I consistently felt guilty for taking up my mentor's time, and that's not a nice way to feel on a weekly basis. Again, this could have been because I chose a mentor who wasn't the best fit for me and my needs at the time. Or it could have simply been something I needed more time to get over.
But combined with the other points listed above, this was enough for me to give up on the idea of mentoring.
I was moving even slower than I had without a mentor because I spent so much time refactoring my code instead of working on new features and bug fixes. I was taking two hours (including travel time) out of the little programming time I had available each week to have discussions about general ideas or different ways to do things I'd already implemented, rather than getting answers to the questions I had.
And on top of all that I felt like a huge burden.
I still think mentoring is great in general, and that it might work for me at some point, but I'm hesitant to try it again after this experience.
I'm hugely grateful to the developer who took his time out weekly to help me learn, and the company he worked for. It's a magnanimous thing to do, and I hope more developers will do it for other juniors who need help and have more realistic expectations about how mentoring can benefit them.