Soft Skills Engineering - Episode 293: Moving TOO fast and following my manager

Episode Date: February 28, 2022

In this episode, Dave and Jamison answer these questions: Is it possible to move too fast and do you believe in too much enthusiasm? I am one of the youngest member of the team and am always willing to start new projects and balance a few different things. Is there a point where this can start hurting my career? I’ve gotten bumped in compensation fairly, almost 25% raise since I first started. My career goal is to stay on the programming side but want to become a possible trainer for newer engineers/devs. Listener Michael asks, I’m a backend engineer in an engineering/coding role with a small bit of SRE type work. I love the work as I get to dig deep into tech we use and have become subject a matter expert on databases within the company. I really like my team and my manager in particular, and get to learn a lot every week. My manager is leaving my team to lead a new team within the company that is focused on the company’s SaaS offering and I’ve been given the option of joining this new team if I wish. I like their managerial style and how they have helped me with my career progression so far. However, I’d be doing Site Reliability Engineering (SRE) work. I’m not sure if I’m ready yet to commit to being an SRE and code less/focus more on ensuring the reliability of mission critical production systems. I don’t know how easy it would be to switch back to more of a coding role in a years time or if it would pigeonhole me into that type of role. Have you got any advice?

it takes more than using git stash to store temporary changes and never unstashing them to be a great engineer this is soft skills engineering episode 293 i'm your host dave smith i'm your host jamison dance soft skills engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into being a developer unlike git and stashing you should just alias git trash to git stash yeah it's probably like a hundred to one the number of times i've added to the stash versus pulled out of the stash you should see you should do like a histogram of git stash pop versus git stash drop and i think you'd find interesting numbers yeah well i wouldn't

because i didn't know about get stash drop until right now isn't that the right command you can just throw away a an old stash thing i probably i don't know i just i never throw it away so i guess it's not trash you're a hoarder get archive but not in get the way you archive other stuff that's what the command should be all right okay i will thank our patrons thank you so much to the stochastic parrot alice joss jost andrew pollock the yeet your job podcast avery sturtzel ian walter aranduna kashokton ohio cameron hall patreon.com.au we're hiring ira chan monkey face emoji jonathan king testing is documenting.org oladapo fadye i escaped from tarkov but i can't escape javascript ragnar harrison timmy gara brant nick hathaway travis sanders dennis bogdanoff

brayden canes john grant i bought winrar nick kantar and philip john basile thank you to that group if you want to join them you can go to soft skills.audio click support us on patreon any amount that you contribute will get you an invite to our slack team an amount greater than some number will get you to have us say words that's right might be your name or anything really anything safe for work do we have a length limit what if someone just puts the text of war and piece please don't in their name field no please jameson don't invite them this will be the cheapest audiobook i've ever bought 20 but wait not really that's expensive for an audiobook that's true well you can do a one-time shout out you only need one recording of the audiobook right

okay yeah the the the 20 a month plan would be you don't want an audiobook you want an artisanal performance of the book for you slightly different every time we should get to questions okay do you want to read our first question yes i do okay this comes from an anonymous listener who says is it possible to move too fast and do you believe in too much enthusiasm i am one of the youngest members of the team and i'm always willing to start new projects and balance a few different things. Is there a point where this can start hurting my career? I've gotten bumped in competition fairly, almost 25% raise since I first started. My career goal is to stay on the programming side, but I want to become a possible trainer for new engineers and developers. Hmm.

Is it possible to move too fast? I mean, the speed of light means no, you cannot move faster than that. So it's not possible to move too fast is what you're saying. Yeah. Yeah. You can't. Yeah. Yeah, I think so. Somehow. My initial reaction to reading this was like, it sounds like this person is going to create a lot of work. Juggle a bunch of things at once. Start a lot of new projects.

I mean, maybe they just didn't include it, but I don't hear finish a lot of things and like simplify and remove pain. Nobody ever says that. Like I have a bad habit of just finishing too many projects. When I start something, I just have to finish it. And I wish I didn't. Maybe this is a junior, senior thing, though. I can see enthusiasm is, I think, more valuable earlier on in your career.

