Soft Skills Engineering - Episode 231: Freedom for me not for thee and optimizing for growth

Episode Date: October 12, 2020

In this episode, Dave and Jamison answer these questions: Questions Hey Dave & Jamison, I have a problem with a more senior engineer in my project, I cannot really predict or follow his thought process. They introduced best practices about organizing code, Git branching, software versioning, etc. to the project. Which is great, because I like well-defined processes. And I followed those processes happily. Now, there are some occasions where the senior engineer violates one of the processes. When they do that I ask why, then they give me the reason and I nod because I think that make sense. Fast forward a little, and I also choose to violate the process the same way, for the same reasons. During the code review, the senior engineer rejects my approach because it “does not make sense”. SurprisedPikachu.jpg I tried a few times to challenge them in these situations but more often than not they either stood their ground or gave the “agree-to-disagree” nod which demoralizes me. So now, I’m inclined to just follow what they say if this situation happens. I understand that there is some nuance for a certain thing to go a certain way, but when this happens I am always left puzzled and spend time re-calibrating the idea/approach. What is the best way(s) to deal with these kind of people? Anyway, love the show and keep up with the good work! Do you think that a job that helps you constantly grow is more important than a job that promises titles?

It takes more than being filled with regret for spending $80 million in Bitcoin on a $20 pizza in 2013 to be a great software engineer. This is episode 231 of the Soft Skills Engineering podcast. I'm your host, Jameson Dance. I'm your host and never Bitcoin investor, Dave Smith. Soft Skills Engineering is a weekly advice show where we talk about the non-technical parts of being a software developer and just speculate about what might have been if we had a time machine we often give time machine related investing advice yeah that's true there's probably some simulation someone has done to think okay say time travel exists but everyone has it how would you build a high frequency trading platform then getting your fiber closer to the exchange is

no longer good enough yeah goldman sachs has that time machine too they already bought up apple in 1980 yeah turns out apple only has one investor and it's this guy in a basement in ohio yeah uh that was kind of a weird couple years when my tech friends were millionaires briefly and then not anymore because they spent 20 bucks on bitcoin a couple years prior yeah well yeah i knew some people that got way into crypto in the very early days when i so i still don't understand it but i didn't understand it and thought it was dumb and now i don't understand it i just think it's bad for the environment gpus cranking out the heat yeah i heard someone describe cryptocurrency as using your car to solve sudoku puzzles that you can buy heroin with like it spits out co2

oh my gosh that is that is accurate that's like it's like an accurate answer like an accurate analogy that tells you nothing about what it actually is yeah well i know the same about it as i did before i learned that analogy i think this is my old man yells at a cloud moment is oh me just shaking my fist at bitcoin and saying harumph saying i wish i would have bought yeah or mind i mean i yeah i had some friends who got pretty into mining when it yeah was fun and interesting and possible as a non-super mega corp with your own highly optimized data center anyways that's not what this show is about no but boy did i do i wish it was in about 2014 do you want to talk about our our exciting

news dave yeah this episode is sponsored by monday.com which is a visual teamwork platform and we'll tell you more about monday.com later thank you to them i also want to thank our patrons thank you to these folks who are supporting the show at a level where we shout them out every single week thank you to oladapo fadeh karen sveinsen ragnar hartesen alexander microconfig.io nick travis sanders evgeny sladkowski dennis bogdanov braden canes steven arman lee john grant luke bayless philip john basile the agile ventures charity sean and vin lock thank you to folks who have supported us in the past if you would like to join this group you can go to soft skills.audio click support us on patreon put in the stuff that they ask you and then wait for that

sweet sweet slack team invite to roll on in where you can join exciting conversations and write down haikus like my boss quit today should i quit today too or am i the boss now i love that one that is such a good one it's a good group that i am regularly entertained by yeah me too all right shall i read our first question please this one comes from an anonymous listener who says hey david jameson i have a problem with a more senior engineer in my project i cannot really predict or follow their thought process they introduce best practices about organizing code get branching software versioning etc to the project which is great because i like well-defined processes and I follow these processes happily. Now, there are some occasions where this engineer violates one

