Soft Skills Engineering - Episode 356: Ummmmmmmmm and failed spikes

Episode Date: May 15, 2023

In this episode, Dave and Jamison answer these questions: I recently started listening to your podcast from the very start of the show! One of the largest differences I noticed (aside from the audio quality, lol), is how often you used filler words like “um”. How on earth did you manage to stop using them? In work presentations and demos, I often end up using the filler words, and listening to the recordings later is painful. The rehearsed parts of the presentation go smoothly, but as soon as I go out of the “script”, I start depending on filler words. How do I get better at this? How exactly should spikes go? I’ve done some deep dives to understand the scope and steps of an upcoming effort, all with detailed write-ups, only to later realize during the implementation that I got some things wrong or missed out some important details. Isn’t that the point of a spike, to root out any unknowns or surprises? Short of just doing the actual implementation, which I’m pretty sure is also missing the point of a spike, What am I doing wrong and how can I properly present post-spike findings to my team?

it takes more than switching jobs so much that you start to feel invested in the soap opera world of the harassment training videos to be a great engineer this is soft skills engineering episode 356 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers about the best characters in the harassment training videos they all do seem like they're part of a shared universe i wonder if there's a subculture of the acting world that does corporate training videos oh yeah i bet there is there's somebody who's there's like a character actor for the the creepy guy who harasses other people or something imagine that guy at parties what do you do for a living yeah i'm i'm an actor oh have you been

anything i've seen probably let me try this move on you all those examples i'm the tom cruise of harassment training video actors i really drive traffic to the videos i'm an a-lister yeah people people hate me so much they are compelled to finish the training i'm the voice the narrator voice that says when you've completed this section click the next button yeah i wonder there is a genre of or uh that they go for a certain voice kind of voice that seems soothing because they have to make up for people rage clicking to try and get through it faster than the video thing allows we know you're trying to skip this furiously as fast as you possibly can please calm down yes please do not let the

harassment training video cause you to send harassing emails to the company for making you watch it now you've made me think of the software developer who had to build that feature the one that forces you to actually watch it all before you can click the next section button and i think about that poor person at parties oh what do you do for a living i'm a software engineer have you built anything i would know yeah i built the feature that prevents you from skipping sections in the harassment videos and you just get punched you know how if you mute the video or if you change tabs or if you try and open the dev tools yes it pauses immediately that's me i figured out all the ways people could try and skip i built seven different prevention techniques for stopping

you from oh so painful oh somebody's got to do it dave i want to thank our patrons can i do it yes please do you have my permission okay this is a shout out to the folks who contribute at the level that we we say their names or words sort of like names every week thank you to the computer science book.com kyle boss van valentin at datafold santa hopar noah frazier loge kensi dodds jenny kim owen chardo craig motlin i love mavis the stochastic parrot alice jost at least we no longer have that name flocking if i forgot how to say that word is common in landfair will go go dory dob just wing it uh canada newton ohio patreon.com.au we're hiring ira chan monkey face emoji jonathan king testing is documenting.org

oladapo fadie anchor the shout out sponsored by will angel ragnar nick hathaway travis sanders brayden canes john grant bartek tatkowski cody sale nick cantar and philip john basile thank you we appreciate it uh if you want to join this group you can go to softskills.audio and click support us on patreon where any amount of money will get you an invite to our slack team amounts above whatever it says in patreon will get you either a one-time or a weekly shout out but even just clicking on it gives us a little burst of joy in our hearts that's true even if you don't convert just the click through it makes us feel good we can feel it yeah check us out on youtube you can find us at soft skills engineering if you like to consume your podcast there

or watch us talk for some reason known only to you um and uh one more announcement uh i'm looking for work i'm looking for a job i'm looking for uh roles leading engineering at a small-ish startup or managing teams of engineers or other engineering managers so if you're hiring or know someone who is how should they get in touch with me join the slack community yeah join the slack pay it's a pay-to-play uh i don't know probably twitter is the best place i'm at jameson underscore dance on twitter all right dave do you want to read our first question yes i do an anonymous listener says i recently started listening to your podcast from the very start of the show one of the largest differences I noticed aside from the audio quality lol is how often you used filler words like um

