Soft Skills Engineering - Episode 2: Influencing your team and dealing with anger

Episode Date: March 14, 2016

In episode 2, Jamison and Dave answer two questions: I work on a team, and I am not the team lead. I have lots of ideas for how to do things better. How can I influence my team without being the team lead, or without stepping on his or her shoes? How do you deal with anger at work, both on the receiving and giving end?

Hello everybody and welcome to episode two of Soft Skills Engineering. I'm Jameson Dance. And I'm Dave Smith. And we're here to talk about everything besides the technical stuff that goes along with engineering. The everything else. Yep. So how are you doing Jameson? I'm doing well. I've got the like Tom Waits cold, which makes me sound like Tom Waits. And that's sweet. It's an enhancement.

Yeah, it's not too bad. And I didn't have to like gargle vodka or whatever he does. I'll be honest, I actually don't even know who that is. Oh, well, he sounds like, how would you describe it? He sounds like the Cookie Monster. Like, like he sounds like death metal vocals, but if he's singing to jazz. Okay. It's, it's kind of interesting. That's great. So, Jameson.

yes why why are soft skills called soft skills and not hard skills oh geez uh some of it might be because of that like stupid engineer bias where everything besides like machines working together is boring and lame so like the hard stuff is what's important because it's harder to do i mean that's totally wrong that's why we're doing this podcast but or maybe is it because hardware and software yeah it could be that like your brain is software stuff meatware wet wet yeah wet oh yeah wetware that's a thing isn't it yep they should call these wetware skills yeah i think that's that's what we'll call it when we arrive at the cyberpunk future well we're here at episode two and uh we've survived one week yep it's great so thanks to our uh three listeners

including jameson's mom yep it was really really great to have you on the show she said it was great. She really liked the show. Great. Thank you. Thank you, Mrs. Dan. So I had one piece of feedback from our first episode from a listener named Evan Ferrer. And you may recall that last week's show was about, one of the questions we answered was, how do I know if I should engage in an opportunity to like join a startup or something, or my friend has a crazy business idea and wants me to join, right? And Evan said that he wished we had mentioned one thing, and I want to share with you what he said. He said, I hoped that in the answer to the first question

that you would point out that sometimes people expect that their only contribution to a new company is coming up with a killer idea and that you will then do all the work and put in all the time and they will keep a sizable portion of the company. Lots of people have killer ideas. They're a commodity.

So says Evan. So thanks, Evan, for that. What do you think about that, James? And you think he's right about that? Yeah, I think he's totally right. I guess my assumption was that this person would be in it for the long haul with you. But if they're just like, hey, no one's ever thought of Craigslist, but only in my small

hometown, and you go build that, then that's kind of like, yeah, obviously, you don't want to work with that person. Yep, totally agree. So thanks for that, Evan. And thanks for listening. Yep. So you may have noticed our format from last week. We take questions from you and answer them on the air.

But I think Jameson and I would like to take a minute and just tell a little bit about ourselves. Um, uh, so you can know like whether, I don't even know, like maybe we're just a couple of guys off the street with ideas, but you know, we have a background in this stuff and maybe it's worth sharing. Sure. So I, I kind of came late to software. I didn't start programming until my sophomore year of college, um, just on the recommendation of a friend. So I wasn't one of those wonder kids with a calculator building games at age seven or something. Um, but I've been doing it for almost 10 years now. Uh, I've worked at a few different places. I've, I've been just kind of a team member. I've, I've led teams. And, uh, right now I'm working in a place called

Kowali where I build open source education software with, with a small team of other people. That's kind of my background. Cool. I have a pretty similar background. I got into programming actually my sophomore year of college as well. Oh, cool. But that was like a different year. no I've been working in the industry since 2003 worked I've worked for basically four companies since that time varying amounts of time at each company I've been a team lead I've been I'm currently the director of engineering at HireVue got about 30 developers and a dozen or so QA people whose efforts I'm responsible for coordinating and serving so I've you know not been around forever but certainly not uh fresh blood as they would say right no fresh meat that's