of those processes. When they do that, I ask why, then they give me the reason, and I nod because I think that makes sense. But fast forward a little bit, and I also choose to violate the process the same way for the same reasons. During the code review, the senior engineer rejects my approach because, quote, it does not make sense. Surprised Pikachu.jpg. i love these verbal emojis and verbal file names oh man it's great okay i tried a few times to challenge them in these situations but more often than not they either stood their ground or gave the quote agree to disagree nod which demoralizes me i know that nod okay so now i'm inclined to just follow what they say if the situation happens i understand that there is some nuance for a

certain thing to go a certain way but when this happens i am always left puzzled and spending time recalibrating the idea and approach what is the best way to deal with these kind of people anyway love the show and keep up the good work thank you so i feel like a lot of this comes down to the difference between having experience that allows you to know what the right thing to do is and being good at teaching other people because it's possible they could just be totally wrong too you know and like bad and nonsensical and but it's also possible that they have some kind of internal rules that they are following or or heuristics that they are following that make sense to them and they just haven't articulated them to you in a way that makes sense to you or that that

completely covers all the cases and maybe that's because the heuristics are actually an extremely complex neural network. Which is, did I decide this or not? Yeah. I feel like I've seen this pop up in my own career where I've tried to teach someone something and then they go off and do that thing and they come back and I say, but no, no, no, not like that. Yeah. They're like, but you said to do the thing. And it turns out that there's some circumstance that's different that i didn't call out explicitly or some reason for why i think it fit in this other situation but not in this one but i also sometimes weigh that against how painful it is to tell someone to throw a thing away and then go back and do it in a different way sometimes i say like sure the code

got worse but at least i won't get yelled at at least i won't hurt anyone's feelings exactly but but the feelings are better and that's really the output of this team is unhurt feelings code quality low feelings quality high yep i'm tempted to reach for a metaphor here that i think could be misinterpreted so let me just start out by saying i don't think all software engineers are children okay so just with that okay with that backdrop i'm going to tell you a metaphor when i ask my children to sweep the floor they pick up a broom and to them the instruction to sweep the floor is move the broom around near the floor for some period of time until my dad is satisfied like that you know and it's like to me the underlying requirement was no i want the floor

to be clean and in fact the method of cleaning doesn't matter to me like you could reach down with your lips and suck the crumbs off the floor i don't care i said that's what my son does can he come to my house because i think i could use that he's a little roomba baby so you know i think sometimes when we give instructions it's not clear to the receiver of those instructions what really we're going for you know like i've said sweep the floor but i don't care about the method and so they're like okay well move these bristles around for a while and i'm good to go the dust the dust is in a different spot yeah and i i've literally had to tell them that so many times like hey when i ask you to sweep the floor the objective is to get the floor

clean not just walk around with a broom for a while yeah so and i i just wonder if that's what's going on here is the the senior engineer has explained the processes but has not explained the governing principles behind the processes which i sometimes call tenets where they've got some mental tenets maybe even subconscious ones that they feel override all the processes i think that's a smarter way of saying what i was trying to say where there's something they didn't communicate underneath that's motivating them and and to you it looks the same but to them the there's there's deeper stuff going on here i've seen this happen oh let's see there's an example of quite a while ago where there was a disagreement about which part of the architecture

to transform some data and the core of the disagreement was this belief i had that like you transform it as soon as it comes in like at the outside so that once it's inside the system it's always in the right format and there was this core underlying belief i had that i don't know if that's really backed up but that was the motivator for all my reasoning and once i figured out that's why i was that's why we were disagreeing is because i i was assuming like well of course you want to transform the data as soon as it comes into the system and they were like had some other assumption they were working under then we were able to progress progress towards just a beautiful agreement where no feelings were hurt and the code quality is still high uh yeah they did it my way

