Soft Skills Engineering - Episode 215: Many jobs in one and junior git stickler

Episode Date: June 22, 2020

In this episode, Dave and Jamison answer these questions: Questions Listener Ryan asks, I am the only full-time software engineer at a relatively small company. There is also a contractor who has been with the company off and on for about 25 years. How do I manage playing multiple roles when the development team is so small? I take the role of software engineer, team lead, software architect, product owner, project manager, designer, QA, etc. Some of those roles are full time jobs. How do I still make progress on development (i.e. coding)? Hey guys, love the show. My question is this. I work in a small startup. About a year ago our team documented what our git workflow would look like. We agreed on things like rebasing instead of merging to master, and never squashing our commits into one, that sort of thing. One of our developers is now making a fuss about following these rules and constantly does their own thing. After speaking to them about it, they shut me down and said it is up to the individual developer to decide how they use these tools. There have been some heated discussion on merge requests with this person telling our senior devs that they don’t want to hear their opinions. This person started at the company 6 months before me, and I am only a junior engineer myself so I’m not sure if there is really anything I can do. I have been at the company for 2 years now. I have offered to help them learn how to use git the way our team agreed but was told “no thanks, I’ll do it my way”. What is the best way to navigate this situation? Is this something I should escalate to my manager, or should I just get over it? Thanks for the help, can’t wait to hear you rip this one apart :P

it takes more than having a net negative number of lines of code in your career to be a great software engineer this is episode 215 of the soft skills engineering podcast i'm your host jameson dance i'm your host dave smith soft skills engineering is your weekly advice show on the soft side of software engineering the non-technical side software engineering it's actually hard but it gets called soft anyways yeah it's not about how to do good you've had 215 chances to practice this and we still i'm still polishing that's how committed we are to this craft we will never stop messing up because that means we've stopped improving that's right we've learned from the vcs we're gonna fail often and fast yep

i do wish i could see like total lines of code change in my career it would be cool if it was negative i've deleted a bunch of code at this current job and it feels so good it feels so much better than writing code i don't know why it does because there can be no bugs in the code you deleted yeah only in the code that depended on the code you deleted and i actually get more notice for deleting code like if i write features people that use them say good job but if i delete a bunch of code then my team is like oh this is so incredible like they're used to they see features all the time but they appreciate it when i delete code that's awesome it's like you reduced their area of concern yeah you know it feels so good here's all this stuff you never have to worry

about again yeah hopefully i just deleted 0.3 percent of the things you have to worry about in a day yeah well do you want to thank our patrons dave you bet thanks to those that are contributing so much that they have offered us their firstborn children and we therefore shout them out on the show every week they are they are brayden canes dennis bogdanov evgeny sladkowski john grant luke bayless microconfig.io nick hathaway nick cantar alexander philip john basile ryan the real mccoy agile ventures charity sean stanley tactical radio steven armand lee travis and vinlock if you'd like to support the show on patreon we would appreciate it all you have to do is go to soft skills.audio and click support us on patreon and if you do and you enter

any number in the dollar box that is greater than zero we will send you an invite to our slack community which is a really fun place to chat with other soft skills engineering listeners 300 listeners strong and lots of good advice in fact i've noticed they're doing a weekly zoom hangout now where you can chat with each other really cool it's super cool to see this stuff spring up i also i can't remember if it was from the slack cult but the name soft skillets as a as a name for the listener group that's from slack right yeah i think so yeah so fun culture happens there soft skillets i love that one all right i am gonna read our first question this is from a listener named ryan who asks i am the only full-time software engineer at a relatively small company

there's also a contractor who has been with the company off and on for about 25 years how do i manage multiple roles when the development team is so small i take on the role of software engineer team lead software architect product owner project manager designer qa etc some of those roles are full-time jobs how do i still make progress on development i.e coding hmm many hats one small head yeah get a bigger head then i think is that yeah that's what you're suggesting like this giant balloon head where you can put lots of hats on yeah this is interesting have you ever been in the situation where you've been sort of the the lone technical person no i've never been the absolute lone technical person but i have been i've been on a team of two