And later on, I think for most people, you kind of evolve towards maybe you're juggling fewer things at once, but they're harder things and you deliver more on them than kind of move a bunch of things forward at the same time. Maybe this is just a 10x developer, though. That's possible. Maybe. Maybe they start 10x more projects than the average developer. And I'm also kind of applying a team lens to a person.

I feel like every time I've worked on a team or been around a team that has a lot of stuff going on at once, what it really means is they're not getting much done on any of those things. And it's always made things better to just reduce the amount of work in progress and work more on fewer things. I think that probably applies. There's a lot of context switching here if you're juggling all this stuff, right? True.

And what this tells me, well, okay, let me back up and say that I was this person at the beginning of my career. I love jumping into new projects, new technologies, new tools, new languages, new everything. Then, as I became more experienced, I started spending a lot more time fixing all these old things that no longer work. Things that were once new and now are just tech debt. You know what I mean? yeah i don't know where i heard this first but it code is is a liability not an asset yes that's the the lesson that may not have been learned here at the same time i don't know there's i work on a team that is building features on an application and we can't just we have more

stuff to do than than we are able to do at the same time but if we could magically just try out a bunch more things that might be a useful trade-off sometimes as kind of a spike or a test or a way to decide what to focus on later. And I will say that if you have the ability to context switch quickly and not pay a long overhead to switch between projects, that's great. I think that will serve you for your entire career. Not everyone can do that. Some people like they take a whole day. It's like, well, I can't, I'm going to work on the front end, but then if I try to touch the back end it's going to be a whole day just to kind of get warmed back up into the back end you know but if you can kind of hop around this project that project that will serve you

very well and this could be you developing that skill you just spent four hours staring at your terminal you've typed out make but just haven't hit enter yet what do i just gotta prep myself what if it fails what if it takes too long to run is there a point where this can start hurting my career not if you switch jobs often enough you outrun the the blast wave behind you bumped in compensation fairly almost 25 well that's rad you got a 25 raise since you first started it it does sound like you're doing the right thing i think yeah my broad feelings are i agree with dave that finishing stuff is generally more valuable and harder than starting things and has a much lower cost usually where starting

things has a potentially very large cost that you don't see up front so maybe maybe you can start to take small steps towards finishing things or or maybe you hand them off to someone else to own and and maintain well or something like that maybe you're prototyping stuff out if you're just leaving like a slew of microservices each written in its own different language and framework and different monitoring standards and database models or database paradigms, someone will curse your name pretty soon. Oh, yeah. Oh, yeah. But I think this is pretty normal. And I would say, hold on to this enthusiasm as long as you can, because eventually the reality of maintenance costs and your team's ability to absorb change, these will all catch up with you eventually. And frankly,

I think that's what differentiates a more senior tenured experienced engineer from a newbie. One of the big things that differentiates them is that a senior tenured engineer should have the ability to make long-term decisions about new technologies and new languages and things and be able to plan for their continued operation and maintenance. And if you see that you've got a team that's not going to be able to handle that, you might make a different choice. And frankly, you might get a little more pragmatic about it and say yeah i see this is new and fun but i don't you know i don't think that the newness and funness outweighs the long-term operating costs of this thing yeah it's a good way to put it so good that maybe we've answered this question maybe yeah this is a good

problem to have though much better than the opposite problem of like well i guess the opposite problem is finishing too many things the inverse problem of i don't finish one thing i start too many things is that the inverse i think the corollary is corollary inverse contrapositive maybe it is that you don't ever try new things ah and then you become obsolete and that that i would say that's much worse for your career than trying too many new things yeah yeah that's a good point it's easier to move into a more stable direction than kind of break out of stagnation yes cool do you want to read our next question dave wait well i mean i want to but i'm gonna let you do it anyway yeah i retract my offer for you to read it and i will snatch the offer and

read the question instead a listener named michael asks i'm a back-end engineer in an engineering coding role with a small bit of sre type work site liability engineering is what sre stands for i love the work as i get to dig deep into tech we use and have become a subject matter expert on databases within the company. I really like my team and my manager in particular and get to learn a lot every week. My manager is leaving my team to lead a new team within the company that is focused on the company's SaaS offering. And I've been given the option of joining this new team if I wish. I like their managerial style and how they have helped me with my career progression so far. However, I'd be doing boring SRE work. I'm not sure if I'm ready yet to commit

