Soft Skills Engineering - Episode 26: Communicate Your Efforts and I Told You So

Episode Date: September 12, 2016

In episode 26, Jamison and Dave answer these question: How do you make sure people know about your good work? See Matt Zabriskie’s great post for background on this. We also mentioned Do Things, Write About It. How do you get your point across effectively so you don’t have to say “I told you so” later?

It takes more than great code to be a great engineer. This is Soft Skills Engineering, episode 26. I'm your host, Dave Smith. I'm your host, Jameson Dance. It's another great day on the podcast. It is. I feel like I need to acknowledge the fact that my microphone is crappy. I'm traveling right now, so I'm on junky iPhone headphones.

Is there a name for the phenomenon where when you're doing something poorly, you say it out loud just so everyone knows you're doing something poorly? I think it's called calling your shot. i'm pretty sure isn't it that's what babe ruth did right before he famously whiffed on that pitch in the world series wasn't it like but did he was he calling that he was gonna miss it or was he calling that he was gonna hit it out of the park no look it up he called he was gonna miss and then he did it's 100 fact you're basically saying you're babe ruth right now i am babe ruth yeah i've transformed

yeah i was gonna say that's not i was gonna say if it didn't have a name i was gonna say let's call it pulling a jameson pulling and that's what i want to be known for announcing that you are gonna suck at something and then sucking at it so jameson's on travel today is assured you're on travel today so you're away from your fancy pants equipment yep but the show must go on we care about you that much yes you're like family we wouldn't miss this it's like thanksgiving dinner yeah we wouldn't miss it it has been delayed because of travel so technically we did miss thanksgiving dinner we just rescheduled it but yeah yeah for christmas yeah okay i will

read the first question um how do i make sure my team and company recognize me for my work and there's a little more background on this question do you want to talk about that dave Yeah, sure. A mutual friend of ours named Matt Zabriskie wrote a very thought-provoking blog post about a topic that I have never conscientiously thought about. It's titled Communicate Your Efforts and subtitled If a Tree Falls in a Forest and No One Is Around to Hear It, Does It Make a Sound? And he goes into this great story about him working crazy long days, 13, 14-hour days, working until like 3 a.m. day after day after day. But apparently no one knew he was doing it. All they knew was that he looks really tired and comes in late every day. And at the end of the day, people didn't really recognize the heroism that he had, you know, all this work he had put in. Then at a different company, he did this tiny little change to the UI to make their product a little bit better.

And then he sent out an email to the team about it. And he got all this praise. You know, the VP of the engineering was like, I love this kind of innovation. Great drive, you know? And he's like, what? What just happened? And so he identified that the difference was communication. He just simply shared what he had done with others.

So we're going to talk a little bit about techniques for that today. So I'll tell you what I do is I forward all of my git commits to the CEO, just to make sure he knows. i have set up a hidden speaker in the team leads office every time i push to github it just plays like a klaxon to let them know jameson he has committed it's kind of a fanfare yeah or maybe it's like a gregorian chant like like my code is uh descending from the heavens into the app there's a network of speakers because they keep finding one but then there's always another one there you go that's how you make

sure people know what you're doing got it um i think there are two interesting things the first thing is definitely the communication part the second one is um the the distinction between input and output where earlier in the story matt was putting in insane hours working crazy amounts of time working really hard um but uh i'm sure it had a big effect on the project yeah probably it doesn't seem like the effect was proportional to his input and that's that's that feels like a true thing to me like working hard doesn't mean you produce something all the time so when you said input and output i think a business person would call that return on investment yeah yeah it's kind of like the what is it the pareto principle the 80 20 thing where 20 of the effort produces

80 of the result or you can kind of mush that into a bunch of different contexts but some of it is just the the task that he was working on was low effort and high impact so yeah exactly that's exactly that's one strategy you could just like only work on the easy stuff strategically pick the easy but impressive stuff well no i mean there's always going to be a bunch of things you could do and um some of them are going to take a long time but but sometimes you have a choice between um something that will take a long time to produce value and something will take a lot less time and might still produce the same amount of value so i don't know you can be slimy about this but it doesn't feel slimy to consider um can i put in less work and and get more output