my feelings were super high nice but to them they felt like they had been trying to do a thing that made sense in in their engineering experience i guess so i agree with you that's what i'm saying well that's interesting sorry i just i actually stopped listening when you said it sounds like you said something but smarter than me and i just have been sitting back relishing that for the last few minutes just basking in it uh well that was the good part of it anyways i guess what i'm seeing here and maybe it's just not in the question is i don't see an explanation of what the senior engineer's reasoning was for disagreeing i i see the question asker saying i thought i was in the similar situation so i tried to do the same thing and it seems like the senior

engineer just said uh-uh i'm sure there was more to it than that though and if i were the question asker i would dig into it and say okay i think i'm in the same situation for these reasons and this is what you did last time why why do you feel like that is not appropriate here but how do you say that without coming across as super like confrontational i don't know i mean i don't know that it has to be confrontational i i don't know that you have to disguise it i mean if that's really what you're doing you're trying to learn from their experience and that seems flattering right like yeah you are the senior wise engineer and taught me this thing that i thought was was appropriate here and can you help me understand why that is incorrect or what's going on here

that makes it different that feels flattering so you're saying grovel a little if you just call them a hypocrite and say listen idiot like caught you because last time you did this thing now you're saying do this thing and i knew you were a fraud then yes that won't work that won't work but if you grovel a little you know oh why senior engineer you're clearly operating on a higher plane where the rules are more clear to you but they are not clear to us underlings please enlighten us shower down your wisdom descend from your throne yes i know that it hurts you to walk on the dirt that we live in but please come we will avert our eyes to not sully your hoodie with our foul

un-senior gaze un-senior we've made offerings of La Croix and Costco snacks oh my gosh so alright

so far we've been operating under the assumption that the senior engineer is acting in good faith and not just being lazy and a bad explainer and that there is more to this situation potentially than what the less senior engineer is able to comprehend. But let's, I would say, let's just assume for the moment that the senior engineer really is just being lazy and is saying, I don't like this process because it takes extra keystrokes and I don't want to do it. I'll tell you about a situation similar to this where I've been lazy, where this happened a few jobs ago, where there was a pretty junior developer

who really wanted guidance and asked me for some feedback on a solution they were thinking of for a problem and i was pretty busy and kind of sick of helping them so i just said that seems fine and then they built it and then submitted it and i was like oh this is all wrong like it's wrong for this reason and you got to do it this way and and their complaint was but you said it was fine before and i don't think i told them this but the reason was like well yeah because i wasn't paying attention before i just wanted you to go away so i could do my work but now i'm actually paying attention okay hold on so this this is like the social equivalent of technical debt you took on some debt right you just you just kicked it you kicked it down the road a little

and now i did yeah i was like future jameson will clean this up yeah i love that guy he cleans up all my messes yeah perfect yeah so it could be like i mean maybe they were just cutting corners last time because they were lazy maybe and it's easier to cut corners in a way it's easier to hold other people accountable sometimes than yourself interesting is that like for me if you agree to a coding standard maybe i'm revealing too much about myself let's say for example hypothetically there was a very rigorous deploy process that required many steps of approval and it was important to follow that and hypothetically someone named james's son really wanted to deploy without following that process even though james's son really wanted

the team to follow that process and just and and defined that process perhaps let's i mean hypothetically well not don't don't blame james's son too much for the process james's son is trying their best to improve the process but some of the process has been foisted upon james's son yeah it was way easier for james's son to say yolo if this screws up i get fired versus if i let someone else screw up they get in trouble so the incentives have been different in their case in that hypothetical situation okay so you're saying you're just so lazy yeah i guess what i'm saying is sometimes it's easier to justify to yourself why you don't have to follow all these extra rules that you've agreed to are important or valuable for some reason because you know all

the secret context of like yeah but there's this tight deadline or this will be the consequence if it has to go through this thing or but if you see someone else do a thing it's easier to say oh we agreed to this standard and like you don't feel the the pain of the potential consequences as much potentially interesting so you have you're completely devoid of empathy is what you're saying sorry i don't know why i don't know why i keep well usually these terrible things about you well hey it's not me it's james's son oh of course right everybody hates that guy all right so so there's a chance that this senior engineer is lazy there's a chance that you're missing some nuance and it's your job to figure it out through crucial question asking that may