to being an sre and code less and focus more on ensuring the reliability of mission critical production systems i don't know how easy it would be to switch back into a more of a coding role in a year's time or if it would pigeonhole me into that type of role have you got any advice oh this is a big decision dave they didn't ask how big the decision was they asked oh sorry well you didn't ask but i'd call this a seven i'm doing my traditional flip-flopping in my head while i read this swung from one strong opinion to another now what do you think they should do well i let's see do i know anyone who has switched back i think this is a big company right do we think yeah it

sounds big if they have sre and different teams working on sass and something that isn't sass man i'm just thinking about interviewers talking to you for your next gig and you've been an sre for the last three years and they're like oh yeah but you're an sre you know and it's i'm just trying to put myself in the narrow mindset the rushed mindset of an interviewer who's trying to make a snap decision on whether to hire you as a software developer when you've got this three years of sre or four years of sre on your resume i think a lot of people are going to look at that and not be able to get over that hump. And they'll just pigeonhole you mentally as an SRE. So I don't know. That's a tough one. So I have a bit of a problem with the way Michael is describing

SRE work. Code less, focus more on ensuring the reliability of mission-critical systems. My understanding of the SRE role is it's still coding. You're just writing code to manage and maintain infrastructure and increase reliability not to build products necessarily yeah so different code yeah like the the google i think they're kind of the the originators of this the sre book and the way they talk about it is very much still hands on the keyboard typing out code oh yeah and and their sre orgs have produced a lot of products that are are used by internal teams to kind of help their systems. And didn't Kubernetes come from that lineage?

I think so. I think Prometheus did too, if I'm remembering correctly. So there's coding, you're saying. Yeah, or there should be. I mean, maybe this is not how SRE works at this role. This sounds more like what I'd call a kind of traditional ops, not SRE. And maybe that's just a naming thing.

Maybe this company calls operations roles SRE because it that's what google calls them they think yeah oh yeah i've seen a lot of that that pattern but you could just quote the sre book at them that's a surefire way to get them to change all their strategies excuse me you are using this word incorrectly as noted on page 15 edition 2 there's a bunch of possibilities here one of the possibilities is that it really is an ops role you won't be coding and if you are coding it's probably bash it's made out of bash and like rage and then that's a bigger decision because it is a bigger career change if it either is more like traditional sre or you can turn it into that then you'll still be doing a lot of coding and

i think that would not make it harder to move back into software engineering it might make you more of a fit for some more specialized software engineering roles that you might not have been before. Like HashiCorp has a bunch of like infrastructure products that are kind of SRE type things. And if you've worked on that stuff, then it's going to be easier for you to go work on Terraform, for example, or other projects or products that are targeted at solving these problems, but working on them as a software engineer. Yeah. Just personally, I think this kind of work is really fun i get super excited about infrastructure reliability high availability monitoring alarming i think this stuff is really really cool especially if you can do it at large

scale i don't know i just think it's really really fun do you enjoy the the power of knowing that you'll be able to page like 500 people with this setup that you made that's actually the most terrifying part of the whole thing but like i don't know i get i really geek out on infrastructure because i feel like it's actually this is going to sound weird but it's closer to traditional engineering like the traditional mechanical engineering and stuff like that that's you know more nuts and bolts because you're actually doing things like balancing cost like actual dollars a lot of times where you're like well this service costs x dollars per month if we if we scale it to this volume but we've got this much demand you know and it's actually

a lot more like well okay i can't say if it's like mechanical engineering because i only had two semesters of mechanical engineering in college, but I can say that it feels like it's in that direction more. And I think that's really cool. Is it like the two semesters of mechanical engineering that you had in college? No, it's nothing like that at all. Those two semesters were rough. Did not like them whatsoever. But I do like the real world analysis. You know, as a developer, it's like, well, I could write this for loop this way or that way. And it's like both ways making no difference whatsoever in any like in any way like well i prefer the curly brace here it's like no it doesn't matter but but with infrastructure engineering and sre stuff it's like

