Soft Skills Engineering - Episode 363: Future impact of tech stacks and async communication

Episode Date: July 3, 2023

In this episode, Dave and Jamison answer these questions: Listener Thor asks, Is there a chance the tech stack I choose throughout my career will hurt my chances to shift direction towards project leading/managing in the future? Say, I do mostly frontend, will this affect the way people see my broader understanding of projects etc. compared to people in roles such as architect? Listener Travis asks, My company is starting to expand across time zones. The majority of the company is based in one time zone and a handful of employees are spread across others. I want to emphasize the importance of asynchronous communication. I have begun to feel like I need to respond ASAP to Slack messages instead of when it is convenient. If we were to say Slack is used for asynchronous communication, is asking the team to use Signal or even text appropriate for a quicker response? What is a good way to handle reaching out to team members in cases where a response is needed more immediately? Show Notes https://m.signalvnoise.com/is-group-chat-making-you-sweat/

it takes more than waiting for an hour for a build to finish only to realize you never actually started the build to be a great engineer this is episode 363 of the soft skills engineering podcast and i'm your host jameson dance i'm your host dave smith soft skills engineering is a weekly advice show about all the non-technical things things that go into the technical field of software development and i have done this before you're like boy this build is taking a little longer than usual i'm sure i've also done it where i thought i started it and i didn't and then i looked and saw nothing was running and assumed it finished yeah like boy what is what a speedy build i must have hit enter with a particular amount of vigor today yes

really got that computer going oh the ways computer the ways we mislead ourselves about what computers actually did dave do you want to read our our thank our patrons yes the illustrious crew weekly shout outs to trash panda the computer science book.com the re-elect jameson dance boogie brigade the re-elect jameson dance committee santa hopar noah frazier lowe kent c dodds jenny kim owen shardle benjamin earl if you would like to join this illustrious crew go to soft skills I didn't click the support us on Patreon button. Craig Motlin, I Love Mavis, The Stochastic Parrot, Alice Jost, Tuscarawas, Ohio,

patreon.com.au, we're hiring. Ira Chan, Monkey Face Emoji, Jonathan King, Webtau, Awesome End-to-End Testing, Oladapafadi, The Re-elect, Jameson Dance Committee, Nick Hathaway, Travis Sanders, Braden Keynes, John Grant, Cody, Please Hire, Jameson Sale, Nick Cantor, and Philip Jambasil. If you truly would like to join this illustrious crew,

go to softskills.audio and click the support us on Patreon button where if you contribute enough dollars in whatever currency you want that are translatable to dollars we shall add you to the illustrious crew and read your name or whatever you can fit in the patreon name field every week on the show and any dollar amount will get you access to our slack community where you can enjoy the musings and solid advice from fellow listeners who i just love hearing from it's a good bunch i'm honored to associate with them all righty should i read our first question hit it this

is from a listener named Thor, who asks, is there a chance the tech stack I choose throughout my career will hurt my chances to shift directions towards product leading or managing in the future? Say, for example, I do mostly front end. Will this affect the way people see my broader understanding of projects compared to people in roles such as architect? Ah, good question. this is kind of the a special case of the specialization specialist versus generalist question what are the repercussions i think the tech stack that you choose or don't choose sometimes you it's chosen for you by the job that you choose biases you towards some opportunities or biases is the wrong word makes you more qualified for some opportunities and and

less qualified for others there's no way to avoid that just by virtue of doing something you're not doing a bunch of other things so if you do a lot of yeah most of the most other things actually that's fair it's a really long list but i i don't think i think it's hard to predict what you'll want to do in the future and make your tech stack choices based on that unless you have a really strong sense of it already so i think i'm saying it kind of doesn't matter because it's going to happen no matter what if you if you start up your career in embedded systems you're probably going to keep doing more embedded system stuff because that's where you started and maybe there's some opportunities in distributed systems that are going to be less out of reach yeah yeah