by doing this other thing oh yeah definitely i mean if your only goal is to get recognition then that that can feel slimy but if your goal is to add value for the people the audience that your product is targeting then why not do the high impact low effort stuff like that's just a no-brainer but even then even then notice that in matt's story he did that high impact low uh effort project but if he hadn't sent an email to his team they might not have even known that he did it or you know they might not they might have just been like oh cool that that finally got in the product you know great yeah you know yeah or it would just they might not even notice ever it would just kind of start to feel a little yeah like oh that's always been there right it's like

yeah yeah yeah so that to me was the key difference yeah the communication part is is big um i'm just saying you can also do something with the actual work you do some of the things that i like to do is um i give frequent status reports to leadership whoever that is don't wait for leadership to ask you how things are going um and i don't mean you have to sit down and fill out like a complicated form and write up a big long email. But I like to keep stakeholders apprised of the stuff that I'm working on. And not just like, hey, I worked on this, like that is utterly uninteresting. What's more interesting is outcomes. Like, hey, I did this project. And as a result, our customers will be able to do this thing they that used to take three hours, they can do it in

30 minutes now, you know, or I worked on this thing that allows other developers to write code uh with fewer bugs isn't that cool you know and i like to focus on outcomes you know what are the outcomes of the things that i'm doing and don't brag yeah oh you know it's not about like look how great i am it's about look at the cool stuff we have now you know talk about the benefits to others don't talk about why you're great yeah i think this this comes more easily to some people than others and i know matt pretty well and he's a very unassuming person he uh is super talented and he doesn't tell you he's super talented so i think this problem applies more to people um who have a hard time kind of talking about themselves or or feeling like they're bragging

then other people might have the other problem which is like how do i not annoy everyone by talking about myself all the time uh so this is more towards one end of the spectrum than the other and it's it's important to know where you are in this spectrum i'm probably kind of a little more towards the end of the spectrum yeah i can see that maybe i mean i don't know i mean but not me i'm really really great you're towards the the better end of this yeah the great end whichever end that is it's it's all the ends that are great that's where i am and i'm making it really great yeah yeah it's it's interesting looking at this from uh the individual's perspective because you usually hear about it from the manager's perspective and it usually

comes up in the form of i don't really know what that person is doing i i'm sure they're working because i see them and their team likes them but but i couldn't tell you like what they did last week and what they're doing this week and and uh sometimes engineers want to avoid process and they want to just put their heads down in the code sometimes it's from not wanting to brag but um if your effort happens without people knowing about it it's like does it does a tree make a sound if it falls in a forest is it really doing anything if people don't know about it Mm-hmm. So I think that as an individual, you can tell others about your work. If you are a leader in your organization, I think it is your responsibility to identify the cool things

that people are doing on your team and tell the rest of the team about them. And this is hard to do because it requires a level of awareness of your team that takes effort to achieve. But the benefits are really great because if you see someone do something really good that has great benefit for other people, like that VP of engineering did for Matt, you then can broadcast that to the rest of the organization and say, hey, look at this cool thing Jameson did. Because of his work, we're going to have X, Y, and Z benefits. And you can list those out and say, I'm really happy to have that. But you don't have to be a leader to do that. You can even just be a peer. Like you may notice Jameson doing something cool. And doesn't

it sound even more awesome, Jameson, if one of your peers says, hey, team, I just want you to know about this cool thing jameson did that i found really beneficial you know like he fixed up our build system so it'll fail faster and give us better useful output you know something like that uh suddenly it takes on a whole new level when you do that for your co-workers so if a tree falls in the woods and you see it but no one else does you can talk about it yeah bragging about your team is is amazing and and it can like basically never go wrong as long as you're not slamming on another team and doing it in a competitive way, but that's a really

good point. My team produces so much better code than the sales team. So much. We destroy them in Super Smash Bros. 2. Yeah, that's a really good idea. I like that, Dave. I like what you said about the manager