how on earth did you manage to stop using them in work presentations and demos I often end up using the filler words and listening to the recordings later is painful that's relatable the the rehearsed parts of the presentation go smoothly but as soon as I go out off script I start depending on filler words how do i get better at this i saw this question and it made me feel so good because i thought oh we've gotten better at this over time we've developed into more eloquent fluent speakers and then dave told me the real answer which i'll let him reveal Which the editors remove all the ums. Oh, my patting on the back was too soon.

So get an editor for real life. Yeah, real time. A real time editor that can somehow mute you as you're saying um. Maybe they show up and they just put their hand over your mouth. How would you do that in real time? You would have to have some kind of delay. Yeah, a small delay. is all you'd need or maybe the the ai magic doing this would be smart enough to it it would be

processing your audio in real time and then detect when you were going to say an um and then it could start to stretch out what you were saying and then kind of speed it up afterwards to catch back up to real time oh to just fill in the gap that would otherwise have been an um i think so okay i was thinking you could have an ai that actually is listening to your nervous system and intercepts it before it can go to your mouth oh it blocks your tongue from uttering it so you just sit there twitching one eye starts to twitch to the right avoid using filler words by having a stroke on zoom such a good idea oh i just said it i just said um oh perfect

you're gonna be really self-conscious about it it is one of those things that it's like noticing your breathing and then you can't stop noticing it yeah okay i have some strategies for this one of them is to believe deeply within my being that what i have to say is engaging and important and everyone is hanging on my every word okay thus it is so important that it's worth me taking the time to speak carefully and deliberately and i don't have to worry about hurry up and filling the space because they're yes they're already engaged they're already waiting with bated breath sitting on the edges of their seats so if i need to pause to organize my thoughts that just adds gravitas to what i have to say yes i was going to say the same thing don't

be afraid of a little silence in fact something i do i don't know if i'm really good at this but I think I'm pretty good at not saying ums, but something I do is when I'm speaking, I will sometimes, oh man, now I'm really trying hard not to say um. The stakes are high. I will sometimes use a moment of silence to convey via my body language that I'm thinking deeply about something, you know, and I don't know exactly what the facial twitches are or the, you know the shape of my mouth or the furrowed shape of my forehead or eyebrows i don't know what they do but i know they come together in a in just an orchestra of facial muscle invocations to convey that i am thinking about what you said and i almost said um right there oh man oh but

you avoided it because you're great at this i do think you're good at it i think you have noticed in our in our just casual chats i feel like that's where it comes out a lot for me but you're just is polished i think you need to replace filler words with filler actions imagine instead of saying um you do you do a cartwheel genius i need to buy myself a second to think and back handspring i think that would make your presentations memorable oh that's for sure i encourage you They would be memorable to be polished in your delivery. Yeah, slowing down is important here. Yeah.

I do believe that most people, when they get nervous, feel an obligation to completely fill every piece of air with the sound of their voice when they're speaking in a group. And when you're not nervous and you're not scared of the people in the room with you, you can just pause and think. And it's okay that there's dead air. I will say that depending on the audience, sometimes if you do take a moment to pause, whether for gravitas or whether to convey that you're thinking or to actually think about something for a moment, there are some audiences that will just jump in and they will fill that breach with their own voice immediately. And so that kind of creates an environment where everyone feels compelled to use filler words, because if they don't fill the air, someone else will. Or filler cartwheels. Right. Sorry. yeah that's a good point if it's a presentation you're less likely to have to defend your time

yes i have noticed that though where and there are some people who i don't know how they do it but they appear to be able to speak off the top of their dome in fully formed paragraphs forever yeah yeah endless monologuing yeah i'm not like that i usually need to have thought something through to be able to speak competently about it or i get pretty rambly and the filler words come in but it does make it harder to participate in those kind of real-time collaborating brainstorming discussions where you're just trying stuff out your point about your level of comfort with the audience that maybe is another approach you could take to this instead of trying to make it so you don't say filler words make yourself more comfortable with the audience and then you'll