the right term fresh blood sorry as the vampire development community calls it my soft skills are not that strong basically part of soft skills is using the right words okay so why don't we start with our first question james yep i'll kick it off so the question is i work on a team and i am not the team lead i have lots of ideas for how to do things better how can i influence my team without being the team lead or without stepping on his or her toes this is a really i assume this is a really common thing because there are there are fewer team leads than there are team members so so this applies to a ton of people yeah um yeah and good for you by the way for having ideas for how to do things better that's great yeah that's true i i have been guilty of being just like the

lump of inner metal that just like sits in his chair and is like man it sure sucks when we do this too bad there's nothing i can do about it yeah yeah i'm totally helpless i'm just along for the ride yeah yeah so that's cool uh my first thought is a propaganda campaign with um like that obama style hope hope and change hope and change and unit tests is what maybe your slogan could be and you just post them up around the office and then maybe you start some rumors like wow that that mary person she's got ideas have you seen the posters that not her that someone besides her put up yeah mary definitely didn't make those yeah uh that's a great that's a terrible idea jay

yeah so i've set the bar low what do you got that could top that So, I've been a team lead, and I have to tell you that as a team lead, I love it when people come to me with ideas for how to do things differently. In fact, every team I've been on, I will ask this question repeatedly, like, hey, what can we do better? And currently, I meet with about a dozen different engineers in monthly one-on-ones, and I always ask them, like, hey, what can we do better, faster at our company? And I've actually been recently asking questions like, if we could tear down the whole organization and all the process and build it from scratch, like say your supreme leader for a day, how would you build it? And it's actually very rare that people have ideas when you approach them that way.

So when people come to me out of the blue without being prompted, I love it. And I think the best thing to do when you have ideas like that is to go to your team lead privately and say look i you know be respectful of the position that they're in don't undermine them and and especially like if you're sitting in a team group setting don't like say well that idea is really dumb you know or like our team lead doesn't know what he's doing those can be really undermining and toxic on a team so the best thing i found is you go to the team lead privately and say hey i love what's going on in the team i love being on the team and i have a couple of ideas i want to share with you that i think will make it better and i think

most people respond very well to that yeah i know that when i was a team lead i uh one of my big fears were that people were just silently unhappy with the way things were yeah me too and they were like man this jameson doesn't know what he was doing if he only did this thing like tell me that thing i would love to know what that thing is yeah definitely um one so another since i'm the person that says the dumb things another bad way to do this is just like stick it in so we we talked about like kind of just jamming react into your project last time and if your idea is use react again a bad way to do that is just use react and submit a pull request it's like here's this feature i hope you don't look at the package.json because it changes stuff yeah um

Because doing that in kind of not a systemic way can often lead to just half-baked ideas kind of scattered around the code. And that makes it harder to understand than if you had just one core principle, even if it might not be the best way to do it. If you're consistent, there's a lot of value in that. I agree. And also when you sneak an idea in, it can really backfire because your idea carries along with it people's opinions. So, like, if you approach someone and say, I'd like to try this idea, and then they get on board and you try it together, even if it's a terrible idea, somehow those ideas will go farther and do better. Whereas if you sneak it in, even if it's a great idea, you sneak it in and you kind of go around the team, the team is likely to reject your idea, even if it's the best idea ever. Oh, I have.

That exact thing happened. So, this was at my, I would call my first real job. I was working with someone who's very smart, who I respect, and has influenced me a lot today. And this person was way into functional programming before I was and was all about Haskell. And they kind of just like took a feature and totally wrote it all themselves. And it worked great. But the code was, it was in JavaScript, but it was completely like all in on functional programming. currying everything partial application everywhere um all these concepts that i wasn't familiar with