which basically means that the dev team is also the it support team gotta set up printer drivers and yep manage active directory servers and of course you know what happens when you make your engineers your it department you start to use ansible to provision your printers like in my case we had this comcast like business internet service but the router was flaky and so rather than just like calling comcast support i like purchased a raspberry pi or something like that and a usb controlled relay that could supply ac power and like set up a cron job on the raspberry pi to reboot like power cycle the router every every night i'm like i am your it department and your engineering department which means brilliant

your it systems are over engineered hey all of your employees office computers are also part of this kubernetes cluster exactly huh i've been in this sort of similar situation where i was the only full-time technical person and there was also a long-term consultant that was there that was doing some other stuff and i kind of liked it for a while it's fun to not have anyone to tell you what to do oh obviously they were paying me money so i was trying to do a good job and wasn't like thanks for the free not even free thanks for paying me to learn rust suckers like but i liked sitting down and thinking like here's this business problem how do i solve it at all levels from like what product do we build how do i design it how does it work how do we test

it, how we deploy it. It was fun. The reason it was fun and not horrible is because there was not an extraordinary amount of pressure. Their expectations for me were pretty low because I'll say delicately, they had had bad experiences in the past. So just by showing up and being a human that speaks kindly and gets stuff done, they were astonished at how awesome I was by being normal and and so i think that made it fun instead of soul crushing it just sounds like you were standing on the shoulders of not giants i mean maybe the giants if they're evil giants that kill people got it the mean giants from skyrim that smash people okay clubs nice not like the giants that who was it isaac newton that said that whoever he stood on oh i

don't know i never met him well wikipedia says it comes from the 12th century someone i've never heard of oh you have now yeah thanks wikipedia anyways okay yeah i i liked it it did slow me down but also it did not slow me down linearly does that make sense like if if no if they're sorry all right i'm just using words that make me sound smart instead of make sense okay okay so say you are a developer doing all these things and then you add someone separate to do qa okay it's possible that adding a separate person to do qa will not make you twice as fast even if half of your time was taken up by QA. Maybe they are really good at their job and then maybe it makes you more than twice as fast, but it's also possible that it'll be less than twice as fast

because now you have all this communication overhead of coordinating with this other person where you just did it all yourself before. So it was certainly slower than it would have been with a full team, but I think if you know your stuff well, you can move pretty fast still as a single person that's my point does that make sense okay it does make sense i guess what i'm saying is all engineering teams should be one one person and they would move very fast relative to how many people they had we call that a quarter pizza team i don't think so you haven't seen how much pizza i can eat no i haven't half pizza team wait a minute oh dave it's still a two pizza team as long as the amount of slices that the team consumes remains constant

you get the same output from them okay you just get people fewer people that eat more pizza it's more efficient right right right so you want very hungry developers yes as long as you don't have to pay them by the slice you just you know you pay them a fixed rate and then yep they eat the pizza they're going to eat and you just reap the profits somehow there's profit in there i'm sure okay so i think speed of delivery is one dimension that can be impactful when you're a one person team but is it the only dimension how are you going to have nerf wars with yourself in the office yeah there's like camaraderie yeah i cut out some of the details but the question massacre mentioned being the only person who decides architecture and design decisions and

and some of that stuff is helpful to bounce off other people definitely it can make your decisions better so you might be doing weird stuff if you're doing it all by yourself oh you definitely are i mean it might be even weirder with someone else but yeah i think i think your growth will be slower if you're the only engineer at a company because you know as as uncomfortable as it is to have your ideas reviewed and critiqued by your peers those are the moments when you grow when you're exposed to new viewpoints also you won't be able to climb the ladder you won't be able to have underlings right yeah if there's a team of one who's gonna i don't know do your dry cleaning what what kind of stuff do underlings well i mean i was gonna say whose skulls will

you use to build your throne yeah exactly and who's gonna build it you're not gonna build it you direct the skull throne laborers thank you for finishing my skull throne well sir it's not quite done yet there's room for one more skull i know i kind of feel like we're getting far away from what the original question was asking which is how do i juggle all of these jobs that aren't coding yeah and still make progress on my coding like it it's like okay if i'm a qa person or a designer or a project manager or an architect that's great but if no one ever writes the code then all these things there's nothing to test there's nothing to design there's nothing to plan so at some point you have to actually write some code or not i don't know maybe that's maybe