kind of naturally do it less yeah how do you do that is that where you imagine them all in dinosaur costumes hmm yeah i think you just have to feel superior to all of them the key is to not respect the audience i don't care what you think or say or think of me and thus i'm not nervous in front of you you have to practice deliberate contempt yes you got to be able to turn it off it as well though yeah when it doesn't serve you i should write a book on how to be contemptuous of the people in the room with you how to convince yourself that they don't matter so you can stop using filler words i do think this is something you can practice and believe it or not listening to your own voice

which i've done a little bit of thanks to this podcast what are we on episode 356 i've only listened to two episodes but anyway just kidding um but you just listen to them over and over again because you found ones with lots of filler words yeah you torture yourself that's pure torture it's how i put myself to sleep at night anyway um practicing oh i just said um there it went i think that was my first one yep so we're 14 minutes you had one right before then but i let you get away with it that's okay and that that supports my point which is this filler the nature of filler words is that you don't usually know you're making those sounds. They're just coming out like your eye blinking or your lungs operating. So the best way to train yourself to stop doing it

is to listen to yourself. And I hear that on this question. The question asker says, when I listen to the recordings later, it's painful. Yep. Embrace that pain. Go listen to those meetings and hear every um and really give every um a name and fill yourself with contempt for those oh you you want to anthropomorphize yes you hate them okay uh expunge them um you there it went there was my um you can't really eliminate a habit if you can't see it or measure it and i'm not saying you should go and measure how many times you say um um gosh oh okay i'm in i'm in a total funk now i'm just spewing the ums because you respect me too much quick quick quick turn on the turn back on the contempt i'm filled with rage and contempt

anyway what i'm trying to say is simply you got to be able to observe it in order to fix it and the best way to observe it is to listen to your own voice recorded back and pay attention to the things you say pay attention to how you must have been feeling at the moment when those ums started coming out and then you can work on on correcting it there are some tools that can detect these filler words automatically at least in english they're probably out there in other languages like a like a little app you can have on your phone or computer and it'll flash every time you say um i haven't found that one yet or a shock collar oh yeah a big squirt gun oh that's blast you right in the face every time you say um that is such a good idea you have to have some

way to delineate non-filler ums you have to give it some token beforehand to say this is a deliberate um right please don't shoot me backslash um yeah there you go i haven't found that that would be rad i have found stuff that will analyze recorded audio and point it out a lot of it will like remove them i said like like is a common one that's also a filler word yeah some people have filler phrases my father-in-law says the thing of it is a lot the thing of it is yeah i've also known someone who says anyway a lot as a filler word like starting sentences with it oh here's one yeah the word so starting a sentence with the word so i think is a filler word huh what what the longest filler phrase is that would be so funny if it was like a 20 word 20 word monologue

filler phrase all right well yeah should um um should we get out of here like yeah i think we've answered the question okay i i like i feel like um we did i'll let my silence convey my deep confidence and expertise and contempt dave will you read our next question i will but it's actually your turn so i mean if you want to yield i will read it but i will read our next question i believe in equity and i think it's your turn okay this is from a listener named brandon how exactly should spikes go i've done some deep dives to understand the scope and steps of an upcoming effort all with detailed write-ups only to later realize during the implementation that i got some things wrong or missed out on some important details isn't that the point of a spike to root out any unknowns or

surprises? Short of just doing the actual implementation, which I'm pretty sure is also missing the point of a spike, what am I doing wrong and how can I properly present post-spike findings to my team? I think this deserves a little bit of background or context setting for what a spike is and why someone would use that word. Oh yeah, that's a good point. Would you like to set the context? I would, but I'm not really an expert in this domain. I'm pretty sure the term spike came from the agile software development methodology community and it's it was basically a a workaround for the fact that the process itself never allowed time for research it was just build build ship ship ship build build you know continuous delivery of value for

the customer and so they said you know we need we need to be able to carve out some time for developers to do research before they start building because if you're just in constant build mode you might build wrong go down a dark alley and have to come back and throw away work so a spike is the capital a agile trademark approved term for doing research that has no customer value or deliverable to the customer um there's my um for you that's the only one i'm going to say for the rest of the show i'm done with um all right i hit my i'll scream loudly every time you say an um from here on out i'm totally gonna get a water gun and a little servo with an Internet of Things device