at the time and the team just got so mad at him because uh it wasn't like a here's a here's some cool ideas we could try it was like just this code bomb in our laps and then we kind of had to maintain it later and every time we didn't understand it we just raged which was not a good way to deal with it but yeah yeah but any new idea is going to have downsides and if you're not bought into the idea you're going to hate it that much more when you see the downsides so and the hate might sometimes trickle over to the author yeah the idea and that's when things go really bad yeah yeah and i mean i think functional programming is a good idea it has lots of new concepts though and and a bad way to introduce them is to just like airdrop them on someone

and then say, good luck looking up what this function does because you can't. Incoming! Oh man, so bad. Yeah, so don't do that. Even if it's a fantastic idea in your mind. Also, you might be wrong. You just might be wrong.

It might be a bad idea, right? Which is why I like to, whenever I propose a new idea to a team, I like to also include an escape hatch. And that's a metaphor. But I say, look, team, I want to do this idea. If it doesn't work out, here's how we're going to bail on this idea.

you know like so for example i want to try kanban instead of scrum um you know maybe we're like a hardcore scrum shop and i say i want to do kanban instead and i so as an escape hatch i'll say let's try kanban for two weeks only and limit it and then i'm going to schedule a meeting after two weeks where we can assess whether things are going good um and i usually would as a team leader you could just do that but as like a non-team lead you'd need to go to the team lead and work that out and then let the team lead bring the idea to the team. I think that's actually really important that you respect that, that like authority. And I'm not like a huge top down kind of guy, like I like ideas to trickle up from the bottom. But for some reason, these ideas tend to work better that

way. So anyway, escape hatch after, you know, a couple weeks, or if it's a code thing, you can say, well, here's, here's our plan to get out of this, if it goes bad, you know, always include that. And then I think the team is more likely to go like, all right, and get behind the idea and rally if there's an escape hatch and they don't feel like they're going to be stuck sure um one more thing i'd probably consider if i were doing this is that um there's always a cost to some idea and the the cost might just be the education cost or the cost of changing the existing code to match it or something sometimes when you get really excited about something um it can be hard not to be zealous about it where where you just see it as the pure good and there's nothing wrong with

it and there's no downside um but but there is some downside and and just yelling like but this is better that won't really solve anything um so so you need to recognize that there are still trade-offs associated with it even if the trade-offs are just teaching everyone the new better way to do stuff yeah yeah i mean best case that's at least there right yep totally yeah So the other idea I had on this one was when you're bringing a new idea to your team, it's really important to separate your ego and your own self-worth from the idea. So that way the team is free to reject the idea without rejecting you as a person. And so I found a few phrases I use to help go through this process. Like whenever I pitch an idea, I'll like try to say, look, I'm not married to this idea.

you know and I say that up front so that people know okay if it's a bad idea they can share their reservations with me without feeling like they're going to hurt me and that gives people permission to be honest and I think that helps a lot so you can say things like I think this might work I think it might be pretty good here's my case for it it might not work I'd like to try it out and see if it could be good for our team right so those kinds of phrases are much better than hey this react thing is way better than this uh backbone thing we're doing and we need to do it like right now you know because then it's like well you're the react guy you know yep you're tight you're married to that idea and if we reject that idea we reject you and no one really wants to

be the rejecter yeah so separate your ego from the idea yeah um i i had a thing i was gonna say and it's gone oh that's a good technique wisdom was lost i'm sorry was it about hope and change no not not directly i mean everything i say indirectly is about is about hope and change oh so i have one more it's gone um i have one more idea on this topic yeah i'm sure maybe as i'm talking your idea will come to you i hope so so when you're proposing change or new ideas to a team team lead or to a team um i found that it's best if you can do so in bite-sized chunks and this goes with the escape hatch idea but you say um i want to try

