Transcript for Episode 193. Senior Engineering Superpowers
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Living large in New York. I’m your host, Michael Nunez. Our co-host today.
[0:00:08.3] DA: Dave Anderson.
[0:00:09.8] MN: Today, we’re asking, what is your senior engineer superpower?
[0:00:14.1] DA: Yeah, I wish it was lasers.
[0:00:19.3] MN: Yeah, just shooting lasers everywhere.
[0:00:20.5] DA: But it’s not, yeah.
[0:00:21.8] MN: No?
[0:00:22.4] DA: No.
[0:00:23.4] MN: We’re going to talk about different superpowers that a senior engineer have, we’ll try and dive through and see if we can find your superpower and share are there super abilities with the world, I guess.
[0:00:35.1] DA: Yeah, I feel like becoming a senior engineer is a slow process and you don’t really realize that it’s happening until you look back and you're like, “Oh, that was my origin story, that’s how I became a superhuman. It was that radioactive ooze that got onto my keyboard or in my coffee.” But, yeah, when did you become a senior engineer?
[0:01:01.0] MN: I was late one night at the client, and a radioactive spider bit me, that’s where it happened. No, I think, so, I was at a client for X amount of – for some months, and I was responsible for – I was in a few projects with the client and I think at some point, it was just like the turn of a new client like it was like a new – they ran an inception on a particular thing they wanted to build on the website and then when it was time for us to develop that feature, things just – I moved around differently, I managed it very well, was able to deliver the feature and I think the first thing that happened that made it and I think it just clicked and then – how do you say? Broke Kaioken as they would say in Dragon Ball Z or whatever.
[0:01:52.5] DA: Just straight backflip.
[0:01:53.9] MN: Yeah, straight backflip. I knew I was senior engineer, you know they had asked and estimated, “How long would this take, roughly? If we all had to kind of figure out the timing of this?” And my answer was, “It depends.” It depends! It depends! And I never knew that –
[0:02:14.4] DA: Not as a joke but like from the bottom of your heart, you’re like –
[0:02:19.0] MN: Yeah, exactly was just like, I knew it depended on things and that I knew what those things were to talk about whether they depended on it that was me. That was like –
[0:02:29.8] DA: Yeah.
[0:02:30.4] MN: I’ve heard that phrase used a lot and I was like, “Yeah, of course it depends.” Whatever, you asked me.
[0:02:36.5] DA: What a nonsense thing to say, that’s like yeah, have you put no thought into this? Yeah, that makes sense. If you say it and you mean it and you can back it up, that’s a different thing because you can quantify the uncertainties, you can list them out and know what the different kinds of things that might bite you in the butt—besides the radioactive spider that gave you your super senior engineer superpowers.
[0:03:02.3] MN: Exactly.
[0:03:04.2] DA: Know what the trade-offs are also, you know, we can do a little bit of this and you can do a little bit of this, or you can go middle…
[0:03:12.1] MN: Exactly. Yeah, then like you know, different from identifying the things that you know and you don’t know, right? You have enough experience to have been in the field for x amount of time, where you now know the things that you may not know and you have to put that into consideration for the project that you have to build so…It depends! That’s why I’ve given that one to everyone, that’s a happy birthday.
You can use that in all your meetings, it depends but you have to mean it, it has to come from the heart.
[0:03:45.9] DA: Right, I mean, it’s balanced with experience, you know? Fine level of experience.
[0:03:51.9] MN: Right.
[0:03:53.5] DA: Yeah, for me, I think I had been on a couple of different disparate clients, bouncing around on different projects very quickly, and I finally landed on a new project, new code base, new people, and it didn’t feel overwhelming to get started. I was just in the middle of the soup, completely uncertain, not knowing anything, but I felt like I knew who to ask what questions, and I knew what kinds of things would help.
[0:04:32.4] MN: Right. Just being able to navigate those waters, right? You know to kind of look at the
git blame and see if that person’s still around to ask any questions.
[0:04:45.1] DA: Yeah, and knowing also, how to ask it, like diplomatically and build soft relationships, like making friends and getting to know people on a deeper level so that you can appreciate the context of the place and you know, have fun doing work. And also, knowing, even though you don’t know certain things, that you can still lift people up around you. You can contribute what you do know or what experience you have to guide people in the right direction. Even if you're kind of taking a backseat to them being the main star of the show.
[0:05:29.2] MN: Right. That comes when you are constantly entering different teams and different code bases. I don’t know if that ability, the more experience you have doing that, the better you get at joining teams and reading different code bases.
You develop that skill, that ability to navigate the waters as I feel like when I hear that is just like knowing, you may have some rough terrain coming up and you need to know the tools necessary to move upward and onward with a new team, there’s a new relationship you would have to build all sorts of stuff like that. That doesn’t come easy, that takes some time.
[0:06:10.5] DA: Yeah, I think another thing that kind of helps or can be like an engineering superpower is just being very earnestly curious about the things that are around you and trying to understand how they came to be as they are.
Kind of taking apart, understanding what kind of trade-offs were made for time or for whatever reasons, and appreciating how things came to be and not just being like, “Oh, what a pile of junk this certain person wrote” or you know, maybe even yourself a couple of months ago, as it goes.
[0:06:49.7] MN: Right, the worst thing you can do is like, read a piece of code and say, “Oh, man, what is this?” And then you check that
git blame, and it’s you. That doesn’t work too well. What you mentioned like you know, being curious about how something was designed with no judgment behind that, right? With experience, you get humbled from that, from your experience to know that you could just read things, kind of understand what’s happening here, and then continue on with whatever you are trying to figure out in your curiosity.
[0:07:27.7] DA: Right, and there are different patterns that you can apply for success. You can look at something and generally see, “Okay, if I apply a design pattern here, maybe it will make it easier in this way or that way.” Kind of – like being able to separate that like, “Okay, when that can come in” or would it be – it may have ben like okay, they could have done that but they didn’t have time or there were some other tradeoff that led them to a different solution. And there are many solutions, so –
[0:08:07.0] MN: Yeah, I think it’s like, reminds me of the retrospective prime directive. Once that resonates with you when you are reviewing code or being curious about something, that’s when you are at peace with the thing that you're reading and then kind of being able to use what’s in front of you and make things better.
For those who don’t remember, because I can’t really do it off the top of my head, I opened the tab, I’m just going to read it anyway. You ready, Dave?
[0:08:38.9] DA: Okay.
[0:08:39.2] MN: Cool. “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
[0:08:55.7] DA: So help me God.
[0:08:58.0] MN: So help me God. That quote has much more meaning when you are curious and you’re looking at things, and then, you know, you quench the thirst of curiosity, and you continue on.
[0:09:07.7] DA: Right, and you have also like some measure of experience of doing the wrong thing or the stupid thing in order to get something that you knew, like, “I know that this is not great but I’ll do it” or if you didn’t know it, it wouldn’t be great and you found out.
[0:09:27.6] MN: Yup. When, after the spider bite and I’ve realized my full potential as a senior engineer—
[0:09:36.6] DA: You got your cape.
[0:09:38.1] MN: Yeah, I got the cape on, I got the onesie and it’s stitched well, right? It’s not like, the old materials I use, brand new materials as I’m fighting crime in the programming world. The one thing that I learned, and I think this is a combination of—this is something that I learned when I was not a senior engineer and then I learned what not to do when I became one—and it’s like lifting up my team members.
I think that’s something that I try to do every day with my team. Ensure that they’re in power and they have the autonomy to build whatever feature’s in front of them with the information that they need to continue moving forward.
I don’t really have anything to prove at that point, so I don’t have to take the hardest ticket, right, to get to this end of the sprint. I feel like that just kind of robs the experience away from other individuals who are trying to find their superpower.
[0:10:35.6] DA: Yeah, that’s definitely pretty true. You’ve already kind of tested your mettle, and you feel confident enough to step back and create a space for other people to succeed, and you know where you can help lift them up and where you can – maybe they could lift you up or give them a chance to, you know, practice some other kind of muscles.
[0:11:03.1] MN: Right and it doesn’t help you know, I think I could use the example of practicing the muscles. I don’t go to the gym, ladies and gentleman, so I'm going to try my best here, but like if I constantly starve an individual from not working out, then they’re never going to get strong, right? You have to give people the challenging problems so that they can work out that program or algorithm –
[0:11:28.1] DA: I mean, what you do know, though, is you do know shoveling the walk.
[0:11:31.9] MN: Yeah.
[0:11:33.1] DA: If you don’t let Annie shovel the walk, she’ll never get strong.
[0:11:37.7] MN: No, like she is shoveling –
[0:11:39.6] DA: You know, you got to let Gio shovel the walk so he can level up.
[0:11:43.3] MN: I mean there’s a task for Gio but I don’t think it’s shoveling snow right now. I am looking forward to the data he does and then I got to – I actually have two shovels, and that is like, one is mine and one is for Gio when he grows up and I think that is another thing too is, funny you brought it up, is also identifying whether the task is too strong, is too much for a person.
[0:12:07.1] DA: Okay, I’m not there yet. I thought Gio could do it. I thought you have the course today.
[0:12:11.2] MN: No, he was good enough today to walk down the street. The path that I built for him that’s what he did but he can’t shovel snow but the ability to, I mean it’s not only like, you’re delegating tasks and you are giving it to other individuals, or more like knowing that a person is capable of this challenge and then giving them that problem, I think also is as a signal that you are a senior engineer who is caring about their team and wanting them to grow.
You got to look at the task and don’t give a two-year-old a shovel and then expect them to make a path, that’s okay.
[0:12:50.6] DA: Yeah, I think another thing that is a senior engineering superpower is what we are talking before, having experience and kind of letting that guide you, and when you hit some kind of a problem, experience gives you an intuition to the right Google-fu or debugging. Like, you know what the right problem or question is in that situation, and it ain't no thing, like even if you don’t know what it is, you can just – it’s like water just rolling over you.
[0:13:23.8] MN: Yeah, definitely that Google foo steps up and you know exactly what to search. You find out one post that answers the question and it is the only one that exists on the Internet. Classic, oh man, that feels so good. I don’t understand how I was, like, and that, I felt like some things in the topics that we mentioned are like, you know, you can know from the top of your mind like bam, you know this thing but like the Google-fu was gradual, and then it just became like the skill in itself.
[0:13:56.1] DA: Yeah, I think a correlate of this is also besides looking outside of the code base into the world and into the people around you and Google and Stack Overflow, there’s also kind of having, being able to develop like a map of where things are in the code. Hopefully your code is organized in a way, or you can enforce some kind of structure on the code, that lets you intuit where something might be. I mean, I’ve had times when I just felt like on fire because I didn’t know something would exist but I just was like, “It’s going to be here,” and then it was there, and I just used it and I was like, “That’s great.”
[0:14:41.3] MN: You just know.
[0:14:42.9] DA: I mean, I guess that also speaks to volumes to the people who came before me, as well. Obviously, there is some kind of logical shape to what they have done, but you know, to have that kind of spider sense is pretty helpful.
[0:14:57.7] MN: Yeah, it definitely has helped – and then as you mentioned, either whether it is Google-fu or you know the framework, the language that you’re working with, the methods that exist, that will help you and your team build better software.
[0:15:12.9] DA: Have you ever had to help somebody plan a project?
[0:15:19.2] MN: Yes, I had to plan a project before, and I definitely know that this is not something – this is something that I knew I could do, because I was a senior engineer. And I don’t think that I would have been able to do that without that, knowing that. You know, a brand new project, and it was a brand new skill in general. It’s like, using AWS serverless. It was like, “All right, we need a project that the user is the serverless, right?” Because that is the future. AWS is the future. I was like, “What?”
[0:15:48.3] DA: What I’ve heard, yeah.
[0:15:49.6] MN: Yeah, it was –
[0:15:50.0] DA: Don’t need roads.
[0:15:50.8] MN: Nope, none of that because everything is serverless. Where are the servers? We don’t know. We got an episode on that and I had no idea what to do for that but I know I had to learn the skills necessary to make deployments for a serverless framework and using the API gateway and all sorts of stuff, and just planning, and talking about the things. The potential roadblocks that we may have, and being able to look months into the future of the problems that we have in our planning, was because I was able to have experience in previous plans that I was a part of, and that kind of stuff.
[0:16:28.0] DA: Right, and so you know what kind of things have gone wrong when you tried to plan something before, so you kind of have like a contingency in your back pocket or you can include that in your planning fudge factor and whatnot.
[0:16:45.7] MN: Right, like, you know, whenever possible don’t try to find the simplest answer; don’t try to hand-roll things that already exist; even if you don’t like 10% of it, don’t throw 90% of it away, you know? You figure out the things that you need to build the plan forward, and then, you know, assess whether this is achievable, whether it isn’t, and I think we mentioned before, the more you know, the more you know of the things you don’t know, and then you get to assess how long it would take for you to take the things that you don’t know and then know them. But that, to me, I felt like that was something I knew as a senior engineer.
[0:17:25.7] DA: I mean, yeah, when you put it like that, it sounds so easy. Just know the things you don’t know. Yeah, sure, just be a senior engineer.
[0:17:32.0] MN: I mean, you do that and know. Yeah, by knowing more, you know that there is more things you don’t know, to have to know those things, so that you know more than you know that don’t but you never not know the things you don’t know.
[0:17:41.7] DA: That’s true, don’t fight it everyone.
[0:17:47.3] MN: The last one for me, this is I guess a little personal, but I would say mentorship is a sign of a senior engineer, to me I feel and it’s not because I am doing it even though I am doing it right now. I work in an organization that helps individuals learn to code. And being able to explain concepts to someone who has never picked up or have never done programming before.
Dave, I want you to do me a favor really quick—and people who are listening. I want you to close your eyes and then remember a time where a string data structure was foreign to you. Do you remember that? I don’t.
[0:18:26.4] DA: Yeah, Visual Basic. I’m there.
[0:18:29.5] MN: It feels like so far. I feel so far, long ago to explain what a string is and what is it used for and being able to explain that in a way that someone grasps the concept, to me I feel like that is a sign because you are able to be patient. You are able to explain things, understand the thing that you are trying to explain for them to pick it up and continue their path to learning.
[0:18:54.8] DA: Yeah, and I guess there is also a lot of different levels of that, too, because you can mentor someone who doesn’t know what a string is, but then you can take that also to coaching somebody who may know more than you and is more talented, but you can kind of help them see the forest for the trees or whatever else you are trying to work on.
[0:19:17.5] MN: Right, and, I mean, I use the example of learning from scratch, because that is what I am currently doing right now, but mentorship is a wide range of things like you mentioned Dave. Someone learning what
bigint is and
integer and that stuff versus, you know, this person wants to learn React best practices and you being able to mentor that person, too, about those things.
[0:19:42.9] DA: Yeah, it’s important, so important. I think we learned a lot. Definitely be on the lookout for spiders and goo on your keyboard. Keep keyboards clean, and no spiders—or maybe we want the goo in the keyboard, I don’t know.
[0:20:02.0] MN: If there was something else that gave you your superpower to become a senior engineer, I would love to hear it. I am curious what other crazy that you – that someone change your keyboard to Dvorak and then you had to force yourself to learn it and then that’s how you became a senior engineer.
[0:20:19.1] DA: Oh, that sounds like a nightmare.
[0:20:20.2] MN: No, but imagine you became a senior engineer, you have to fight your way through Dvorak key bindings and learning it, or you did Emacs, like, you know, it wasn’t that that did it to you. Was it –
[0:20:30.4] DA: Or maybe you fell down one day and you could only type in Dvorak like that’s cool.
[0:20:36.2] MN: Man, that’s crazy yeah.
[0:20:37.2] DA: It’s like you don’t know QWERTY anymore but I can type 200 words a minute.
[0:20:40.4] MN: Right, and however you got your superpower, I love to hear it, and I am curious at what point in time was it for you because that is just between the both of us, and we got a ton more. We’ll be here forever, but I’ll be all ears.
[END OF DISCUSSION]
[0:20:55.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode; subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries, and my amazing co-host, Dave Anderson, and me, your host, Michael Nuñez, thanks for listening to The Rabbit Hole.
Links and Resources:
Our seasoned cross-functional agilists work with you to develop technology, ship product and deliver value. We leverage our diverse expertise across industries and throughout the organizational growth cycle to your benefit. We bring best practices, emergent practices and creative solutions to your problems.