Recorded – watch the full episode on YouTube.
What does it take to be a senior developer? Do you feel like a senior developer?
Sean Allen: If you ask somebody what a senior developer is, you ask 10 people, you're going to get 10 different answers. So I agree with you.
I guess I don't consider myself junior, but as far as mid-level, senior, it's all such a blur to me, like I don't, I don't know or care, to be honest with you. But so yeah, what is a senior developer? I don't know. It's very hard to answer. And it doesn't sound like you're worried about that. If you've been doing this 20 years, you're not worried about it.
But I do know there are junior developers or mid level developers that care a lot about it. And I'm not sure why. Maybe it's because of a title that you can get at a company for a certain level of pay. I don't know. But I just think a lot of people put a lot thought, effort, and stress into whether they're a mid level or a senior, I just think it's irrelevant.
“A junior developer, I would expect, would be someone I would sit down with and say, okay, your task today is to this screen here, here's the design, and then ask them how they think they might solve it, and then bounce ideas back with them for a while.”
Paul Hudson: I can understand it. Folks want to see the word “junior” erased from their title. They don't want it on there – of course they don't.
Sean Allen: I get the junior thing, it's the whole mid-level, senior, and then like I don't even know the details of this, right, but once you get into big companies, there's like L2, L3, there's like a whole system of like that, I don't know.
Paul Hudson: But that makes sense, because if you think about it, you'll see some people who are 24 years old, and are senior developers. Okay, you're senior now, what are you in 40 years time when you're still working? You retire at 65 or so, in your 50s, 60s, what are you then? Senior senior senior senior? Well, no. You got to break it down more than that.
“An intermediate developer, a mid-level role is someone who won't have to do that, but is still tackling regular kinds of problems. They'll do it on their own. And a senior, for me, is the kind of person who'll have half an eye on the code, but half an eye on other business concerns.”
Certainly in my head, I divide it, not into what code you necessarily can write, but what kind of problems you're tackling. A junior developer, I would expect, would be someone I would sit down with and say, okay, your task today is to this screen here, here's the design, and then ask them how they think they might solve it, and then bounce ideas back with them for a while. And then say, well this might be this, what about this, just to help them work through the problem and come to their own conclusions about the best way to solve it, which is of course hopefully the best way to solve it. But finding it their own way.
An intermediate developer is someone who won't have to do that, but is still tackling regular kinds of problems. They'll do it on their own. And a senior, for me, is the kind of person who'll have half an eye on the code, but half an eye on other business concerns. What are the commercials behind this, how can I take the team forward, how can I mentor other people, how can I organize training? You know? And that kind of thing, deadlines, I wouldn't want to inflict on a junior developer, they are, in my eyes, certainly I was when I was a junior developer, a code monkey. Sit down, write the code you're given, do these tasks.
As you progress, you get more responsibility, more understanding, more awareness, more responsibility, more trust in the team to take on bigger tasks. But you're still writing code if you're an intermediate or a junior, and even senior, you're still writing the same sorts of code, but the responsibility behind it is what evolves over time.
Paul Hudson: Do you think iOS developers need to know all the Git commands or can you use a GUI tool?
Sean Allen: I use the GitHub GUI, and here's why. 98% of the time, you're doing git pull/git push. I mean, and the GUI, for me, is way faster to do just that. So it's very, very rare that I have to do any rebasing or whatever, that I'll just probably end up having to follow a tutorial, and then I'll bust out the command line.
But for my day to day work, because it's basically, “okay, git pull, git push, done.” Then yeah, I use a GUI. So I guess to answer the question is, do you have to know the commands? I don't think so, because I don't. And I guess if you take good caution in not having to completely revert back to specific commit, or the whole Rebase, yeah, you'll probably save yourself some time.
“I guess to answer the question is, do you have to know the commands? I don't think so, because I don't. And I guess if you take good caution in not having to completely revert back to a specific commit, or the whole rebase, yeah, you'll probably save yourself some time.”
Paul Hudson: Yes. I have a real problem with Git. I mean, my brain is not wired well in this respect: I can only use the command line. You know, Tower, would say, “hey Paul, we love your stuff, have a free Tower license." I'd be like, "Thank you very much." And I’d launch it and go, “whew, I don't get this tool. This is way above my pay grade, I don't understand at all.”
But if I go to the command line, you know, – git branch, git check out, git tag, I can do all that from the command line. I just really, really struggle translating that into a GUI. I am quite set in my ways. I'm only 40 years old, Sean, and I'm set in my ways! I'm never changing from this ever again.
“But what I like about the GUI, too, is like when I have my commit, it shows all the files changes, and I can just click from file to file to file, and see those changes. And if I want to discard all changes on just that file, I can just right click discard changes, rather than navigating to it on the command line, and deleting it from there.”
Sean Allen: It's a funny story, that how you can be influenced early. Because I learned on the command line; I was a command line person from the start. Then at my first job, they all used the GitHub GUI. And I fought it and fought it, for like months. And then finally was like, alright, I'll give it a try. Haven't looked back since. So it's interesting.
But what I like about the GUI, too, is like when I have my commit, it shows all the files changes, and I can just click from file to file to file, and see those changes. And if I want to discard all changes on just that file, I can just right-click to discard changes, rather than navigating to it on the command line, and deleting it from there. I'm sure once you get good at it, it's fast, but I find the GUI to just be really, really fast and easy for the day to day needs. You know? When you feel like doing anything tricky, it's probably not great, but again, 98% of the time, it's great.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED Spend less time managing in-app purchase infrastructure so you can focus on building your app. RevenueCat gives everything you need to easily implement, manage, and analyze in-app purchases and subscriptions without managing servers or writing backend code.
Link copied to your pasteboard.