this in a limited fashion i want to do like a prototype um i want to build something small or do a small feature this way or just say i want to have just a few people on the team do this new process whatever the idea is make it small and and bite-sized don't force the team to go all in on your new idea because then when you go all in the risk level goes way up right and so if you fail it can be like a catastrophic failure instead of just a small failure there's this awesome quote from uh oh is his name kent beck the agile guy he said um even the most uh catastrophic plane crash is not so bad if you aren't that high on the ground off the ground and i'm totally paraphrasing that but basically saying you can crash the plane if you're only three inches off

the ground, it's not going to hurt, right? Your plane can crash. And so if your idea crashes and burns, but you only really got a few feet off the ground, then no big deal. Sure. So I would say that. So instead of listening to what I'm sure was a great point you just made, I was thinking about my point. Just kidding. I was listening. While I was listening, I remembered it. I think there can also be different phases of a project. Sometimes you might want to just try a bunch of crazy things all at once kind of like scatter ideas out to the wind sure sure you've heard maybe the let a thousand flowers bloom but then after that there's eventually some phase where you want to consolidate on some core ideas and and i think that can be a good process to try

things out and know that hey we we are going to refactor some of these bad some of these things that turn out to be bad ideas we're going to refactor away but hopefully we'll arrive on a better end point than if we had just stuck with something without trying anything new yeah yeah it's kind of like a scatter gather type thing yeah yeah yeah and if you're gonna if you're gonna let a thousand flowers bloom you're gonna have to prune oh yeah a bunch of those ideas yeah like 950 of them right yeah one of my one of my friends is um kind of leading a i guess a sibling project at the company and he's in that phase right now and it's actually really really cool to see where we tried all these crazy things

and now they're kind of consolidating and cleaning up and it's making a big difference in how easy the code is to work with. My last suggestion is just be a worm tongue and kind of like be the power behind the throne and if you can ensorcel the team

lead and manipulate him or her then that might work too. Put them under your spell. Yeah, yeah. But don't be a jerk about it, like worm tongue. well don't let anybody find out i think it was fine until he was discovered everything was great yeah until he was discovered yeah it's true so um yeah so in fact i i have

found that it can be a really great place to have a lot of influence but not necessarily have all the responsibility oh it's so good it's so good that's a keep that in mind if you're jealous of your lead's power if it fails you're not on the hook you just brought the idea up to the team and then it didn't work out. It wasn't my fault that your idea sucked too late. It wasn't my fault that you were too foolish to appreciate the true majesty of writing everything in white space.

Should we move on to the next question? Yeah, let's do it. I'll read this one. This is a short one, but I think we could talk a lot about it. I've got a few stories. Okay, so the question shortly worded is, how do you deal with anger at work?

And I think everyone gets angry. uh occasionally sometimes you're on the receiving end and sometimes you're on the giving end and so we should just explore this and see where we go yeah what do you think james and have you ever been angry one or one or two times um i think the the first thing to note about this question is there's a difference between um maybe transient anger and a toxic environment and if you work in a place where people are angry all the time and and one of the accepted methods of communication is just like yelling and insults and stuff maybe that's fine for like the military i don't know there are probably places where that works okay boot camp but yeah for me like it's time to pack

your bags and move away you are not responsible for fixing that environment uh yeah i agree with that unless you're like the ceo or something um sure sure but if if not just bail like there's nothing that's worth suffering through an environment like that so that's kind of a preface to it so let's put that environment aside and say that you know let's now let's deal with like the more not insane yeah where people are friendly and happy but there's just some tension going on or something yeah yeah so i've got a story should i tell please i was working on a project and it was my first time being a lead of a pretty big project we had probably like 20 people working on it and I was technical lead for the project on the software side of it and there was like a

more senior team member who was responsible for my project and several others and since it was my first time I'd go to him a lot for suggestions on how to proceed and we were selling products to a customer who required a pretty heavy degree of documentation and process and stuff and rigor and so I had just been in this guy's office and I was talking to him about it and he was like okay it looks like you're good and he was helping me through some of the processes and stuff so right after that meeting I had a with him I had a meeting with the whole team and I sat down and there's about 20 engineers in this room and I'm standing up at the front of the room and I'm saying okay we're at the point now where we need to move away from our documentation phase and into