as well, where in the case I was talking about where the manager doesn't really know what they're working on, like you should have little alarm bells going off in your head and go find it out because if they are good and i'm assuming they are because they're on your team and you're awesome they're doing some kind of good work and and you can help promote the visibility of that yeah it is so hard as a manager to know what everybody is working on at all times you know if you have more than like 10 people you're responsible for it's so hard to keep track you wouldn't think it would be it's only 10 people

but it is just so hard because it changes all the time right like hey you still working on that webpack thing oh no that was last week you know it's like dang it yeah my state isn't valid all the time then you have different problems yeah exactly but i think as a leader it it's on you to talk to these people and just say hey what you're working on there's no shame in asking what are you working on how's it going i hated stand-up meetings for the longest time and i've moved from hate to begrudging tolerance and it's partially because of this because it's a built-in check for you to tell your team what you're doing and um it took me a while but i figured out to to do it more in the way that you described dave where you're describing outcomes

instead of uh instead of effort yeah like what am i working on oh i hate that today i worked on this like i don't care i worked on this code file and i've done that a lot and other people have done that a lot and i i finally realized like i don't care when they say which file they're working in they probably don't care when i say what file i'm working in and then kind of changed how wait you're working on main that's awesome that is awesome i can't wait to see just all the good things that come out of the letters you're typing into main i bet you're typing really good today yeah please david's typing well this is a podcast no i meant literally he's doing good with the typing oh like he or he's typing the word good

i meant literally good yeah but but how dare you pardon me but stand-up is a good way to practice that um and and this might feel really weird but i don't think there's anything wrong with doing what matt did where if you just do something you feel like especially proud of or it was kind of a big struggle and you finally solved it there's nothing wrong with just tapping somebody on the shoulder and say like hey i did this and i'm super pumped yeah isn't this cool yeah what do you think of this yeah that's that's what i was gonna say if you're too if that makes you cringe too much you can say like looking for feedback on this thing yeah and then you just kind of hope their feedback is you are the best hey ceo i'm looking

for some feedback yeah and by feedback i mean give me a raise he just like tears apart your code in a detailed code review you have no concept of architecture or style does the word cohesion mean nothing to you yeah so another way you can approach this is by sharing things that are of documentation interest like say you've built an underlying tool or framework that's going to help the team you can write up some documentation about it maybe you have a team wiki or google docs or something uh you can write up a doc some documentation about it and then write an email to the team explaining the new thing you've built with a link to the documentation and suddenly it's like you're you're you're doing two things with one what is it killing two birds

with one stone uh two seg faults one i don't know and what you're doing is you're sharing information about the thing you built thereby you know communicating what the effort that you've put in. But you're also sharing documentation, which is needful for the team to use the thing you've built. So it's like, this is a case where documentation is not only its own reward, but also can benefit your own self personally. Yeah, I've, I've seen a different take on that where the team has some kind of brown bag like thing. Usually the brown bag is about some external tool or technology that somebody is interested in wants to share with the team. But i've seen them be internal as well where it's like check out this cool thing that amy did and

and this new pattern she introduced to solve this tricky problem and as a way to spotlight team effort yeah that's cool i think i i would have one word of caution which is if you focus your work too much on um producing shiny internal product things uh it might make you shy away from the gnarlier problems this is kind of what i was talking about at the beginning but the opposite way right if all you want to do is just deliver a component that has a glorious demo page that has cool animations because then everyone will think you're awesome um that's not most of what programming is most of the time so uh i think you can get too drawn into this idea and and and focus more on people's praise

versus like yeah building stuff but just don't do that i don't know yeah i mean totally there's a balance there right yeah yeah and that would be super annoying if you had a co-worker that was just like clearly motivated only by the uh plus ones and replies they get to their email chain when they get a load of this guys like i don't i want to get a load of you fixing the bug that we've been stuck on forever also you told us about that last week fred yeah if you're struggling with people not knowing anything about your work like probably go go hard at it and then you'll course correct if if if you make it too far to the other side in the unlikely event that you make it too far yeah yeah what were you gonna say

