Soft Skills Engineering - Episode 361: Get git and non-tech ramping up

Episode Date: June 19, 2023

In this episode, Dave and Jamison answer these questions: Listener Schtolteheim Reinbach III asks, Hey soft skills engineering, love you guys. I work at a company you wouldn’t hear much about, on a product that you wouldn’t think about as having much tech involved- suffice it to say, it makes me interesting at parties. I’m not a developer myself, but on my team, I’m having an issue with a developer who can’t seem to use GitHub properly. Fairly often, whenever he fixes or creates things, he doesn’t seem to check them in properly, and between releases, numerous times, this has caused people to end up reproducing work, for the developers, business team, and QA alike. He’s been at this company for several years, and people have only complained, but no one has made an effort to fix it. I don’t manage him, and I can’t see the processes that are in place on his end, how do I go about reducing the amount of regressions that are created due to a developer who can’t Git? I’m also interested to hear if you two have similar stories about devs who can’t Git, or if you’ve been that dev, and what happened. I quit my job and got a new one! What should I be doing during the initial ramp up period that shows I am a skilled engineer even though I do not know the main languages they use? Also any advice on the non-tech side of ramping up? What should I be doing besides learning the tech stack and fixing bugs? Thank you for all your help and feedback. Show Notes https://xyproblem.info/

it takes more than slipping a note card labeled dot ds store into every book you open in your library to be a great software engineer this is episode 361 of the soft skills engineering podcast i'm your host james and dance i'm your host dave smith soft skills engineering is a weekly advice show about all the non-technical things that go into the technical field of software development and where we make jokes about the mac os file systems metadata format i guess we kind of have a theme emerging where we try to take silly things that happen in the remote or digital world and make them happen in the real world i'll just write down my name and when i open the book like i said keep it up to date we kind of already have those with library cards

remember those or not library cards what were they called the the checkout things the things that you would like sign or get stamped in the front of the book yeah yeah those were so satisfying and it was cool to see the history of who else had checked out the book almost as cool as a git history alas does not exist anymore except in some database yep dave do you want to thank our patrons yes we have weekly shout outs for trash panda thecomputersciencebook.com the re-elect jameson dance boogie brigade the re-elect jameson dance committee santa hope our noah frazier low kent c dogs jenny kim owen chardell benjamin earl if you would like to join this illustrious crew to go to soft skills.io and click the support us on patreon button craig motlin i love mavis the

stochastic parrot alice jost tuscarawas ohio i'm gonna have to look that one up later patreon.com.au we're hiring irish and monkey face emoji jonathan king web tau awesome end-to-end testing oladapofadi the re-elect jameson dance committee nick hathaway travis sanders braden canes john grant cody please hire jameson sale nick kantar and philip john basile if you would like to join this illustrious crew go to softskills.audio and click the support us on patreon button any dollar amount will get you access to our slack community where you can interact with this illustrious crew and any amount over a sufficient threshold will get us to read whatever you type into the patreon name field and then you'll truly be a member of the illustrious crew

illustrious sir yes i think that's the illustriousist is that the superlative probably most illustriousist yes uh i better read a question do it before i make up even more words Okay, this is from a listener, Stolterheim Reinbach III asks, I'm going to risk offending you and say that's probably not your real name, but I'm going to Google it after this. Hey, Soft Skills Engineering. Love you guys. I work at a company you wouldn't hear much about on a product you wouldn't think about as having much tech involvement.

Suffice it to say, it makes me interesting at parties. I'm not a developer myself, but on my team, I'm having an issue with a developer who can't seem to use GitHub properly. Fairly often, whenever he creates or fixes things, he doesn't seem to check them in properly, and between releases numerous times, this has caused people to end up reproducing work for the developer's business team and QA alike. He's been at this company for several years, and people have only complained, but no one has made an effort to fix it. I don't manage him, and I can't see the processes that are in place on his end. How do I go about reducing the amount of regressions

that are created due to a developer who can't get? I. I'm also interested to hear if you, too, have similar stories about devs who can't get, or if you've been that dev, and what happened. Everyone has been that dev at one point. No one is born getting. If you're ever Googling reflog,