like let's start laying down the code and getting this product built right this is a very waterfall company at the time so it's like we're done with the design documentation now let's move on and we really need to move i i emphasize that we needed to move out of documentation and into the like coding time and for whatever reason this really rubbed this guy wrong who i just had that meeting with he came with me into this next meeting and he stood up in front of everybody and uh pretty much yelled at me um in front of the whole team and it was just it was so humiliating and i just felt so stupid because i had just been in his office going over the project plan and it's like he had all these problems with the project but he waited to tell me about them until we were in

front of everybody instead of in you know in private and it was just it was just humiliating so that's an example of what i would say don't do that to people yeah you know wait if you have criticism for someone you're angry at someone do it privately like you owe it to them to communicate to them usually if you especially if it's serious but do it in private um and you'll save yourself a lot of hurt yeah that's a good point um i'm still i'm still licking my wound i mean i don't think anybody reacts well to to public humiliation yeah um so i have a story it's kind of related to the last point actually uh about experimenting with the new ideas and kind of tech choice and stuff like that so uh recently at work we were experimenting we were talking about experimenting

with some new front-end technology. And we talked about it all as a team. There was going to be a small group of people that actually worked on the project using it, but it was part of a larger team. So we kind of got the larger team together and talked about it and talked about the pros and cons. There are some downsides.

There's some risks. But we kind of talked about mitigating those risks and whether we thought it was acceptable or not. And we came away with the decision to proceed in kind of an experimental fashion for a few months and and then re-evaluate later on uh and that was going uh okay i think i think it was going pretty well there were some minor issues but nothing earth-shattering i feel like um but uh people that weren't on the project i i think had some underlying concerns that they didn't feel

like were resolved at that first meeting so there's kind of not anger but some some uh i don't know some uh i can't think of the word right now that's just what kind of day is some reservations yeah some some unresolved reservations that kind of kept coming up um so so part way through this trial period we ended up having another meeting to resolve those and we ended up deciding to just scrap the project and and start over in a new less risky technology and i did not react well to that at all um i i didn't like rage or blow up or anything uh i i avoid conflict pretty as like my primary rule of existence so so i wouldn't like yell at somebody ever but i i was so frustrated by that until pushed hard enough uh no i don't i don't

think so i i would just like pack my bags and move away um but i'm out of here yeah but i was so frustrated with the way the decision went down and and and so angry about it and i just like disappeared into my little cubby and put death metal on my headphones did you just kind of fume yeah i did i just fumed for a couple days i didn't get anything done because every time i sat down to write a line of code in the rewrite i was like this is so stupid we're so much further along it'd be so much better if we use this other thing it's going great it had all these reasons um and and the team reacted so well uh like they they noticed that i was they're like where's yeah why why can we hear music through his headphones i usually can't hear the death

and then why when i look over his shoulders the song called the satanist that's weird that's not usually the kind of genre that he listens to um and and so people kind of like noticed and and pulled together another meeting where we were able to productively resolve our concerns and and it wasn't ever personal anger it wasn't like i'm mad at this okay person um so there wasn't that tension of like interpersonal conflict it was just uh me being upset at how the situation worked and then the team responding really well um by like not i mean they could have been like man jameson's really petty i hope he gets over it or they could have ignored me or they could have sure a lot of different things could have happened but i feel like that could have gone

toxic bad yeah yeah and and i feel like because the people i work with are very nice and are good at the soft skills stuff they they noticed and then we were able to arrive at um i think both a good technical solution and also a good uh like interpersonal solution so there's a lot to be said for um kind of knowing your team well and paying attention to their mood and and noticing when And decisions that you think are resolved aren't actually resolved because that happened a few times in that story. And I think we would have been worse off if we had just never had the second meeting again. And we would have also been worse off if we never had the third meeting where everything kind of got resolved. And good on your teammates because sometimes it's really hard to read other people, especially when there's a slightly bigger team, you know, five or ten people.