so you can press a button. Oh, dang it. That was not even on purpose. So a spike is usually a time-boxed research effort where the output is information to be used by the development team and the output is not a deliverable for a customer. There you go.

How does that definition fit with you, Jameson? That sounds great. I realized while you were saying this that maybe this is one of those concepts concepts that has a very specific definition from whoever originally created it and then it's kind of diffused out through the culture and become much more vague but the way i understand it is basically yes it's some amount of research to help you figure out what to do next yeah when you know you want to do a broad thing but you don't know how to break that down into individual tasks yeah

and a lot of times it'll be a proof of concept or a prototype or something so that you can get your hands dirty with a concept or or a new technology and then when you actually are going to build it when you've committed to deliver it on a certain timeline or a sprint or something, you can have more confidence. So yeah, there was a rhetorical question in the question that said, isn't the purpose of a spike to root out any unknowns or surprises before you start working on it? Yes, that is the purpose of a spike. Oh, I was going to disagree. I was going to say no, not to root out any unknowns. I think it's to provide information and reduce the risk and help you figure out what to do next but i would not expect a spike to completely answer

every question or mean that there aren't going to be technical questions that come up in the actual implementation of the work maybe there's hmm it gets kind of fuzzy uh oh no i said it i said uh instead of um i actually like which one do you think is worse i don't know yeah i think it is unreasonable to expect a spike to completely eliminate unknowns or surprises i think you can maybe see trends where if you regularly uncover large new things after you spiked on work maybe that indicates something differently you can spike on or do in your spike to try and account for that class of problems but i think it's fine that as long as the spike provides you useful information and is like i said like is

directionally correct that feels good enough for me i don't think the outcome is an accurate estimate of how long it takes to do the work or a complete task list or project plan or something i think it's to give you more information yeah i like to think about spike planning as the balance between doing all the work to figure out how to do the work and not doing any research up front and ask myself were we better off during implementation because we did a spike or are we worse off because the spike delayed the start of implementation yeah somewhere there's a perfect placement of the pendulum where you do just enough research in the spike so that the implementation goes optimally. Because I like to think about the two extremes. So on extreme one, you do a spike

that takes six months, and then implementation only takes a day because you did all the work in the research spike. That's probably not what you want. And then on the other extreme, you have a whole team working on something with no research done beforehand. So they end up throwing away a bunch of work and going down a bunch of blind alleys and having to come back. And now it's multiple people wasting their time instead of presumably one person doing the research up front. that's also not what you want so somewhere in between the balance has to be struck for the spike there are a couple questions in here what am i doing wrong and how can i properly present post-spike findings to my team i think presenting post-spike findings to your team relies on you

and your team having a shared understanding of what the output of the spike is and maybe on your team it does mean the spike turns into a project plan and that's fair you can you can do whatever you want it's your team but if you expect that the spike is a list of things to be careful about and your team expects the spike to be a list of stories or tickets or whatever that you can go build then they'll they'll be sad about the output of your spike because it didn't work in my teams there's typically a step after the spike which is like okay now now let's make the plan based on what we've learned like create all the stories and write a design doc or something yep that's not part of the spike no not usually the spike is usually one question maybe the question is broad

and has sub questions underneath it but the goal of the spike is answer this question as thoroughly as we can in the time we've allocated for it yeah exactly and i think that's a key point is that most spikes are time boxed and so you know that you're only willing to invest so much time and the overhead of researching before you start building i would also say that during development if you don't discover any unknowns at all everything was crystal clear from the beginning and you ship it you're probably doing pretty boring software engineering if there's really no surprises and nothing new that you learn while building then yeah i guess there's two ways that that could happen one is that you've done such extensive work up front that you already