though well i was just gonna tell a little story about something i built why years ago yeah you gotta tell it and i will give you praise oh i think i know how this is gonna work so a few years ago we were building our system at work and we you know how you build a system and it looks like it's having no problems um but the only reason you don't think it's having problems is because you have no monitoring yeah yeah or like everything is broken except the piece that says hey everything's fine yeah oh no that and that's broken in green yeah so um you know i just had this sinking feeling that we had some data inconsistency in our database but i just didn't really know for sure and i thought you know i want to know so i made a little project

called danger mouse and its job was to run every day and just go through the database looking for problematic stuff like hey here's a here's a record that shouldn't be in this state for this long something must have gone wrong you know so i did that and i wrote i wrote it up in like a day and it sent out a night a nightly email and and i sent out an i sent out an email before i pushed it to say hey just so you know we're going to start getting nightly emails that explain data inconsistencies that that i can find from this new thing called danger mouse isn't that nifty yada yada yada it should be fun well the first day it ran it found all these problems And we were like, Whoa, holy crap, we have so many problems. And this was one of those cases

where it was like, it was almost the same thing that Matt said in his article, which was like, the CTO was like, great job. This is so awesome. I'm so glad you know, and, and I'm like, wow, this took like just a few hours to whip up and ship. And so, you know, just another example of that. And I think most people have those situations. And like Matt said, the difference can be whether you communicate to the team about it because i could have just set it up to just email me and just fix the problems myself and then the system would be just as better off but the team would be unaware of what was going on yeah and and if part of the problem is the team wasn't aware of the issues then uh i would argue that wouldn't have solved the problem as well that's

true probably not long term right even if you fix the data inconsistencies if nobody knew like oh the way you built that caused this problem then they wouldn't exactly yeah exactly so um wait wait you forgot to praise me dave i am so proud of you for doing that oh man i'm just grateful that my mentorship helped you come up with that idea and you must be you must feel so fulfilled right now you've just really taken taken my advice and run with it and done almost as much as i imagine you could have done with it no that's a really cool idea i've i've like thought about doing that and then i was like and i'll just go back to doing regular work before so it's cool that you you uh you made it happen that's awesome i want to share one blog post that i like is from

2013 it's called do things right about it and it's just by just a person they're not famous i don't even know who they are but I just like their writing and it talks about how you can use this at work but you can also use this just in personal stuff you just do a thing and you write about the thing you're doing and most people don't do that so just by the act of putting words on the internet about what you're doing you'll gain a lot of benefit to it there's not a ton of risk or commitment and there's a potential that other people will get excited about what you're doing So I think it's a good kind of general principle. Cool.

We'll put that in the show notes. Yep. All right. I think we have answered this question. All right. Question answered. Let us move on. Do you want to read the second question?

It has names and I, you just do such a good job of names, Dave. I tell you what I have. I have confidence. You do. I do not want to do this. Just like Apple. Yeah. You're so brave for reading this thing.

Okay, this is from a listener named Maray Rosso. And he says, how do you get your point across effectively so that you don't have to later say, I told you so? You say, neener, neener, neener. Told you so. Isn't the act of telling someone I told you so, isn't that like a valid energy source that powers all of engineering efforts? i thought that was like the gasoline in the engine

uh so dave you there's there's a lot kind of going on in this question i think i liked the interpretation that you said earlier um when we were discussing it before yeah sure share that sure i think i think there's actually two ways you could interpret this question the first one is not very nice i'm going to show that one first and we'll probably set that aside but um the first interpretation is like saying i told you so is kind of mean you know like obviously i think that's probably obvious um but so let's go with the second interpretation which is how do you communicate effectively so that when something goes bad later people are clear on what it was you were saying in the first place and and hopefully so they can avoid

the pitfall that you were trying to communicate in the first place. In other words, it may be that you're explaining your ideas to someone and they just don't quite understand what you're saying. And then things go bad and you're like, that's what I was trying to warn you about, you know? So it's not a, I told you so, I'm the best and you're the worst. It's more like, I tried to, I was trying to help us avoid this exact situation that we're now in, right?