it's like pattern matching off each of those people's behavior every day and then noticing an outlier that can be really hard yeah you know so good on them for for noticing yep yeah another thing with that story is when i was mad i was totally useless i got nothing done for two days and some people i think can kind of like rage code um but but i i cannot use your anger yeah exactly um so so there's a cost to anger beyond just the tension it creates in the team which is that it it's hard to be a productive uh member of of the team if you're really upset about something and that can go that can become a vicious cycle right yep yeah because then you get you get talked to about not producing and then you probably and you feel even more frustrated right yep yeah that

that's rough well good on good on your team and good on you now if you could go back and do anything differently do you think you would yeah i think i think part of this was caused by my um aversion to conflict because i i didn't stand up as strongly as i felt and so i kind of just let this decision happen that i disagreed with because i didn't want to uh i didn't want to to create tension or conflict which ended up creating more conflict down the road ah yeah paradox yeah so i think if i had uh stuck to my guns a little more i either would have been i i think convinced and actually accepted the solution or i would have convinced other people and yeah and then avoided a couple days of of grumpy town grumpy death metal town all right well i have a story please

please share two two times in my uh short and illustrious career i have yelled at someone at work twice so i'm not not proud to admit this but i'm gonna tell one from about 10 years ago and uh anyway this is you don't hear a lot of these stories because people don't usually air their dirty laundry like this but here you go on the internet forever yeah fortunately this is just you know our mothers and a few close friends who listen to this but um i was on a little project it was a one person one engineer project it was me and then they had a manager who was responsible for the finances and the schedule and stuff and at this particular company we had a really strange financial incentive system we were working on billable hours which means that uh we charged

the customer for every hour of engineering time and there were some times uh i think we called them like money would turn into a pumpkin which means like there's a time limit on um how long you had on the calendar before you that money would disappear so if you didn't burn up the money uh then the rest of it would be gone and so my manager so you had to bill a certain amount of hours or they wouldn't pay that chunk. No, no, no, no, no. It was more like we have a hundred thousand dollars to give to your project and you have until June to use it. And if you, whatever you have left when June comes around, we're just going to keep that. Okay. That makes sense. So it's not, it's not a fixed price. It's like, we're going to pay you by the hour, but if you don't

spend enough, we're going to take our money back. Sure. It's weird. Okay. That sounds like a weird incentive already. I can tell you more details later. It is, it's kind of weird. So I was working along, chugging along on this project and the manager comes in and says, I'd like to add so and so to the team to help it go faster. And I'm like, no, that will not work. This particular person they wanted to add would not have gone faster. They would have needed a lot of ramp time and I had actually had some bad experiences with this person in the past. And we were late in the project, like we only had a few weeks left. And so it's like, there's no way at this late hour adding someone is going to help. Now, sometimes it does help, but in this case, I was quite

confident that it wouldn't. And the manager pushed on me really hard. Like, come on, you just got to let this guy join the team. Why aren't you letting him join the team? And I finally, he just, I cracked and I was like, stop it. Like, I'm not going to let this guy join the team. It's not going to help. You know? And I actually raised my voice at him. And when I did that, he like backed down immediately. He was a much more senior person and he could see that I was uh, not in a good place emotionally. And so he walked, he basically walked away at that point. And I felt, I felt pretty bad, but not as bad as I felt the next day when he came and apologized to me. And he said, he basically said, I'm sorry. I understand where you're coming from. And I was

like, oh my gosh, have you ever had someone apologize to you, Jameson? And you're like, no, no, no. I'm the one who should be apologizing. Many times. Yeah. And so it's one of those where I was just totally humbled. I felt so bad about yelling and it was just dumb, but I was so angry and he was pushing and I didn't understand this broken incentive system at the time I was really junior, you know, like to me, I was like, I want to build a great product