you're currently that dev. Or cleaning up after that dev. There is certainly a rite of passage where every developer has messed up Git at least once, like really catastrophically, and you had to rebuild the history. I remember when we were introducing Git to our team at work many years ago, and someone checked in an entire Linux CD-ROM ISO file into Git. It was like 600 megabytes. And so every time someone cloned the repo or pulled, it got really slow and bad. Yeah. Did you have to remove it from the history?

Yeah, we had to go in. edit the history and it was beyond my ability at the time but the person who brought us git this is like 2008 uh they did all the git magic to make that work they possess the arcane skills advanced knowledge and techniques exactly this does not seem like i mean they didn't tell us what their process is and they mentioned releases and theoretically you could devise a a process using git that would be hard for developers to follow correctly oh not just theoretically yeah that's true okay that is a practical reality flow was that the thing that had a cool website that everyone did for a long time that made their lives worse yeah

we don't officially express an opinion on technical topics like that but yes yeah but from reading the question this sounds beyond what i would attribute to a process being complicated because they seem it seems like this person is is uniquely messing it up more than other folks right so i'm gonna briefly say maybe make it un-mess-up-able and then skip over that because that's probably more work there's kind of a meta question here which is as someone who doesn't have influence direct you know formal direct influence on this team or visibility into what's going wrong how do i fix it because the problems definitely directly influence me but i can't influence a solution yeah there's a an answer that applies to these kind of problems

that has lots of caveats but i will say it anyways which is you you walk the tree till you get to that person so you talk to your manager and then if they manage the person they talk to the person if not then they talk to the manager who manages that person or if they're in a different part of the org they talk to their manager and then it kind of goes up until the root of the tree okay someone in that person's reporting chain and traces back down this sounds like a google interview question is there is there backtracking involved in this usually yeah usually there's backtracking when someone along the chain says something wrong or misinterprets it

and then has to back out of what they said and disavow it. So yes, I guess. Yeah. So if you're on the same team, this can work decently because there's less room for mistranslation. But the further away they are in the org,

the more steps it's going to have to go through and the more different people will have to put something on their to-do list to make this happen. so depending on how close you are into the org this might be a thing you could do separate from just walking that tree this also includes the difficulty of you telling someone hey this person is messing up and then right hoping that they fix it and and that's also kind of fraught uh and then the more steps it goes through the more nodes it nodes i don't know yeah these are

nodes yeah the more nodes you go through in that in that traversal the more room again there is for misinterpretation like by the time it gets to this person it might end up as hey schottelheim reinbach said you suck at git fix it you know like or or it might be like there's severe concerns about your performance at this company and we're letting you go or like it might just morph or yeah change in ways that you do not intend are you saying is that a compelling reason to avoid actually following this process and instead go straight to the person yes because dave you're gonna tell me how i do that without offending this person oh oh and now i have to rethink my answer because i was planning on offering some offense ah yeah i mean there is a telephone game

risk here if you were to go directly to this person as a product manager wait did they say product manager i think so right no uh they say i'm not a developer myself okay oh wait on my team okay they're on the same team oh one node okay good maybe that's less bad yeah i it's funny how i just assume they're a product manager if they're not a developer i mean what else is there obviously by process of elimination you are a product manager and the fact that you care about releases. You can tell by the title with royalty. Yeah, exactly. Exactly. You're a royal product manager descended from the great Reinbach dynasty. Here you have a place. I think you have an opportunity to sit down directly with this person and tell them, hey, I've noticed a pattern of you

breaking releases and it seems to be Git related. Now I'm not a developer, so I can't tell you how to fix this but is this something you're aware of and are you working on this now that that's probably how i would tee up the conversation the problem is if you're not a developer and you don't know the specific problems the developer in question here might come back to you and say yes i'm aware here are the three things i'm doing to fix it and you won't know if those are good you know you're like sounds good to me oh he he said he was gonna rebase instead of merging oh that sounds right it's like i don't know if that's right so yeah that's kind of tricky it seems like you're going to need to go find yourself a partner to come and do this intervention i also wonder

