How to move up from being a junior developer in iOS

Recorded March 28th 2020 – watch the full episode on YouTube.

What are your recommendations for breaking out of the junior title? How do you get moved forward and prove your Swift skills?

John Sundell: This is something that I definitely struggled with myself a few years ago, where I was seen as a junior developer by people around me, but I kind of started seeing myself more as a senior developer, and that was kind of an awkward situation, to be honest. I felt like I had more experience than what other people might have seen that I had, or they were giving me tasks that I felt I wanted something more. I wanted something more advanced.

"So if you want to be seen as a more senior developer and if you want to level up and get that title in your company, whatever different titles you might have, act as if you already have that job."

I wanted to work more with more senior-type tasks, like architecture, like making decisions around the structure of the code and things like that, not just do the bug fixing and the UI development tasks and things like that. I basically wanted to be seen as someone who was a more senior, who had more expertise, and that was really difficult, but one thing and one piece of advice I got back then, and I will kind of pass that on here as well, is that act like the person that you want to be seen as.

So if you want to be seen as a more senior developer and if you want to level up and get that title in your company, whatever different titles you might have, act as if you already have that job. Ask to be part of those meetings, those conversations.

Get a mentor, someone who can help you reach there, like someone who is already a senior developer, who can tell you bluntly, ask them for their candid feedback and say, “Tell me when I'm acting as a junior developer or when I'm not acting as senior enough. Tell me about it, because I want to know.” Get a partner or multiple partners, people who can help you out to reach that goal, and then really start imagining yourself in the shoes of that developer and really try to push yourself towards that, because I feel like that's really like the only way to get there.

“Get a mentor, someone who can help you reach there, like someone who is already a senior developer.”

And that was the only way for me, and once I personally started doing that, a lot of these people that I mentioned, these mentors and these people around me, my managers and different people who I was looking up to and who helped me out, they were pointing out things that, in retrospect, they were definitely junior behaviors.

One of those things that I really had to overcome was that I used to be very, very kind of strongly opinionated, and I used to always want to argue for one or some specific things, and one thing I realized that in order to be seen as a more senior person and in order to level up and really have a more senior mindset, I needed to stop worrying so much about always being right or always getting my way, and be more pragmatic and to look at a bigger picture more, and to look at things more practically, and to get other people's opinion, and to invite other people into the conversation rather than just listening to the sound of my own voice.

“Feedback can be incredibly painful sometimes, and there's a lot of different misconceptions, I think, about what feedback really is.”

So that was incredibly valuable feedback for me, because without that feedback and without that kind of wake up call, I probably would still be stuck as a junior developer because I would have kept repeating those mistakes over and over again. So I think that's really crucial.

Again, it comes down to feedback. Feedback can be incredibly painful sometimes, and there's a lot of different misconceptions, I think, about what feedback really is. It's not just someone telling you this is bad or this is good. That's not really feedback. It's about trying to help and guide you to changing your behavior, to improving yourself, and that's really, really, for me, the most important vehicle to advancing your career.

Paul Hudson: Feedback has to be actionable. You have to be able to do something with this feedback, otherwise it's a critique. You had a go at me. Taking pot shots at my code isn't helpful. Here is where I think the problem area is. Here are things you could try to fix that. Here's where I think you should go next. Actually actionable things you can take away and apply.

“You're going to have to learn new skills. You're going to have to maybe change the way you approach certain things, leave certain strong opinions at home when you go to work.”

John Sundell: Exactly. That's really what it is, and the person who's giving you the feedback should be having your best interest at heart. It should be someone who you know has your best interest in mind and who's going to help you reach that, whether or not, it's probably going to hurt a little bit because you're going to have to change some behaviors. You're going to have to learn new skills. You're going to have to maybe change the way you approach certain things, leave certain strong opinions at home when you go to work, but for me, I'm incredibly happy that I learned those skills and that I changed that behavior, because I just feel like I enjoy my work so much more now as well.

I sometimes see a lot of teams who are stuck in endless debates around code style, for example, and I really care about code style. I really do. I think it's important to have something that's consistent and easy to read, but at the same time, is it the most important thing in the world? No, not quite. Is it something that I want to argue over and over again? No, not really. If I'm going to work with someone or with a project that has a different code style than I'm used to or than I like, I'm perfectly fine with that. I'm not going to completely change it or write the code in my style just because that's what I like, and there's things like that, that I'm very happy that I've been able to change that behavior to be more adaptive.

Paul Hudson: I think ultimately as long as you're able to work with a style guide, it doesn't have to be your style guide. It's their style guide, but it's consistently applied throughout their code, hopefully using something like SwiftLint or something similar, it makes a big difference, because then your code reviews don't become, "You've put a line break here. There's too many tabs here." Those are important, but we don't want to discuss those. We want to discuss bigger things like, “Will this scale for performance? Will this be easy to maintain? Are there better ways of doing this?” Not tabs, spaces, or similar.

John Sundell: Exactly, and this is a little bit off topic, but one thing I really love, for example, now in GitHub is that you can also edit a file directly, and that kind of ties back to that behavior, is that are you going to pick a fight over something? Or if it's really important to you, if you see something that you feel is inconsistent with the code style, are you going to pick a fight over it or are you going to send that back to someone who needs to go and change their context and fix it again? Or are you just going to hit the edit button, change that yourself, it's going to take you 10 seconds, and then it's done? It comes down to like using the tools that are at your disposal and trying to apply the highest level of pragmatism that you can, I think.

Sponsor Hacking with Swift and reach the world's largest Swift community!