and have it done on time. And to him, he was like, I want to get this money or we're not going to get it, you know? And so both of us didn't understand each other. And so the result was anger. So I'd say if you're ever really angry at someone, take a moment and really try to understand their motivation and this can be hard but until you do you're gonna just be mad because you're

gonna think you can just think oh this person's just dumb right like they're doing dumb stuff or or even worse than that you can ascribe to them some uh some kind of manipulative motivation yeah like foul play like they are trying to make themselves look better for a promotion or and sometimes that's the case and that might not be a bad thing but but you could be totally wrong yeah exactly so and i was like i just had no i actually just had no idea what this guy was talking about he just wanted to make your day bad yeah he's like this guy just hates me yeah it's very unlikely that someone just hates you right i i think an interesting common thread in in those stories well in the two i guess successful anger resolution stories are um

kind of kind and empathetic teammates that that are willing to solve the anger problem and and maybe that's where the solution comes from that if if you are angry or if you're working with someone else that's angry someone needs to kind of step up and and be humble and figure out what's actually going on and apologize if you need to even if you're not convinced that you're wrong i mean someone kind of needs to diffuse the situation because it won't resolve itself well on its own yeah exactly like the natural inclination the inertia will take it to a bad place yeah and even if you you kind of calm down or the other person kind of calms down there's still that kind of lingering resentment that will stick around if it's not yeah yeah and you have to

just step in and say i'm going to cut this off yep and so i i would say that the advice that i would give people in this situation which is not advice that i have taken myself very well because it's hard is when you feel yourself getting angry try to step out of the situation and stop and think about the other person's perspective and try to figure out what their motivation is and make that your challenge instead of saying like how can i win the anger match you know you say how can i understand them and i think you'll find it it's a lot easier to resolve these conflicts it doesn't always work yeah i've had a couple i've had one other instance where i'm like i just I tried and tried and tried and I just couldn't get it to work out, but, but it can.

Uh, I think the other solution or the other takeaway we've had is that you yelled at somebody and you got your way. So problem solved. The volume of your voice is key. It's, I mean, I say that in jest, obviously, because the, the, the benefit of getting your way does not outweigh the cost of, of using anger to get your way. like long-term that's going to kill your team and you'll win the battle you'll lose the war doing that somebody you'll quit or you'll get fired or some a bunch of other people quit or yeah yeah

it won't it won't work out well the ripple effects yep well that's all i have for that james and you have anything else uh no i think that's about all i got well i've got some announcements please uh soft skills engineering is on twitter we are a real grown-up podcast you can find us at soft skills eng we'll be posting links to shows as they become available there and we are on itunes uh which means if you are on an i device you can just go to the podcast app and search for soft skills engineering and we will come up um and i suspect for android users you might be able to also search using your podcast app of choice yeah itunes is often used as a kind of directory for other podcast apps even if they're on android or not associated with apple

at all so we should show up on most podcast apps now all right that's all i had so jameson how can people get in touch with us if they would like us to answer one of their questions uh i think we should ask them to tweet it at soft skills engineering that seems like a good way or if you don't like that just tweet at either dave or i um i'm jergeson on twitter j-e-r-g-a-s-o-n and i'm dj smith 42 on twitter and again you can tweet us at soft skills eng on twitter as well so you said that thing about itunes but you didn't say the traditional second part which is if you like the show be sure to subscribe and give us a rating uh people i don't actually i don't actually know where to see said ratings so um i think they affect your ranks in oh in the

different categories so if more people subscribe and rate you then you get a higher rank which means more people listen and as you can tell we've got zero sponsors so that won't affect our lives at all but we just want people to listen to the show yeah and then let us know if we can help and uh you know if there's any questions you have we would love to answer them yep all right thanks all right thanks everybody see ya