that's a bad assumption on my part i mean if you architect well enough you can just generate your whole app from little metal diagrams i think you should try waterfall development right you sit down you do all the design take off that hat yep then put on your coder hat write all the code take that off do all the qa and then take that hat off and then put on your deploy to production hat your configuration management hat yeah exactly okay and then repeat yep that's perfect i mean i think you have to do that on the feature level just not like the whole project level there's probably going to be a little bit more design up front but you should when you take on a task you got to sit down and kind of iterate through each of those things some people do really well at

context switching and some people don't yeah and if you don't you're probably not going to enjoy this role yeah that's true if you want to be a deep specialist in anything besides the business domain that you're working in it's gonna be rough but you get to go really broad which i think is is exciting yeah i actually think end-to-end ownership of a problem space is underrated and this is actually really good experience to be able to say i truly understand the full development life cycle because i had to do all of it you know i mean there are there are armies of open floor plan companies engineers just who get a task implement the code ship it and then move on to the next task yeah very very limited scope but here it's like the business decisions you're

probably a part of those you're part of the testing you're probably the support team too when there are issues yeah you know they come to you this is good it's also a recipe for burnout but also a good experience yeah i still make progress on development i guess we haven't given any concrete advice on how to still make progress on development yet well what else is new yeah i think you get to see that writing the code is one part of building software and it's not the only part and if you just accept that then i don't know that you have to like not do qa so you have more time to write code just cut that out we don't need that yeah what if i just don't architect it i'll just stack overflow it to prod

the thing that would be hardest here is the product side for me and so to me that feels the most like this maybe this is just my personal skill set but that feels like the most separate of a job that i could dive into the deepest like architecture and writing the code and designing it and qa and stuff that all feels kind of in the same family of of types of work but product ownership is just such a different headspace to get into yeah so maybe there's some role for you to delegate some of this stuff to other people if if i know you're the only engineer but you don't have to be an engineer to be a product owner very likely there's someone at the company who could take on that role or at least could kind of vet your ideas so you're not you're not starting from

scratch you you can have somebody with that experience to tell you if you're going on the right track or not yeah well that's my only concrete advice okay good find a product owner i think this problem essentially boils down to a time management problem where it's very easy for some of these roles to expand so big in terms of time consumption that they crowd out the other roles like coding i think it's it's very easy to engage in endless discussions with the rest of the business architect design project management can easily explode because there's just so much to think about all the time and discuss and so many different opinions on that but like the coding part how do you actually block off time to make sure that

that makes progress i mean you could literally block off time in your schedule i like what you said about how all these can expand to take up as much time as you want maybe there's something there where you need to be disciplined in saying i will do the absolute bare minimum i just don't have time to make any progress if i'm trying to be like an expert qa person and an expert project manager and and do i mean you can go read a book about project management and then spend a lifetime implementing all those processes that's true or you can do like the one project manager thing that will move your product forward, whatever you decide that is. So maybe it's taking little tiny slices of each of these roles instead of saying, I'm going to be an effective software

architect. How do I do that? Okay. Here's this big list of things. I will do all of them. Okay. I'm going to be a very good product owner. How do I do that? And, and like dive into them super deeply. You just kind of have to do like the most helpful thing from each of these. Yeah. Also on the one hand, I mentioned that some of these tasks or these roles can balloon, you know like product owner and project manager but how much can they really balloon if there's only one engineer i mean how much how much like prioritization and roadmap and planning and resource allocation do you really need to do if there's just one person coding and it's you and you're not coding right now because you're doing the project plan yeah well you have to update it

in real time and then you get stuck in this endless loop of like you go to write some code and you have to go update the project plan to say you're writing code but now you're updating the project plan you have to update the project plan to say you're updating the project plan infinite recursion yeah never make progress i do think it makes sense to timebox a lot of these jobs and also block off time for the ones that require more like deep uninterrupted flow state work like coding if you're the only one it's got to get done and that that is probably the one thing that is like the scarce commodity on this list yeah although that might be my bias speaking because it's also probably the one thing that you enjoy doing the most.