more out of reach but that's that's just how the world works i don't know so i i'm pretty sure i would have had some really good advice on this one but it said tech stack and i thought i thought it said how should i choose the tech stock and uh i've been like i've actually been reading some investor reports and shareholder minutes and things so if my advice furiously for this question if my advice sounds weird that's because i've been focusing on the wrong thing time to talk about ebitda yes pick the front-end framework with the best earnings to valuation ratio isn't that a thing the pe price to earnings ratio yeah that's the one as you can see i've not been No, I'm serious. I'm like well-prepared for text doc selection here.

Wait, really? No. Okay. But I think it's a good, it's actually a good narrative, which is most of the time when I give advice on this podcast, it's because I misread the question. And so anytime you think that was a little weird, that's probably because I misread the question. Like I gave really good advice just to something someone else asked. yes i like that explanation i'll file it away for my own future defense so i do actually want to

zoom in a little on one of the words this person chose to ask this person is thor god of thunder i guess i'm a little little one little confused why the god of thunder would care about which direction their career goes whatever uh just imagine this guy with really huge muscles uh coding on the front end um let's see for example if i do mostly front end will this affect the way people see my broader understanding of projects i believe yes i believe that in our industry there actually is a little bit of a stigma against front-end developers like they don't understand the full system they can't do they can't lead a project and i'm not saying this is justified but i believe that stigma exists and i believe that if you focus exclusively on front-end

that that will close some doors for you in the biased minds of other people i've certainly seen different levels of engineering prestige for different areas of the stack and in general i think i agree with you the front end can be less prestigious unless it's really tightly connected to just excellent design yeah like a like a product that's yeah exactly it's like wow like in fact one product came to mind when you said that and i don't even know if we should say the name on the air but there's a both gonna say it at the same time okay ready so you count it one two three linear linkedin we got the first three letters the same

oh my goodness yeah that's a good point yeah linear is an example of a product people look at and think that design is awesome and and there's a lot of prestige it's awesome and very well implemented and so polished and fast and people are like i didn't even know you could do that on the web you know like the like the people who created google maps you know the front end for google maps originally remember how revolutionary it was you could actually click on a graphical thing and drag it around and the rest of the page would fill in dynamically it was like yeah whoa and zooming in incredible and i think the people who built that it's like yeah they are that's kind of a note a noteworthy exception to the otherwise bias against people

who only do front end. Or maybe if you work somewhere where there's enough scale that you need very specialized performance or design system folks that are really trying to solve large cross-cutting front end problems. But I think if you take the average front end developer and the average backend developer, maybe I'm reflecting my own bias here. I guess I can't not, but I do think the average backend developer will feel like more of a real engineer to other to others. And I think we should be clear that what we're saying here is not our own biases, because as you all know, we have transcended the whole concept of bias. And so we are only reporting a factual analysis of other people's biases. Yes. Let's be very clear about that.

But I do see this a little bit. Now, to be fair, I think front-end developers are super valuable and most projects would actually fail horribly without skilled front-end developers, especially if you tried to have a back-end developer do the front-end it's like yeah that's going to be awful so all sweeping generalizations are wrong so i'm going to say something wrong but i think it's harder to do excellent front-end work than excellent back-end work in general i think it's a harder problem domain yeah it's a little bit less constrained you know the input space is enormous on it right and it's impossible to please a lot of people you know yes yeah so i mean if i think i believe that and this is this has been kind of

the story of my career but the most valuable engineers or sorry let me let me restate that that the engineers who receive the most perceived value for taking on projects in leadership and management like it's asking about here tend to be those who have a broad exposure to lots of different areas of development. So maybe you spent a few years becoming deeply expert in front-end and then you pivoted and became deeply expert in back-end and then you pivoted and became deeply expert in infrastructure. And now you actually have deep skills in multiple areas that kind of qualify you to lead a team of cross-functional team members who are actually all working in those areas of specialization, but need someone to direct. And then you can speak with confidence