knew everything you were going to build. Or it's just really boring software. I'm trying to think of a really boring software. I don't know. Maybe it's I fill out a form with people's first name and last name, and then we store the form results in a database table. Okay. Probably not a lot of surprises there. You need to reverse a string in every language. I would not take it as a negative sign that you discover surprises during the implementation. That might actually mean that you're just working on hard problems. And I like to tell myself, because it makes me feel important and special, that software development is a little bit of a different craft because every task we take on, it is the first time that anyone in the history of humanity has done that

thing. This is not an assembly line. This is not repeatable work. Every single time we build it, you're building something brand new from scratch you know like i think about um oh there's another filler word you know that's a big one i think about jobs where maybe you're assembling things maybe maybe you're an etsy craft shop and you're assembling some cute little trinkets and you have to put them all together well you know you put together a thousand of those things and you're not really going to have a lot of surprises after the first three you know but in software development it's always the first one because once we build it once we don't actually have to assemble anymore you just the computer just ships copies so the code you write is always a first

time craft and there will always be surprises and that's part to me that's part of what makes software development so fun now we're getting off topic what a digression from how we normally operate this podcast yeah i also like that you're operating in man-made constructs that are basically ideas made made into something real it's not like you're digging dirt and you need to go study the material sciences and the geology the substrate you're working in is someone's idea that they turned into code a few years ago and i think that's part of what makes it fun too you're kind of like taking in parts of people's brains and building stuff on top of them yep it's really cool so lean into it but of course as with everything in engineering it's a judgment call

if you find yourself making too many mistakes and having a lot of surprises during implementation it could be that you just didn't do a thorough enough job and you need to go level up your ability to research beforehand and anticipate these things because that is a really valuable skill especially if you're doing research that other people are going to use during the implementation of the software because if you you know you make a mistake and then 10 people go down the wrong path and they have to come back that's a lot of wasted effort it's not necessarily bad it might even be a necessary part of the process but we should try to minimize that that's an important part of our job yeah we didn't really talk about this and it didn't come up in the

question explicitly but there's also a skill in communicating the stuff that you learned to other people if they're going to work on it if you do the spike and you find out some of the unknowns and the hairy parts and maybe you come up with some answers but the team doesn't understand them then it didn't work it didn't it didn't help yeah you may as well have not done it right yeah exactly if they have to go rediscover the stuff that you figured out then it was a waste of time so yes maybe this is a good segue to a final point i'll make which is that the output of research for software development purposes should almost always be a written document for two reasons yeah Number one, maybe three reasons. We'll see if I can remember all three as I say them.

Number one, writing helps you clarify your own research. You've learned things. Now go write them down to see if you actually learned them. Number two, it's much harder to misinterpret written communication than verbal communication because it can be referenced again and again. It can all, you know, it doesn't change every time it's spoken. Every time you read it, the words don't change around. Writing really helps with that. And then number three, it scales like crazy because when you've got 10 people and you know only seven of them show up to the meeting where you're sharing your research and then you got three more you got to go do it again well with in written form that's fine they can read it on their own time they can reread it

so it scales really well so to me that's a great way to make sure not only that you communicate it well but also just the act of writing down your research will force you into a mindset that will make you more comprehensive in your research yeah here here and while you're at it ask chat gpt to write us a love letter oh chat gpt it's actually a good point the writing part has gotten a lot easier now you just throw a few bullets down into chat gpt and say write this in a engineering style doc and then you edit it to taste and you just save yourself three hours of writer's block yeah i will i'll remain on topic nice try i i think there are i have concerns about that approach becoming more widespread but um nah filler words i gotta get out of here before

i say more filler words and make it clear that all my advice was hypocritical i'm gonna ask chat gpt to write a document that has tons of filler words in it oh yeah why don't we ask chat gpt to write us an application that detects filler words from your local audio and then beep when it detects them could it do that is it no like native apis like that i'll find out after this show but first we got to end the show what can people do if they want their own questions answered dave go to soft skills.audio and click the ask us a question button thank you so much to everyone who fills out our form each week we love reading your questions it keeps us going it fills my heart with joy and when dave's heart is full of joy my heart is full of joy the spillover goes into

The Jameson's are the spillover. Yeah. Yes. I get the overflow joy. Thank you for listening. Thanks for your questions. We'll catch you next week.