Yeah. I mean, there's some truth there. You could have other people help QA the product, depending on what kind of thing it is. I mean, they probably wouldn't be able to write unit tests if they're not developers, but they could poke around at it. Yeah. I mean, another thing is automation is your friend here.

You know, as much of these jobs as you can automate, the better. So if you're wrestling with tools that are slow and manual, get rid of those tools. you just can't afford to have tools that slow you down if you have a very long like regression checklist for testing that you do right before every release like figure out a way to automate that that'll be time very well spent yeah i like it well have we answered the question well almost there is there is one more thing you could lean into just embrace this situation you know you're currently only wearing five or six hats but why not take on more like hr we already mentioned it

department maybe you could be the board of directors too i mean yeah you you basically become a solo founder of the company at that point except you just have a boss still somehow until you take that job yeah we didn't mention that but hopefully your boss is aware of the situation and is not comparing your product owner output to a full-time product owner yeah etc like they they have chosen to go with someone that will move very slowly because they're doing a lot of things at once right despite all the things i said earlier about how you can move faster if you don't have all the communication overhead it'll go slower than if there's more people devoted to this i think and they just have to be fine with

that all right now i think it's answered all right shall we move on to our next question yes yes okay i'll read this one it says hey love the show my question is this i work in a small startup about a year ago our team documented what our git workflow would look like we agreed on things like rebasing instead of merging to master and never squashing our commits into one that sort of thing one of our developers is now making a fuss about following these rules and constantly does their own thing after speaking to them about it they shut me down and said it is up to the individual developer to decide how they use these tools there have been some heated discussion on merge requests with this person telling our senior devs that they don't want to hear their opinions

this person started at the company six months before me and i am only a junior engineer myself so i'm not sure if there really is anything i can do i have been at the company for two years i have offered to help them learn how to use git the way our team agreed but was told quote no thanks i'll do it my way what is the best way to navigate this situation is this something i should escalate to my manager or should i just get over it thanks for the help can't wait to here you rip this one apart is that in a good way or bad way i don't know like the way i rip apart a slice of pizza out of the pizza yeah huh i hope we don't have a reputation for completely trashing our question askers heated discussions on merge requests with this person telling our

senior devs that they don't want to hear their opinions so i think you have a jerk problem masquerading as a git problem it sounds like this person is either like a very git specific jerk or or just hard to work with in general okay bad news i guess the problem is worse than you thought you can't i mean if you if you switch to like mercurial then it's not like the problem would go away it'll bubble up in some other fashion so if you're saying if you unmask the the jerk masquerading as a git problem then you'll just have a new problem it's like another mask waiting right underneath the git mask yeah they shut me down and said it's up to the individual developer to decide how they use these tools that is weird to me yeah there's a trade-off between consistency

and freedom of self-expression and saying it's up to the individual developer to decide how they use these tools is like sort of true but also sort of not true i mean you work on a team and the company pays you money to work on the team it's not like you and your decisions have effects outside of you so if i decided suddenly i'm gonna rewrite everything in closure like and then i just tell people what's my decision because i'm doing it it's up to developers to learn to decide how they're gonna use yeah yeah i've decided it's up to me it ignores the cost it has and maybe the cost of merge versus rebase is smaller than that but it's still like presumably there's some collective decision that was made of of why this is important and they're just saying like nah i

don't think so it's a free country a free country free country argument classic freedom of speech you just whip out a whip out a pocket constitution and shove it in their face yeah just pick an amendment that nobody knows i don't even know if they're in the u.s or not i don't know the doesn't matter 18th amendment always remember the 18th amendment freedom of get rebase i don't i don't know if there is one oh that's prohibition that's a big one oh nice that establishes prohibition the one that got overturned yeah okay you picked a great one for this example yeah freedom just say freedom of speech like the 18th amendment says and throw them off probably no one will challenge you yeah i still can't believe that happened

prohibition yeah looking back it's just i can't believe it can you imagine that today i can't even imagine someone trying it but remember this is the same generation that thought eugenics might be a good idea too so you know yeah there were some ideas floating around yeah yeah okay other weird things this person started six months before me and you've been here for two years and they talked about the team decided a year ago i'm just thinking that through the timeline the team decided a year ago about what the workflow would look like so it's not a new decision to them it's not like they came into the team and were like this thing you decided without me is stupid like they were around for that presumably yeah they were there actually i wonder how that