when you say, yeah, I think we should use a load balancer here to power our API. And then we should put our front end on a CDN or something like you have these terms handy, and you know what it means to say them. So I think that breadth or diversity of skills actually speak more than one, than deep, but single skilled expertise. It also depends on the kinds of projects that you need to lead. If you're leading a front-end project, then front-end expertise is a plus and deep specialization in that because you've spent your career in there to the extent that maybe you're a little bit less strong at other types of software development is not necessarily a negative. I'll also say that it's getting harder and harder to be a specialist in multiple disciplines nowadays, because A, the barrier to entry in all three of the disciplines I just mentioned, the barrier to entry has gone up, I think, over the last 10, 15 years.

And not only that, but the universe that exists within that domain is just enormous. I mean, you think about the technologies that are on the bookshelf or on the store shelf that you can pull off to do front-end development with today compared to, say, just 10 years ago, it's probably 100 times more options on the table. So it's actually really hard to even jump. And so to me, there's nothing wrong with a career that specializes in one of those areas.

Maybe a better or a different question you could ask is, what would make me effective at doing this? And I could see broader experience across the tech stack being one answer to this question but not the only answer certainly there's a whole bunch of other stuff that is not how well do you know the http 1.1 spec right whatever the the play framework and you could also start thinking about that stuff about people management or soft skills like like you've come to this podcast for or kind of estimation and planning and the the mechanics of figuring out how long stuff will take

and updating everybody with how it's going. And there's just a whole bunch of skills that will apply no matter what domain, technical domain the project is in. So maybe focus on those. I agree. And then I want to just zero in on the last word in this question

that said architect. It said, what are the impact? Let's see, I do mostly front-end. Will this affect the way people see my broader understanding compared to people's in roles such as architect? Well, I'll say that the only effective architects I know are people who first were skilled and specialized in one domain to begin.

You don't usually just, you're not just born an architect. And an architect here, what I mean is kind of like a principal engineer who directs the efforts of other engineers and tends to work at the design level where other engineers are working more at the individual unit or coding, doing a little more coding and a little more kind of in the trenches work. And so, no, like I think that those people, it's kind of a false equivalence to suggest that an architect isn't someone who focused mostly on front end. Like you could certainly have a front end architect.

You could also have someone who has front end in their background and other disciplines and is an architect currently. Yeah. Well, have we answered the question, Dave? I kind of think so. I mean, just to summarize, we're saying never, ever touch front end because it is terrible and everyone will hate you. Did I get that right?

no you got it wrong i love front end just kidding it's very satisfying to make a thing that someone else can touch yeah use very directly yeah but there is a bias out there and you'll have to navigate that and my personal preference is to have diversity of of skills so but i also like to go deep so it's it's not you can't do them all at the same time so it takes years to accumulate Yeah. All right. Do you want to read our next question? Yes. Next question comes from a listener named Travis. Travis says, my company is starting to expand across time zones. The majority of the company is based in one time zone and a handful of employees are spread across others. I want to emphasize the importance of asynchronous communication. I have begun to feel

like I need to respond ASAP to Slack messages instead of when it is convenient. If we were to say Slack is used for asynchronous communication, is asking the team to use signal or even text appropriate for a quicker response? What is a good way to handle reaching out to team members in cases where a response is needed more immediately? There's a lot going on in this question. The multiple time zone thing, the asynchronous versus synchronous, and the way that the tool you're using to communicate bundles along expectations for how it is used. It's all interesting stuff i will say that when you're spanning a significantly large enough set of time zones that from experience one thing that doesn't work are the warning beacons of gondor

they travel at the speed of light plus some person to run and grab a torch yeah that seems pretty fast right it is but i guess the problem is it's it's fast and then there's a pretty long setup time and that's and you can only use them not very high bandwidth and okay yeah that's fair and don't even try to send a message over those things you know like turn them on turn them off to signal ones and zeros it's like hours between each bit well that's when you need the mirrors you can flash yeah then you start stringing wires and then you get the internet yeah just like that if you skip a few steps from the the morning begins of gondor you're just one step away from the internet yes i remember what is that message or not message blog post is group chat making you