Yeah, I told you so is so like weird and triumphant sounding because say you warned them of some horrible disaster in your company that was looming and then it happened and then you're like, I told you so, ha ha. Like you're in trouble too. You have the bad situation now too. There's not. It's like I told us so.

Yeah. Great. congratulations our database is still gone yeah and i don't think it was this person's intent to be the triumphant yeah jerk the post-apocalyptic jerk yeah yeah i guess if it's all let's go with the charitable interpretation of the ashes at least yeah yeah how do you do so yeah how do you actually share your ideas in such a way people understand them so that later well really so they don't get into bad situations just in general it's it's kind of you could kind of boil it down to how do

you convince people of things right yeah and i think we've talked about techniques for this in the past like interpretive dance it's like totally underutilized yes start there and if that doesn't work then maybe we should talk about some backup stuff sure yeah so what's the backup plan i think pictures help pictures and words on in text form help a lot you know they say a picture is worth a thousand words and sometimes when you're trying to explain like if you do this it will have this outcome you can break it down for people by having a very simple graphic that says like if you do this put it in a box and then have like an arrow pointing to something else you'll and then a big title that says like outcome you know like we lose database you know like um

it's like ah it's for some reason my brain can see a picture like that you know with like circles and arrows and just instantly understand the relationship between what you're trying to say and the outcomes but if you just write it in an email or say it out loud for whatever reason it doesn't have the sticky memory impact for me so i actually made a flow chart and it's here i'll share it in the show notes and it it has two boxes one is dave is smart and there's an arrow pointing to another box therefore jameson is smart um are you are you convinced it's yeah that uh that sounds right it just feels right to me you haven't even seen the flow chart i just told you it existed yeah i've got this picture in my head and i think it's right yeah good so have you have

you used this technique in practice oh yeah try and convince people uh well okay so let's talk about convincing but first let's talk about understanding okay and i think when you're trying to communicate a concept there are two part two phases and they come one after the other phase one is understanding phase two is convincing so understanding in phase one is all about making sure that the idea that you have in your head successfully is transmitted into the head of someone else and that is remarkably hard to do right yeah i mean he's jameson like i have no idea what you're talking about i don't know it seems pretty easy to me no definitely right and uh but but you really can't even get to convincing until afterward but i'll tell you

what if you want to convince someone you better make sure your idea is firmly implanted in their head first then you can move on to convincing and yes i do think that sometimes having a graphic or having a nice document can actually convince people more strongly than the idea standing on its own okay but you're not you're not talking about persuading you're just talking about making sure what you are trying to say is understood by them well that's what i meant by phase one and phase two is convincing and i think a nice graphic and visual can help uh both of those things but i think you wanted to talk about the responsibility that comes with that because just because you have a convincing graphic doesn't mean you're right yeah this keeps me up at night sometimes

where i worry that the people that i'm listening to are very convincing but that doesn't have anything to do with being right um i can understand their ideas well and they could still be horrible ideas but they could just be very good at making flow charts that convince me that that they make sense um but i mean if you're if you're worried about saying i told you so then it's like the last question there's there's a balance and you don't want to be um an absolute ruler that is convinced that they hold all the secrets but if there's something that you're genuinely concerned about then i think it's fine to be worried about making sure people understand and are aware of the problem yeah definitely just don't yeah don't go full-on

cult leader on it so like using like some of these casual game psychological techniques from like mobile games yeah i mean you i got it you could make like a visual where the audience that you're presenting to can actually level up and earn gems as you go through the presentation i think if you put that much effort into a presentation you just win by default though you build a free-to-play mobile game to convince people to use postgres instead of mongodb or something then you got it you deserve it they were like i I don't know what we just did, but I came out with 1,700 gems.

And all it takes is one person in that meeting to pay for the gems, and then your game has paid for itself. As I'm thinking about ways to communicate with people, I keep going to written communication because so much of what I do, at least in software development, is written. There's a little bit of verbal and then a ton of visual, whether it's on a whiteboard, drafting out an idea, whether it's like a google doc or a flow chart or a presentation so i'd say 80 is written and visual