meeting went i wonder if they just like tacitly agreed in silence yeah and then later they were like i'm gonna i'm gonna make this team a living nightmare yeah i'll show them all it does so heated discussion telling our senior devs they don't want to hear their opinions shut me down set us up to the individual developer yeah i feel like the the cost here is maybe not that we have merge commits now when this developer does stuff i don't know maybe that's a huge deal in your process i don't know what it is but it seems like that's not the biggest deal the cost is like it's gonna make it hard to work together as a team with this person if they're hard to work with yep and this is one manifestation of the cost we still haven't given any advice on what to do about it oh we'll get

there don't you worry hmm what do you think dave well okay so first of all there is obviously a lack of a cultural norm in this company that developers can point to to say no we're not going to debate this anymore and you're going to get on board that's just missing you know my company has a one of our cultural items is about when you disagree with a group but the group wants to move forward anyway that you get on board with it there's obviously the other side of that which is standing up for what you believe in and what you think is right which is also part of our culture but once the group forms a consensus or even a you know a good enough consensus you get on board because not getting on board will just trash the idea so like even even if this git

workflow is the best thing ever if you have one person that's constantly putting up friction and causing arguments about it suddenly that any value that could have come from that workflow is completely negated by this person's behavior yeah so it sounds like there might be some missing cultural elements here or at least some norm that is overt enough that a team could point to it and say you're not complying with our culture of x which is you know once we get on board with an idea we or rather once we agree on an idea we all get on board i don't know how i would do this as appear i've seen situations where the team has agreed to some practice and then someone on the team is not holding up to that practice or not doing it and a way i've seen this handled is

instead of saying like hey do the thing step in line someone asks you're not doing the thing do you feel like we need to change our practice if so then let's have a discussion about that but until then do the thing like you're saying if you disagree it's kind of the opposite of what you're saying dave like keep disagreeing forever but like don't just do the thing like let's talk change the practice yeah don't just go your own way separately because you disagree like if you want to make a change then propose the change instead of just right individually not follow it but i think in this case this developer is like like no i don't i don't want to make a big discussion and i and i don't want to open this box back up again i just don't think it matters

that we have consensus on this point. And I don't care if you work differently, I'm going to work my way and you work your way and it won't make a difference. And actually, I'm just going to take that developer side for the moment. Maybe that's right. Maybe it doesn't make a big difference.

And maybe the burden is on the team to say that the cost of inconsistency here is actually something that's material enough to warrant enforced consistency. I feel like some people have really strong feelings about kit workflows that I have not seen reflected in my day-to-day reality like very strong opinions about how you commit and what your commit messages say and like i don't know what tools you use and just like way stronger

than i've seen warranted for the amount of difference it makes to a development workflow this is for i guess normal sized projects not like the kernel or these giant things that have very specific constraints but i mean maybe it's possible that they are trying to over specify because there are some people who have very strong feelings about what I would call like aesthetics, the aesthetics of Git. Yes.

Our commit history needs to be linear because it seems nice, even though like part of the point of Git is it has these just outrageous, complicated commit histories. It's true. That's true. Outrageous is the right word.

Yeah. That's a good point. Like I think some workflows, like some teams have workflows that depend on consistent Git history. for example like let's say that your deployment process is actually managed by git and when you want to roll back a change you have to do some kind of git revert or something and if one developer does it differently than everyone else then the ops team who does these deploys and rollbacks

might think they're rolling back something but actually they're not because some developer didn't follow the process yeah like that would be a material cost right yeah if if there is a strong material cost i think this is easier it's you can just say hey if you do this it will have this concrete negative effect if the effect is just like conflict then that's harder to talk through right it's harder to solve but if you do have like a very concrete justification for why it's done this way then i think it's worth bringing up they mentioned escalating to my manager what do you think about that okay so now we're getting into what do i do as a junior developer with this with this developer okay based on the discussion that there's already