sweat we've mentioned this a few times but not for a while it's an article by the makers of an early group chat tool called what was it called fire or something campfire campfire that's what it was yeah i used it did that one become hip chat something like that oh no they were competitors think so yeah they were competitors they were both what they both could have been slack but for some reason that will i will never understand slack just absolutely swept the market away even though it does yeah they were early movers in the thing that wasn't irc that developers complained about to say why not just use irc and then i guess you could say they made it possible for like to exist because they proved out the concept yeah we paid them actually i don't know if we paid

them money i don't know we we patronized we we used their service and they should really be paying us for how for the privilege i'm off topic okay is group chat making you sweat the point of this blog post as i recall it is that there's a inherent expectation of synchronous communication even if you say these tools support asynchronous communication the fact that it's all very real time means it's tough to do it's tough to work asynchronously through slack because somebody is always going to be expecting an immediate response or giving an immediate response and it's it's just hard to roll back that expectation that even though someone could respond right away and sometimes does respond right away they they might not always and that's not how we actually work

that's the exception there's a bunch of other stuff in here we'll include it in the show notes and i'll probably read it again so i can remember the other things in here but i think i'm saying i feel your pain that you feel like you need to respond asap to slack messages and most of the time you don't but when you do you really do it's and it's hard to tell there's not a lot of requires extra effort to communicate that context in slack to say hey i need an answer right away versus please respond whenever and and not never not everybody does that and expectations can differ between different people so i feel this pain that generally you want to move to asynchronous communication but it's fuzzy what the broader expectations are yeah the company and how and

for how the tool should be used. Yeah, exactly. And I think a lot of people, if you were to go survey your company right now and ask them what is the expected response time on a Slack message versus an email versus insert your technology of choice here, I'll bet you would get a pretty big distribution

where the minimum and maximum are quite spread. So yeah, you're gonna have to navigate that whole mess. One way that I've seen people do this is write it down and also make sure the behavior matches the thing that's written down. So GitLab has a big old communication handbook, and there's a piece in there about asynchronous communication. Really, really good. Yeah, I've never worked there, but I've stolen their handbook.

Yeah, I feel like I've worked there because I've lifted so much content from their handbook. Yeah, but from that, I interpret that they are trying to be explicit with the expectations and make sure that they're understood and followed and used by folks. But just it takes a lot of effort because without deliberate effort, the expectations will diverge. Yeah. And also, is this true? I don't know. I feel like the higher up you are in a company, the more you expect people to respond to you right away. Maybe.

Or at least it feels that way on the other end of it. It definitely feels. Yeah, there's definitely some pressure when someone above you a few levels sends a message. unless they explicitly say i feel this unless they explicitly say hey get to this when you get to it or not urgent or whatever if they just ask a question i feel like well i have to do it even if we have this culture of being asynchronous we're kind of sidestepping the question though i guess they're also asking is it okay to use two different oh yeah mediums oh short answer that's totally fine love it i actually do that at work all the time in fact people have explicitly

told me look if you want to get my attention immediately send me a text if you don't mind at taking a few hours or a day, do it on Slack or email. I'm like, great. I love it. I've said that to people, but I can't not respond right away. I have a hard time behaving that way. I just want to be helpful. People ask stuff or... You can, but sometimes you just don't see the message because you're occupied with something else, like a meeting or something, right? That's true. And so I'm sure that you're like me, where if you see the message, you feel compelled to respond. but when you don't see the message which i have set up most of my messaging systems