as opposed to verbal is that about what you think you've done too yeah i would say that depends so mine is definitely more written than and visual than verbal i think i'm a less visual person than lots of engineers but it's still definitely weighted towards words or pictures okay interesting so um so when i think about ways to communicate ideas like for example cause and effect like say i've got a cause and effect situation if we make this technical decision these will be the positive and negative outcomes you can show that visually with a little flow chart or you can just write it down like a list of bullet points and for some reason when my brain sees a list of bullet points i interpret that as an unordered set just a list of things like a bag of words kind of thing

but when my brain sees a flow chart with boxes and arrows with like pointers on one side of the arrows uh suddenly i now my brain instantly recognizes that as a time like a temporal flow and a cause and effect like this then that then that and um it makes a big difference in the way that i process that information so figuring out a way to visually organize your information can help your readers brains uh quickly recognize the concepts you're going for instead of making them really dig in and have to invest because guess what people don't actually like reading your long emails or your presentations you know and so the the more the the faster they can process it with their human meatware the the better yeah yeah that's a good point it also communicates

something about your uh i guess your commute your your commitment to the decision if you're willing to put the time into making some kind of visual instead of just stand up and say we're all doomed unless you listen to me then uh yeah yeah it just feels like a little more solid again can be used for good or evil use it for good i also want to bring up a point which is uh there's there's making yourself under making yourself be understood and there's also um perceiving if you are being understood or not and it is it's very possible that people understand you and they still disagree with you and you think this is impossible they must not understand what i'm saying they they might just disagree with your points or something like that

right maybe they fully understand but they believe you are wrong yeah and or go ahead no no you i insist no no no no you go ahead i already forgot what i was gonna say so you have to go ahead I was going to say the other side of that coin is that they don't understand but sometimes for whatever reason in human to human interaction we are scared to admit we don't understand and so giving people

like a safety net to be able to express that they don't understand without making them look dumb is an important part of communication and so one of the ways you can do that is with a little bit of self-deprecation you can be like hey this is a hard subject for me to explain

i feel like maybe i'm not coming across how is this coming out and then and then the person receiving is free to go i'm a little foggy instead of them feeling like they're dumb you can that you can take on some of that wait for them and say look i'm having a hard time communicating this to you it's me not you and then they can feel safer expressing their misunderstanding yeah i like that especially in this kind of i told you so uh late in situation it could be a little a little tense and if you can open it up that way it might make people less defensive and more willing to understand each other another thing you can do is you can back up your points with solid evidence and i'll give you an example of this uh i'll give you an example of this doing being done poorly

so i used to work at a company with a lab and i had like a raised floor and we were getting a shipment of servers and server racks and they were pretty heavy and they were being delivered and one of our engineers said hey whoa whoa whoa we can't put those in the lab the the raised floor will not support that much weight they'll break through the floor and and everyone was like oh crap well the racks are coming right now and we told the customer we'd get them like stood up like right now so what do we do and he's like well you can't put them in the lab and that's all he gave he didn't give any data points he didn't say here's the spec for the floor here's like a document from the vendor you know here's the weight of the equipment you can see clearly that it'll that

it won't hold up all he said was it won't hold so he made an assertion without giving like evidence behind it like data points to support it and so at the end of the day his advice was actually ignored and fortunately the floor held fine so he never had to say i told you so but but you can see he wasn't taken as seriously as he could have been if he had said hey i looked up the vendor spec for the floor and i've got this data point and it says here you know it can only support this many pounds and those racks weigh twice that so you know he didn't do that so if you're coming up with some kind of problem you need to have some kind of evidence behind it to really be taken seriously otherwise it's just an assertion and guess what as software developers we are constantly

bombarded with assertions that aren't true right like all the time do you feel this way jameson i do yeah i'm actually gonna talk about this in just about a week at an upcoming conference yep yeah we we we pretend like we're scientific and data-driven and it's so untrue software is all about storytelling and and anecdotes and convincing people and chest pounding i mean what chest thumping is that the right yeah i think so i think chest pounding is when you like bump into someone else and chest thumping is when that's that's chest bumping oh shoot we need a taxonomy where's Linnaeus save us Carl oh man soft skills engineering is your top source for Carl Linnaeus themed jokes