involve a light degree of groveling have i summarized correctly i think so yeah if you feel like they're being lazy earlier and just kind of rubber stamping your stuff then it's sort of on you to make it important enough to get it on their roadmap okay like you you can pull feedback earlier into the process yeah because they say during code review the senior engineer rejects my approach like you could get feedback on that approach earlier before code review which is a fairly expensive time to get feedback that is don't do it this way right the way that you spent two weeks doing exactly yeah yeah it's easier to say i would like to do it this way and draw a little diagram for half an hour and then here it does not make sense yep have we answered the

question i think so good luck good luck now i'm not going to name any names but we have a time honored tradition on this show of complaining about hard-to-use task trackers. However, things are changing in this world. Have you heard about monday.com? Yeah, I've used monday.com. It's a work OS that powers teams to run processes, projects, and build custom workflows in one digital workspace. It's pretty cool. It's very modern. I heard you can actually develop apps that run on monday.com now. It's super customizable. That's right. And monday.com is hosting an app competition for developers. They're giving away three Teslas and a bunch of other prizes to the winners i am recruiting a team to implement doom in monday.com and you can ride in my tesla if we

win this sounds like a good chance to get in early on a growing platform currently there are over a hundred thousand teams that use monday.com for their daily work and your app could be in front of them to sign up go to monday.com soft skills you can find the dates and the rules of the competition there i suggest you check it out today so you don't miss out go to monday.com soft skills i will read the next question this is a short one do you think that a job that helps you constantly grow is more important than a job that promises titles hmm titles i assume promises titles means that maybe you get hired somewhere that gives you a fancy title super mega staff charizard or whatever i don't know what was is charmelian is that the final one which one is

the last one of the pokemon oh you just said pokemon i was like i have no idea what you're talking about i think charizard is the last one i don't know anyways very relevant to the podcast yeah so say you get a fancy title but the work is not really pushing you in a new direction or i the classic trade-off is like go work at a startup where the title is person who works at a startup right but you kind of just do everything and get all these challenges thrown at you and and growth work really hard and learn a bunch and grow and then you leave as person who worked at a startup right junior software associate yeah what do you think oh boy my perspective on this has changed so much in the last four or five years i think i spent probably the first

10 years of my career thinking titles are super dumb and just do awesome stuff and everything will be fine yeah titles are things for like the man people with suits and ties and squares and just beam counters and we just sling code i also thought titles were for people who were egotistical and self-obsessed like ladder climbing yeah like i care more about you recognizing my greatness than actually being great huh that kind of mentality okay yeah i don't know that i had that but i definitely had the the one that i described of like titles are just kind of hokey it's like it's uncool to care about your title yeah because it's just distraction from the really important stuff it's like caring about the brand of jeans that you wear some people care

a lot about the brand of jeans that they wear i know just like some people care a lot about titles are you saying okay so in this analogy the the brand of the jeans that you're wearing is the title but the growth here is going to be like how beefy and powerful your thighs are and like yeah those beefy powerful thighs in a big old pair of lee pipes or jinko jeans they'll still look great even if your title is associate turner offer honor but you can produce very awesome code or build great things so you're saying good legs look good in any brand of jeans yep lee pipes flatter the the figure if you're if you can squat enough weight okay your thighs are three feet wide

so that's a little weird but i think i understand where the where the analogy is trying to take us so to be clear we're just to recap we are describing how i used to feel yes okay got it well i don't know i think i just wanted to make that analogy it's wandered far away from any meaning or relationship to reality i'm sure that there's nowhere we could take that analogy that wouldn't be great but we should probably set it aside yeah so bottom line i think jameson you and i both kind of had a negative perception of titles and the pursuit of title increase and i think that's somewhat justified in some cases i actually remember a day when a co-worker of mine changed their title to senior