they mentioned github they mentioned git i guess this is kind of general for when you don't have the exact technical details but if you can focus on the outcomes you're seeing instead of the things you think are causing it or contributing to it it's possible it has nothing to do with github at all and it's more like the ci process for cutting a release or something and so if you say i think you don't know how to use github properly and that's not actually the problem as a defense mechanism the developer might flip the bozo bit on you might think oh yeah this reinbach character i google this by the way it looks like it's from a jrpg series that i've never heard of but has a very exhaustive wiki oh is that what you've been doing instead of

listening to my answers quiz me on what you said i'll prove i was listening now i'm counting on you not being able to remember what you said in order to you nailed it in order to formulate a question you placed your bet and you're gonna walk away with the win today yes no one will know except all the people i just told uh what was i saying oh yeah you if you can focus on the impact you're seeing and the outcomes you're seeing instead of your hypothesis on why they're being created that might make it easier to solve and also kind of makes it easier for someone else to dig into and diagnose more clearly yeah i guess another option is that you could go through the effort of working with this person to diagnose why exactly this is happening but that gets into

manager territory it feels like why why is this thing happening so i mean this is what engineering managers are for to that's right help the team get better with technical competence and the and the context to be able to do that when when the thing there they need to improve on is is technical that's right or non-technical yeah i think i'm just going to roll back my whole earlier answer about walking that tree like they're on your straight to their boss yeah you should have an engineering manager on the team you should be able to say hey i've noticed this thing fix it can you make it better yeah it's your job your job is to run a team that does consistent releases and doesn't introduce incidental errors and so fix it you know it's your job and they'll

probably be like yeah i've been trying for months and i don't know what to do from the outside But I would way rather have a problem caused by wonkiness around release practices than an overall technical quality problem. If there's just a lot of bugs that get introduced, that's such a broad problem, often without very clear solutions. If this is all because one person is not following the release processes, I feel like you should be able to make a big improvement. You should be able to look like a hero if you're the engineering manager. Yeah, but then why is it there in the first place?

I don't know. Yeah, exactly. Oh you created the problem and you solved it. Now you're a hero. What? I don't know how this works I want to rewind the clock just two minutes and say I think the name for what you were describing Jameson when you encouraged the question asker to focus on outcomes instead of diagnosing the problem is the xy problem Am I right? Yes Yeah, I was not thinking of it like that. But yes, I think you're right yeah so the xy problem is where you propose a solution or over diagnose the problem or

misdiagnose the problem and ask the person to solve that rather than the actual outcome that you're going for very very common actually in software because the root causes of problems are often not obvious by the symptoms i think there's it's one of those things that has a website that describes it, right? It does. xyproblem.info. I just Googled it. Yeah. I wonder what fraction of links on Stack Overflow are links to this website. It's got to be a non-trivial amount. Oh boy. Anyway, that was a little time travel sidebar. Going back to the present, there is a possibility here that this manifestation of errors is indicative of this developer's lack of skill to do the job that they're being paid to do

and so it could be that the reason this keeps happening is because your engineering manager is hesitant around taking more serious action against this person because it's a performance problem and performance problems are notoriously challenging for engineering managers and a lot of managers don't like to confront them head-on because they're awkward and uncomfortable but it could very well be that there's a deeper skill gap here and that git is just one of those places where you're seeing the skill gap so you should be sensitive to that when you go in because the engineering manager might be like thank you for the feedback and then kind of seem dismissive to you but the engineering manager is secretly pulling their hair out trying to solve this

performance problem and not getting traction yeah it's possible i really do think your best bet would be to partner with the engineering manager on this we kind of talked at the beginning about the process and maybe it's complicated maybe there are things you can do to help influence the process as someone who kind of observes it and and sees the impact that the current process is having even if it's mostly caused by one person but that also helps soften the message of you are the problem to the developer if it's if it's both an attempt to improve how they use the process and improve the process then maybe it assuages their ego a little bit maybe that's not a thing you care about though i don't know all right have we answered the question i think so

