Recorded – watch the full episode on YouTube.
Now you’re a senior developer for the New York Times, doing amazing work there. What would you say separates a senior developer from a junior developer?
Paola Mata: So I have a lot of thoughts on this actually. Obviously every company has their career ladder or maybe some don't, but at least they have some idea of what it takes to be a senior developer. When I was junior, I thought maybe it's just being really fast or just knowing how to do everything. And I've definitely changed my mind as I've grown as a developer and obviously working up toward the promotion and even since then.
But if I have to answer that question for somebody who's maybe trying to get there, then putting it simply it's being able to handle, let's say a project or a feature from start to finish. So that involves a lot.
“There's a lot of communications, there's planning, there's obviously the technical knowhow for how to approach a problem architecturally and otherwise. And also part of it's also breaking down the work.”
There's a lot of communications, there's planning, there's obviously the technical knowhow for how to approach a problem architecturally and otherwise. And also part of it's also breaking down the work. If you're managing a project, let's say, and you are working with other people, how do you break down that work to make it easier to tackle simultaneously. As opposed to being blocked. Just like seeing the project through.
And then there are other aspects to it, which are probably also around mentoring and working with other people, which I can speak more to. But I think those are the major things that I would at least qualify you to say, “hey, I should have a senior title at this point, if I can do these things.”
“I think the code is the fun part, but I enjoy the process even like contributing to what a feature's going to look like.”
Paul Hudson: I remember years ago I was delivering a lecture to a university full of want-to-be developers who were going to graduate in a year or so of time and hopefully get jobs doing that. And the lecturer specifically asked me to talk about how much time I spent coding. Because I think in their heads, the answer was eight hours a day. Sit down Xcode, open, outcome, Swift, eight hours, close it, go home kind of thing. And it really isn't like that, right?
Because all the things you mentioned only like one breaking things down was really specifically about the actual practical application of writing the code for this. Everything else, planning this stuff, building the bigger picture is not necessarily code related.
Paola Mata: Exactly. I think the code is the fun part, but I enjoy the process even like contributing to what a feature's going to look like. So when we're planning something, I'm the technical go-to person for a specific project. Even now we're planning on following up on a project that was launched last year that I worked on. I have my designer come to me and ask me like, “hey, is this feasible? Is this even possible? Or would this be more work versus that?” And just like that to keep in mind what actually the feature's going to be.
Paul Hudson: So when it comes to this day-to-day role of being a senior developer, what would you say are the fundamental skills of a senior developer?
Paola Mata: Well, there's definitely the technical knowhow, which I think is something you gain from experience, which I was thinking earlier. Somebody being like six months into this and getting a senior title, to me, doesn't make sense. Because I don't think enough time has passed to learn from your mistakes and see some of those play out. And maybe I was like, “oh, maybe I should've written this differently.” And learn from the mistakes of others as well. Learn from your team. So that definitely takes time and experience.
But I think communication is really important. Working well with others, knowing how to make trade offs between, "Should I make this a super complicated feature or should I..." Having a good sense of the product versus the code and having a good middle ground for what's important. How to write code that your team can understand and read and expand as needed. So I don't know if I'm answering the question.
So there's the technical part, the communication part, there's a lot like managing different aspects of a project, I would say.
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 In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.