software developer on linkedin and i was like what a nerd i remember it because i feel really stupid now but and and they were totally i mean they deserved it it was just like to my dumb brain the idea that anyone would care enough to make their title anything real on linkedin was like yeah show their their heart was in the wrong place right now okay so now this is a nuanced topic but so how would you say that your mindset has shifted on this subject in the last few years basically as much as it can so you're all about the jeans and not about anything about the thick thighs anymore yeah the i mean the right jeans can have a lot of padding in them and make your thighs look thick how do you think batman's suit flatters his figure that's true that's true it's

mostly foam and if you have a lot of space you can pack a lot of money in cash into the into the void in your jeans yeah so one thing i didn't realize is that titles can signal importance to people and i had a lot of built-in signals of like this person belongs as a software developer already like for better for worse lots of software developers are white dudes i'm white dude so i fit in with that group there's like a certain i don't know i like video games and yeah it's even even a subgroup of that group is you know you're kind of nerdy you like you like fantasy novels yeah like there there's some kind of classical yeah some classical markers that i fit in several ways so i never felt really out of place or like i had to prove that i belonged i just felt like yeah i mean

yeah i can i can do this work and everybody should just know that i can do the work which is why you were able to get by for several years with the title of archduke of computering exactly yeah because because there was this underlying assumption that like well yeah that's he can make fun of this because he probably knows stuff about computers but i have realized that that is definitely not true of everybody that they do not get this built-in benefit of the doubt or that they just might work in environments where like titles are important to collaborating with other people to signal what they know and what they're responsible for and i just wasn't at all in that environment and assume no one else in the world was either and if they were they deserve what

they get yeah that's what they get for being a bunch of dorks so what i think just to be really specific about that last point jameson and i both joined huge companies in the last four years and i have come to appreciate the value of both title and level so like job family and level within that family when i i work with literally hundreds of people every month and i just can't keep track of who is responsible for what on that many teams you know like who's the person who knows about x y and z it's like i need an entry point into teams that i don't have a long-standing relationship with so i look for the person with the right title on that team as a guide path as a like a landing light on a runway to guide me to the right place to talk to the right people

i just if i had to like spend six months building a relationship with every member of every team i interface with i would never be able to build anything because i work in such a complex large environment yeah i don't think it's a coincidence that when we both joined large megacorps our ideas about titles changed and i think some of that is dependent on the situation but i think i just have more understanding of of i mean especially if you're from a marginalized group like you you might be discounted just uh just because of who you are and a title can help counteract that where if you're i don't know a senior engineer already then that might kind of break up someone's implicit bias from triggering or help you get a little bit more respect or a little bit more

support in some ways. While I agree with everything you've said so far, I do want to point out though that there is also this other problem because people have chased titles so much in our industry that, and we've mentioned this a lot on the show, but the same title at two different companies can mean vastly different things. And like, I'll just give an example. I was browsing a candidate's LinkedIn profile the other day who's been in the software industry for a good number of years. but they literally had senior software engineer listed as their title at a job that they were working at while attending university. And they had no prior experience. It was like their first job, not even out of college. And they already are calling themselves senior software engineer.

So it's kind of like kind of the devil's advocate side of what we've said so far is that there has been so much title inflation and just random title assignment and non-agreement on what titles mean that it almost doesn't matter anymore in many cases. That's the opposite of what you just said. it is in my experience it matters at my large company exactly and there is there is agreement yeah there's agreement broadly and there is some amount of vetting where like someone would have to be pretty exceptional to get the title of senior software engineer for their first software job like they would have to meet a certain standard that i would kind of trust that that fit yes and at my company that that's just not possible because there's no way that you have had the

experience to meet the requirements to have that title at my company right out of college or for your first job even if you were brilliant you just couldn't get it because you would not have had the opportunity so i guess it's it's worth pointing out that titles are extremely important in large organizations where there's broad agreement and then the value of a title i think decreases once you start crossing into other domains like other companies so we've sort of wandered far field from the original question which is is it more important to try to grow or to optimize for a title that could be either within your same job like do you try to get better at your job do you try and get a promotion or while you're doing a job search do you pick a job that gives you the