good luck best of luck to you uh i hope you get to turn into a real life person someday instead of a cartoonish pixelated rpg is it kind of a anime themed rpg i think so yeah yeah it looks like it 1995 oh vintage all right shall i read our next question yeah please do okay this comes from an anonymous listener who says i quit my job and got a new one what should i be doing during the initial ramp up period that shows i am a skilled engineer even though i do not know the main languages they use also any advice on the non-tech side of ramping up what should i be doing besides learning the tech stack and fixing bugs thank you for all your help and feedback all right this is nice nice to see someone getting a job instead of just getting

laid off man i wish that were me it will be hopefully soon well you're a valuable asset jameson it's only a matter of time before this market scoops you up i have been interviewing a lot and my the podcast has come up a lot and i have not figured out a comfortable way to discuss it besides just hiding in shame which is what i do yeah hey if i interviewed with you and you're listening to this now because you said you would you should hire me there i'll insert super liminal messages that's awesome what should i do to ramp up i know dave you've talked in the past about wanting to hire people

who i can't remember the smart ways that you said it so i'm going to say it in dumb ways but you've talked in the past about not wanting to hire for specific languages we we use python we hire people that know python and and that makes a lot of sense to me the set of people who could comfortably do the job well is is not a subset of the people that know the tech stack you already use but in that case then you do have this training thing how have you seen people be effective when they join and need to come up to speed on a new tech stack well i kind of sidestep that problem a little bit because i tend to hire people who have a proven track record of already doing it and i don't know how they do it you just know that they've done it before i just know they

have and i know they can do it again got it i guess i have some techniques on how i've done it over the past because over my career i've done major tech stack reboots maybe three or four times where I'm completely walking away from, from some language or ecosystem and walking into a whole new language and or technology stack. And what I'll do is before I start the job, I'll actually buy a couple of books on the languages and technologies and, and read them cover to cover and really make sure that I've got a solid foundation. Because one of the, one of the risks when you're learning a new programming languages is that you, you mistranslate concepts from one language to the next and i remember when i started a job in 2012 i had come from a job where i was writing only c

plus plus and uh one of the new languages i was picking up not it wasn't totally new to me but one of the languages at the new job was javascript and someone commented hey your javascript looks like c plus plus and i was like oh crap this means that i'm not really writing idiomatic code in the new language and so i need to go expose myself to more code written in that language were they complimenting you on you having figured out how to do template metaprogramming in javascript i don't think it was a compliment this is incredible how did they figure out pointer arithmetic this isn't the feature of the language you know what javascript needs pointer arithmetic it's not dangerous enough needs

easily accessible use after free errors the barrier to entry to use after free errors is too high yeah they were subtly telling you they found a buffer overrun yes exactly in your javascript code yeah you your code looks like javascript code in the fact that you got the interpreter to segfault oh no i took that i took that as not a compliment actually because it showed that i was not really using the language to its full potential. And maybe more importantly, I wasn't matching the patterns on the team. And so my code looked foreign to them, even though it was in the same language. So I like reading books to learn new languages. I think it's a great way to just

go all the way to the basics, to the fundamental building blocks of the language. And it'll also save you a bunch of time where you're like, oh man, what's the syntax for this looping that I like? You know, just really basic things. Don't spend time on the job fumbling around with looping constructs and basic conditionals and things just read a book and that stuff will be like chapter one yeah so that that gives you the kind of broad overview and then you at least will have heard of concepts that come back up that right you can go dig into more oh yeah that reminds me i remember my first the same job within my first week one of the other developers used the term object literal in in a javascript context and i literally thought no pun intended

that he was making up that word i'm like that doesn't exist and then later i realized oh no that's actually a an interesting javascript feature called object literals and i'm like oh and it's useful and so i'm like ah you're making that up yeah and that's just because i didn't have a good foundation oh i'm thinking back about what you said about you just hired people who did it i think there's a balance there um i worked with someone at a previous job who was learning a new language that was in also a pretty new paradigm not just kind of the i feel like you can kind of squint and get from ruby to python to javascript to go to java and like there's some common things in in what's that parent language that they all descend from algol is that the one