it's a deep cut uh but yeah so you were saying i can't remember what were we talking about as as software engineers we consider ourselves to be scientific but we're often oh yeah yeah no how often have you seen like rich hickey stands up and gives an amazing presentation about closure and there's no data there he's just very good at presenting and he just says words and you're like yeah that makes sense and you have great hair and then you just switch to closure and that's that's how the decisions are made i came to closure for the hair but i stayed for the s expressions yeah yeah that's that's how like basically every technical technical decision ever feels like it's made to me and and especially how the broader themes of the industry are driven

anyways but i mean even even easily verifiable stuff i mean it's one thing to say choose a programming language based on a feel but there's easily verifiable stuff that i am bombarded with that's false like hey if you don't pass in that timeout parameter your program is not going to work right i'm like well how's it going to break i don't know it's just not going to work and it's like okay well i didn't pass it and it's working in production so it's fine right like people say that kind of crap all the time and so like i find myself to i find myself becoming more and more skeptical of and i don't mean like as a life view but just more like okay a human being said some words to me and i'm gonna put them in like a little bin and then later i'll pull them out of

the bin and inspect them a little more and see if they're right you know that's just kind of how i've become yeah that makes sense um do you do you want to kind of sum up what we talked about this question yeah so first of all don't be a jerk which i don't think our listeners was trying to be a jerk i think in fact he put i told you so in air quotes which i think is a good indication that He is not looking for that kind of meanness. A picture is worth a thousand words. Try to organize your information in such a way visually that people can process it quickly. Not everybody is a visual learner, so you may need to write a song.

And that might also work. Dance was mentioned. Also interpretive dance. Jameson will write songs for money. They have kind of weird rhymes. and uh there are two parts of communication when you're trying to explain a concept or a risk and that is understanding and convincing and i think understanding must precede convincing and also if you're willing to write a document of some kind or you know put in some effort into communication

it will carry a little more weight to the heart and mind of the receiver of the listener to make sure they know how serious you are about this and then make sure that your uh data is or that your argument is backed up by evidence and not just um you know you having great hair yeah dave you've talked a lot about the kind of the art of of making yourself be understood and be convincing if if you're in this tricky situation where you're worried about saying i told you so there can be a lot of other kind of human or political factors at play and i don't i don't know how to navigate those safely the thing i try and do is um make stateless decisions and and by that i mean you just look at what you have right now you don't worry about like whose

idea this thing was or the ceo said this thing we tried it five times already like there's a lot of context around stuff that is unhelpful but still affects the decision and if you can filter that stuff out um i think you yourself can try and be a point of of reason in in the decision making process so it's like functional decision making it has to be a pure function that only operates on the inputs and returns consistent output yep and it's just easier to reason about i hate that phrase and you can unit you can unit test your decisions a little better yeah exactly all you do is set up the company in the exact same way and then try it try it out but yeah they're just just that that stuff will get worried about plenty without you

also worrying about it so if you can if you can avoid letting that influence your decisions then i think you'll be better off awesome question answered we did it thank you dear listeners jameson what do people do if they want to share the soft skills engineering love with their friends or enemies so there are two ways to do it one is um you find a smooth stone from a lake bring it back boil it for four hours grind it drink it into a powder and then say soft skills soft skills soft skills three times in the mirror that's the first way okay good and if you don't want to do that please uh you can rate the show on itunes you can subscribe on itunes even if you don't use itunes it still helps in letting other people know about it

and just tweet about it. I think that's how we've gotten a lot of our listeners is through people tweeting about the episode. So please continue to do that. Yeah, it's great. Also, if you want to send us questions, you can do that publicly on Twitter or through direct messages on Twitter

if you don't want to share the details or if you feel like there's just a lot to your question that might not fit in the tweet. Awesome. Thank you very much, dear listeners. We love you. We'll catch you next week.