fancier title right right i would say that in in a good healthy environment let's let's say you're in a company and you want to decide whether to go after the title or go after growth i think that like i said good healthy company you should go after the growth and the title will follow anyway and i just i want to caveat that like crazy because i think many many places are not healthy in that way but if you find yourself if you're lucky enough to find yourself in that kind of a situation i would say growth first title comes second and if you strive for a title in a healthy environment i think it can backfire on you what do you mean i mean i've seen people who get so promotion obsessed that they do things that actually undercut their own success. For example,

they can like kind of steal work from other team members or like hoard certain tasks because they know that it'll look good in their portfolio and they don't collaborate as much or they hide information. These are very toxic negative behaviors and I've seen that done in the pursuit of title or promotion. So I want to believe that you've seen it done and fail miserably. Yes. But my cynicism is saying you've seen it done and like it just works and there just makes life worse for other people i've first of all i've only seen it done in a couple of instances and out of hundreds of observations and in those cases it did fail so i don't know now but now popping out going up to like a bigger context of i'm looking at jobs at different companies or i'm comparing two jobs that

have one that has a title of let's say principal engineer and one that has a title of just engineer you know which one should you go for all else being equal i would probably go after the one with the fancier title yeah yeah the problem is that no job is no two jobs are equal there's this n-dimensional space that you're comparing them on about like field and pay and colleagues and technology and work-life balance and title and all that other stuff do you like how all my answers only work in theory yeah i think in a way if i were interested in growth i would try to optimize for breadth of impact or breadth of responsibility because like you said titles can be so wildly different at different companies you can be a director at one company and that means you like

are on a team by yourself and do everything and you can be a i don't know team lead on another team and your team is like 15 people i mean wildly different i direct my code that i write to do things yeah exactly so if if i saw a title on a resume i think the first thing i would try to understand is but how how big was your impact or how wide was your scope of responsibility and i try and calibrate that in my head and kind of like strip away the title malarkey mm-hmm so hopefully those correlate in some way and it can be easier to say like if you want to grow your breadth of impact it can be easier if you have titles in your past that indicate you've been growing in that way but you can also pursue that without a title change and without a promotion

and then that sort of like builds up as credit and then if you do finally change jobs or get promoted you sort of cash it all in to say look i have all this experience even though this wasn't my title, I ran all these projects and whatever the case is, and you kind of turn it into a title. Exactly. And you're going to have to do that anyway, especially at the more senior levels, because there's such a lack of clarity on what a title even means for every company, that you're going to be explaining yourself and what your job duties look like regardless. And I've grown very skeptical of titles when I see them. And so I just find myself asking the candidate anyway, to try to get a sense for their breadth and scope of impact.

Yeah, that's a really good point. I sort of believe titles within my company, but I do not believe titles outside of my company. But the other side of that argument is if you have a recruiter that's looking for directors or looking for only senior engineers, then you're going to show up in the search results unless you don't have that title. Absolutely.

So, I mean, there's that aspect as well. This is a complicated question, right? Yeah, I don't know. Maybe 23-year-old Jameson was right and the really important thing in life is to be an Archduke of Computering. There's one thing that's for sure is no recruiter is searching for Archduke of Computering

and if they do and they find you, should definitely take that job i did not get any linkedin spam well and that's another good point is the kinds of opportunities i get on linkedin are just so different depending on the title that i have like you know my current title is actually kind of a silly title like archduke of computering but it's something else and my linkedin messages have gone way down but when it was senior software engineer and when it was director it was just non-stop linkedin messages so it definitely changes the kind of opportunities that will show up at your door talking cylinder builder i forgot about that i mean it's accurate but is it precise yeah it's 100 precise totally repeatable every

time every time i measure it it's right it's like the same number it's perfect then all right i think we've answered the question i think so too good luck it's a very nuanced field and i don't even think we've given like a concrete answer on one or other side of this it depends gotta go all right jamies and where can people go if they want to ask us questions and get completely nonsensical abstract theoretical only academic answers if you want the hottest tips on gene brand versus thigh beefiness go to softskills.audio and click ask a question and then we will tell you whether to buy pants or do squats all right we'll catch you next week

Thank you.