and like the algol children languages and they explicitly said when they joined hey i'm going to put a lot of effort in to learn this language, but I didn't really see it. I did see a ramp up in the speed and complexity of their contributions, but they didn't say, they didn't tell me their detailed plan of I'm going to reserve, I don't know, five hours this day to go read this book or follow this course or something. And the point I'm meandering towards is you want to make sure you're communicating that you are working to get better i think unless there's explicit expectations set by the company that you will join and kind of do nothing except learn the stack you want to avoid looking like you're doing nothing except learning the stack you should still be able to

get something done yeah as a software engineer new to the stack there should be some kind of easy tasks picked out for you or that you could find if they aren't prepped for you so i think i think my point is you want to balance you're not going to school right you're they didn't hire you to to teach you this language they hired you to get stuff done right so the expectations of how much you get done might be lower at the beginning but you still should be able to produce some output even if the output takes you a long time or is not idiomatic or you need help from others to figure out how to do it in the new tech stack or whatever the other point i wanted to make is there is a so this is the tech stack right the stuff i don't know you go somewhere they do java

you go somewhere else they also do java everything else is going to be totally different um yeah there's there's some non-transferable knowledge about the architecture and the setup that you're going to have to develop even if it was in the exact same tech stack you were already familiar with if you had not switched tech stacks and you you can kind of combine those learning periods of learning the architecture and the patterns of the code base and the the software with learning the new language but they should have some expectation of of even if you there's some ramp up even if you're familiar with the ecosystem already yeah not familiar with with how it works in the company exactly like you don't know the names of all the services you don't

know the uh deployment tools and processes you don't know the oh you might not even know the git workflow just yet yeah exactly yeah maybe they're using puppet instead of chef or something like that and i have to figure out okay how do i deploy stuff and yeah exactly infrastructure set up and what about the non-tech side we've talked a bunch about the tech side yeah this is this is That's an interesting one, but I think if you're remote, this is more challenging than if you're local. I think some of this, or in-person rather, I think some of the in-person natural organic activities that just happen will help you get to know your team members. Things like make sure you're not just sitting at your desk all the time, and when someone walks over near your area, be sure to put your headphones down, turn around, look at them, have some chit-chat, engage, follow their lead on how much time is too much time, and be sure to engage. Now, if you're remote though, oh boy, that's harder, but I would probably set up one-on-ones with everyone on my team. Just schedule 20 minutes on their calendars. Just tell them you want to get

to know them and ask questions. And, you know, if your manager is really on the ball, your manager will probably give you a list of people that they want you to go meet in the first week or two weeks of your time on the job. You just got to be a lot more proactive about it though, when you're remote. I love that idea of scheduling one-on-ones with the folks on your team. It feels like a very manager thing to do and that i would expect a manager to do that when they joined a new job but it's important for non-managers too you gotta talk to these people and know them and work with them put a face to the code they'll be reviewing in a pull request or the slack message they're going to get asking for help setting up the environment or whatever yeah for sure

have we answered the question well probably not but it's pretty good marginally good enough the standard we strive to achieve all right and sometimes we do thank you for asking and congrats on sometimes we achieve it yeah i mean we strive to achieve it we don't promise yeah it's a goal and it wouldn't be a good goal if it were easy that's right it's a stretch it's a stretch goal the good enough stretch goal oh yeah i'm glad you got a new job it's exciting it's it's a there's a fun energy that comes with getting a new job that yeah for sure it's it's a good time all right what can people do if they want their own questions answered go to softskills.audio and click the

ask a question button where you can fill out our little form that asks that lets you ask whatever question you want and for those of you whose questions we have answered in the past you can use that same form to tell us how our advice went whether it was good bad indifferent and it turns out there is no html form validation that will prevent you from submitting non-questions to our question form that'd be some fancy attributes on html it's coming with the ai large language model yes attribute data dash llm prompt or something right that's actually a cool idea and maybe i'll go build that because i'm unemployed all right all right thank you we appreciate it catch you next time