been heated discussion on merge requests which means that these comments are permanent and readable by the managers guaranteed your manager already knows because very very unlikely that everyone just sits on their hands and doesn't doesn't mention this to the management i don't know maybe they're not technical maybe not but i mean if it has gotten so heated that you who didn't even participate in the discussion can sense the heat then the people who did participate in the discussion probably felt the heat even more and if there's been multiple people then there's a good chance your manager is already aware so you're saying don't escalate because they already know well i haven't actually said anything yet but i am what i think is as a junior

developer this is probably too far above your pay grade to really jump into i would approach this very gingerly as a junior developer i would probably go to management and say management what is your opinion on the kinds of behaviors that might be negative or harmful at what point do they rise to the level of needing to be reported to management to actually get resolved versus, eh, just, you know, whatever. That's human nature. There's always going to be some conflict. And I would ask that kind of general question,

and they might be like, oh, is this about Bob and the Git workflow? Yeah, I can just see this conflict between, like, we all agreed to do this thing, and there's this one person who's not doing it. I think the larger problem here is that it makes it harder to decide and do things as a team

if you have this feeling that it doesn't matter what we decide we're just not going to do it yeah it's almost like process debt oh where you have these leftover processes that sort of exist in some form but aren't really followed and it makes it harder to create or follow good processes because it it muddies the waters a little bit so yeah i'm in favor of either ripping things out or doing them not like half almost doing them yeah it's like it's like an alarm that fires and everyone's like oh just ignore that one yeah yeah oh we wrote this document about our git workflow but we don't do it because this one person didn't so like what about this other document about communication styles or i

don't know this is a really good call out like it's kind of like a precedent where if all it takes is one person to just be annoyed by it and not follow the process to like by default discard the process then that's that's not a good precedent so if you're the junior developer Dave would you say anything about it to the the git stickler I would probably sit on this for a while before I said anything about it and maybe you already have but I mean this is just not something as a junior developer this is not something I'm going to wade into if I was the senior like one of the most senior engineers on this team I would absolutely engage this developer and say look we need to come to an agreement here either you feel strongly enough that we shouldn't

be doing this as a team or we just love for you to come with us and all get on board so that we are all doing the same process here if there's some reason not to do this we'd love to hear about it but otherwise would you just go along with us for this one you know if it just do it as a favor you know so i would try to resolve that and i would go directly i probably would not involve management on this one yeah but as a junior developer i'm probably just going to sit this one out and let other folks deal with it yeah that's a good point they are i mean they already did try to bring it up a few times it sounds like they talked to the person yeah exactly so i feel like you've sort of done your job but i think it's worth escalating at this point i know

you said that your manager probably already knows, but I would still bring it up because even if they know, maybe hearing it from you gives them more detail and more context or pushes them to do something about it if they haven't done anything yet, or maybe they are doing something about it. Like, I don't know. I think it's worth bringing up. Yeah, maybe. I'm kind of on the fence on that one. I don't know. I think this is a big deal. I just don't think it's your big deal. Yeah. And I know, Jameson, you are currently in management and I think these kinds of data points are really important to you as a manager. And I know you're open to hearing the input from your developers on other developers too like that's great managers love that but it also kind

of puts the junior developer at a kind of a risky dangerous spot where it's like uh how deep am i gonna have to go on this like if you're gonna do like if you're gonna terminate this person because they won't you know maybe this is just one of many things they're doing wrong am i gonna have to be a witness so to speak you know or what yeah so i don't know it's uncomfortable and as a junior developer it's kind of like i don't know i guess wow i'm really wishy-washy on this one now well question 100 definitively answered all right where can people go if they want to ask their own question and get a wishy-washy answer maybe possibly to softskills.audio there's a button on there that

will take you to a form where you can ask a question which we will answer eventually someday thank you to folks who are sending in questions we appreciate it please keep doing it unless there's just like no soft skills issues anymore but then you can make up stuff there's a lot of issues that could happen from fiction please share the show with people that you know we we love it when we get new listeners and hopefully it helps someone as well we like to think it's not just for our benefit but also their benefit i have nothing else i don't know anything else you want to say dave nope okay but wishy-washy end it was a pretty definitive end really well yeah it'll turn off and then it will be the end. All right. See you next week.