to do so that i only see messages when i go look for them yeah when i don't see them then i just don't respond because i don't see them and if you want to get my attention use one of these mechanisms that i've set up that will notify me or ding at me do people use text fairly regularly for that immediate response i mean i my whole team does uh for sure okay and we've explicitly said that to each other like if you want our attention right away use a text message and we'll know that it's important or call call me on the phone what's the the level of urgency that would do you do it regularly i mean if there's an emergency if there's a page then yeah i get called right but i've definitely said if it's if it's important for me to respond right

away send me a text or call me and i think the only times it's ever happened are when it's really something pretty urgent usually some kind of incident yeah like i'll i probably only do it once or twice a week at most sometimes zero times a week and and i receive even less that's me transmitting you text someone else yeah okay on the receiving end it's probably even less people message me even less yeah but like you know take take for example we we're all remote at the moment we've got a meeting with a bunch of people and there's just something that we really need to get answered because we're not going to be able to get together again for several days and somebody has the answer so we'll message that person and say hey can you hop on with us for a

minute you know so that'll be that'll be a case for a text or signal or phone call you know and then there's the whole obvious category light the beacons fetch the technical program manager that's the tpm torch yeah yeah and then if there's a whole obvious category of things where the system is down and it's like no one would would question why you did a synchronous communication style for that but um otherwise it's just judgment calls and i think you know a team ought to write down what their policy is and agree on it because then no one can be i mean really frustration happens when people get they have there are expectations placed on them that they didn't agree to or understand and then people are disappointed in them it's almost like

meta frustration it's like you get frustrated because someone else is frustrated with you because you didn't respond in the time they thought you should respond but you didn't know you were supposed to respond in that amount of time so now you're both frustrated and so yeah putting this all down on paper and then as examples happen writing them down and adding them to that document to say hey here's a few examples where we felt it was appropriate to use synchronous communication this helps people calibrate especially new people because they can come in and go oh let's see if my situation looks like some of these situations okay it doesn't all right i'll do async yeah i like that i like the examples advice the i think that is the the

correct answer to a good way to handle reaching out to team members the correct answer is whatever way you have agreed upon and documented with the team and i imagine they're pretty reasonable people i mean they know you and you listen to this show which means they have they have the good judgment to associate with the soft skills engineering listener says something good about the quality of their character and i think that means that they yeah they they probably would not object to the idea that there's some way to get a hold of them when it's important and and there's so many different ways to do it that pick away it'll work if the team thinks it's reasonable i agree it does there is like a having multiple channels for communication

having to monitor them is a pain in the butt and one nice thing about slack for everything is that's the only place you look you don't have to remember to check other thing so you probably need to calibrate how often you use it like if i don't know 15 of your messages are going through this text or signal channel that feels like it could be a lot because that's enough that you basically have to monitor them both all the time except that what you're saying that monitor both the synchronous and asynchronous channels? Yeah. I mean, I guess the point of the synchronous one is you get interrupted. Exactly. There's no monitoring there. It should just pop in your face. Now that doesn't always happen. Or maybe you stepped away from your desk for a moment and you

miss an alert. So yeah, you kind of got to check things a little bit, but by and large, your synchronous channels ought to be configured so that they are unignorable. Yeah. The air horn. Exactly. Arduino kit that you send everybody on the team. That would be a fun hack week project for a team hook up pager duty to this giant air horn yeah a little actuator that pushes a button that's connected to an arduino that's connected to your to some sns topic or something that'd be so talk about incentivizing developers to not have downtime yeah all right have we answered this question i think so good luck it's a noble cause and absolutely something that every team should have an established policy for yeah all right what should 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 form which we love we receive so many wonderful questions every week and we love reading them and we love you but we would love you more if you would submit a question to the show you can fill out as much or as little information that identifies you as you want the uh the credit card and social security number though are required so you might just have to make one up. I'll give you mine. Listen, if you're hung up on that, shoot me a DM on Twitter. I'll hook you up. Don't even worry about it. I'll paste you mine. All right. All right. Thank you for listening. We'll catch you next week.