oh that's gonna make a five thousand dollar a month difference to our bill you know like let's consider that trade-off it's like way more concrete than than stylistic code stuff so anyway i think it's fun michael also mentions a manager that they really like and has helped his career so far And there's two ways you could look at this. One is it might be useful to see a different style. Maybe you'll get some different strengths out of a new manager that will help you in different ways. The other way you could look at it is to say, probably if your manager is great, your next manager is going to be worse just from how averages work. And that's matched my experience most of the time. I think I've had management changes. It gets worse in general? I was more bummed out. There's also a really big cost, especially if you're focused on career progression, to resetting that context and developing a new relationship and understanding where your manager thinks your skill level is at. And depending on how close or far you are from promotion, if you think you're close now, you aren't anymore once you switch managers in the worst case. Sometimes you still are. So that can affect your career progression quite a bit. And if you have a good manager who's done a good job taking care of your career, then that probably mitigates a lot of the risk that your career will have problems by making this jump to an SRE role. That's true. If you have a good relationship with your manager and you do want to go back to software engineering, having your manager kind of on your side makes it way easier to make one of those transfers internally.

And maybe you don't have to choose right now. Maybe you could stay on this team for a bit, see how the new manager works out, and then choose. Yeah, give them a trial period in writing. You have three weeks to impress me. Yeah. I have scheduled our performance review three weeks from now. Yes. But even then, you mentioned that the risk is mitigated by being able to go back. That's true. But also, your manager might be able to craft this new job on the SRE team in such a way that you can get the growth that you're looking for in your career and not get pigeonholed. back in that direction for your next gig yeah i think i'm definitely leaning towards going with your manager and sticking with someone that you know has been great and very supportive of you especially if you can like you said craft this job into something that involves more coding

or clarify what they mean by sre yeah a good manager is is worth a lot i've heard that pithy phrase that people don't quit jobs they quit managers yeah and this is somehow connected to that right like you want to stay with someone that you like yeah you're not quitting and and no works well for you yeah or i mean maybe if you want to quit your job this is like a first baby step to it it's just like not follow not follow this manager you like yeah yeah if you're at war with yourself there's something else you might want to keep in mind here when managers transfer and their teams follow them that actually makes the manager look really good and so you're doing your manager a favor which means you can ask for a raise that's how it works reciprocity

i don't think i've seen well have i i don't know maybe i've seen this i'll never know because i'm going to stop talking about it and thinking about it if you got any advice yeah i think i gave my advice i think one other option too is just to talk with your manager about what they think you should do. Maybe they know the manager that's replacing them and can give you some insight into what that would be like. Or maybe they can give you a more clear answer on how much code you would be writing in this new team. Yeah. I also think the most important thing you can do is figure out that question that Jameson just called out. Is this going to be a coding development role or is this going to be like sitting in front of a screen and watching

charts to see if numbers go too high or too low and then calling someone? If it turns out to be that ladder kind of thing it will absolutely be a setback in your career and it will make your next job a lot harder to get yeah i mean there's there's more to ops than that i know i'm kind of i was kind of painting the the worst case scenario okay yeah i work with some very skilled ops folks absolutely i don't want to i don't in any way mean to belittle that yeah it is a fascinating and valuable role but if if you really want to write code and that's not what it is then you should know that yeah so anyway that's that's my advice is scope it out maybe go talk to some of your peers and hey you're at the same company right so should be pretty easy yeah to go figure

this out that's a good point should be easier to gather info about what it's going to be like maybe it's a new team that's uh well i mean i guess it's a new team if there's a new manager maybe maybe you can't look at what that team is already doing and figure out what you will be doing if that's the case then you probably have more power to turn it into something that you want to do though right all right that's that's it i'm done okay i'm used up me too what could people do if they want their own questions answered go to soft skills.audio and click the ask a question button you can fill out that form with your information you could leave it completely blank or you can tell us that your name is some unpronounceable emoji which is also

fine and we just have to say thank you so much to everyone who has submitted questions we really appreciate it you are rad thank you for doing it and we will catch you next week We'll be right back.