Soft Skills Engineering - Episode 348: Making too many mistakes and low code career risk

Episode Date: March 20, 2023

In this episode, Dave and Jamison answer these questions: Hey Dave and Jamison, long time listener of the show. looking to get your advice on dealing with guilt at work. Lately, I’ve found myself in a lot of situations of having to deal with bugs/incompleteness after pushing out a feature. It’s not my intention to be careless and I do feel like I’m giving it my 100% but there seems to keep being thing after thing that I’m not catching. It’s impossible to sweep these things under the rug when you have to put up a follow-up pull request to fix something that was clearly your fault. I feel like every once in a while is okay but when it starts to become a pattern, I wonder how this may reflect on my performance review. My coworkers aren’t letting on about any frustrations they may have but every time this happens, I can’t help but feel shameful of myself and it’s causing my anxiety to hit the roof. I’m waking up for work each morning wondering what’s it gonna be this time and feeling pits in my stomach. Please help. What are your thoughts on low-code platforms? I feel they will end up like WordPress (small companies with the tools in a varying degree of spaghetti that pay a contractor to clean up) I found myself on a team that wants to use it, and I feel like it’s a detriment to my career. I feel like another employer won’t take me seriously in an interview as I try to explain my way around it. Is this something I should be concerned about being in too long? I’ve voiced my concerns, but it doesn’t seem like direction is changing. What would you do? How do you feel about low-code in general?

it takes more than posting tons of content on linkedin to trick your manager into thinking you're looking for work so that they give you that promotion you asked for to be a great engineer this is soft skills engineering episode 348 i'm your host dave smith i'm your host jamison dance soft skills engineering is a weekly advice podcast for software engineers who just want that promotion and will do anything either ethical or not to get it we've just entered a whole new world of grifting enabled by these large language models generative ai just a button click away used to be you had to outsource this stuff now you can just generate it now it's already all been outsourced for you should i thank our patrons dave do it i

want to thank systematic guy anthony ongaro kyle boss connie lee santa hopar noah frazier loge Kent C. Dodds, Jenny Kim, Owen Shardell, Craig Motlin, I Love Mavis, The Stochastic Parrot, Alice Jost, Nanden Houten, Ohio, Patreon.com.au we're hiring, Ira Chan, Monkey Face Emoji, Jonathan King, Testing is Document. I think this is pasted wrong because it says

testingisdocument.org. And if I remember right from many years, it's testingisdocumentation.org. Documenting? Documenting. Testing is... It's one of those three. Old Apple Fadier,

Will Angel, pronounced like that town in Ohio slash scotland with an unpronounceable name nick hathaway travis sanders braden canes john grant bartek tatkowski cody sale nick cantar and philip john basile thank you thank you so much we appreciate your support because it makes us feel good and also because it pays for the costs of producing the podcast which are non-zero so this helps helps keep it going thank you if you would like to contribute to the podcast help keep it going as well you can go to soft skills.audio and click support us on patreon any dollar amount will get you an invite to our slack community and any dollar in amount above whatever the amount it says it is is it's parameterized

look this up yeah yeah i'm yeah i've generalized this that's true i don't have to look it up now in case we jack our rates way up in the future the audio will be listeners won't be able to come back and yeah be like where this used to be you'll never know anyways there's there's a reward tier where we say your name or some stuff you want us to say some of these are names some of them are not and you know play in that space we think some of them are names i don't yeah we'll say whatever you want pretty much with the with editorial rights yes thank you we appreciate it do you want to read our first question dave i do this comes from an anonymous listener who says hey david jameson longtime listener of the show looking to get your advice on dealing with guilt

at work lately i've found myself in a lot of situations of having to deal with bugs or incompleteness after pushing out a feature. It's not my intention to be careless, and I do feel like I'm giving it my 100%, but there seems to keep being thing after thing that I'm not catching. It's impossible to sweep these under the rug when you have to put up a follow-up pull request to fix something that was clearly your fault. I feel like every once in a while it's okay, but when it starts to become a pattern, I wonder how this may reflect on my performance review. My co-workers aren't letting on about any frustrations they may have, but every time this happens i can't help but feel shameful of myself and it's causing my anxiety to hit the

roof i'm waking up for work each morning wondering what it's going to be this time and feeling pits in my stomach please help oh ouch my stomach just got a pit reading this i'm guilt-free i know that is not true i have recorded audio evidence maybe even hundreds of hours recorded audio evidence if only okay i have one thought which is that breaking stuff is correlated with changing stuff so one way to look at this is you sure are doing a lot of stuff that's true if you're if you're breaking things if you get nothing done you're probably not going to put any bugs in you know related to that if people notice what you're breaking, that means it's actually meaningful. It's important. It means you're not just getting

sidelined and working on stuff that doesn't matter. Yeah. Yeah, that's true. Look at all these silver linings. Turn that frown upside down. It's actually good. I don't think I'm a careful person in general. And certainly when I was in IC, my strong point was not great rigor in being very careful don't ask me what my strong points were but it wasn't that so i i feel this sometimes i'd get a lot of stuff done and then it would have some bugs and i also worked with people who were very careful just by nature they they kind of thought systematically and exhaustively through the problem space and were able to uncover ways it would break that they did not expect and then and then produce non-broken stuff because they anticipated all the before it broke even

amazing yeah i could produce non-broken stuff but sometimes it took breaking it in production to produce it i think these co-workers of yours had time machines i mean nobody's perfect that's part of it but i have i have noticed a a spectrum of of like prod readiness i don't know it feels like a an attribute you can put some points into when you're creating your developer character class yeah but i've also seen people get better at it so what was my point i think it's natural there's some variation here i think you can if you want to you can get better at it and one way you can get better at it is ask yourself how could i have known this when you're going back through and fixing stuff that comes up not in a like there's

no possible way i could have known this no like literally how could i have known this yeah like Yeah, what could I have done differently that would have uncovered this earlier? And maybe that reveals you need to do more unit testing. I don't know. That's like a trite answer because it's like saying exercise. Sure, everybody does, and it would always make everything better. But still, maybe it would. Maybe it reveals that you need to, I don't know, talk through your designs a little bit more with people before you start building them.

Or maybe there's some additional QA steps or there's a class of errors that you seem to fall into. yeah see if you can do little mini post-mortems because i i imagine it's not one big thing of like but you forget to run the code you just never run your code and it's it's probably a lot of little things that if you patch up over time you will be able to get better at encountering i i know exactly what you're talking about and it's like it's very common when you come into a new code base to ship bugs and the and when someone asks you why you ship that bug the answer is well i didn't know about a whole set of features that this product has and not knowing about those features meant that i didn't test them or consider them with my own code and so they broke you know

and it's like and that category of things i don't know how to accelerate that for your own self like how to accelerate getting past that but it seems like you just have to take the time to to learn all the cobweb filled corners in your code base there's that's certainly true like i don't know you change some background job to take three seconds instead of two and then you find out that was actually used as the timer they for some critical system that assumed it would be every two seconds we set our clock by that being every two seconds yeah we think it's three months in the future yeah how dare you it's like how how could you have known that and that's where you go literally how could i have known that like i don't know what would it take to know

that is a good point actually i think you're one attribute when i think of people that seem to be better at not breaking stuff tenure at the company in the code base certainly affects that it's directly related i didn't break that because i knew about that yeah i think there are also some transferable skills here though that as you gain experience through your career you you you get some spidey senses of ways that stuff might break yeah and and so some of it is yeah knowing the code base and the infrastructure and platform that you're working in better and some of it is knowing like i don't know manually doing stuff with dates is scary so if you see code that does that and you have to touch it it's probably going to break

stuff yeah so like take extra time to think through all the possible ways that that could break and then you're like but i can't think of any ways it could break it's like well yeah that will come after you break it as long as all of my events get delivered exactly once then everything's fine then you just continue on your merry way yeah and someone someone maybe you you're in the future tells you uh hey that's actually impossible to guarantee so you have to work you have to design around that someone possibly you i love that yeah there isn't isn't that true though that there are like several categories of just bug spawn points in software that is across every company i've ever worked at in 20 years and you mentioned one of them date and times and in

particular time zones it's like anytime i see the word time zone i'm like okay nope not a quick fix yeah i know this is broken in guaranteed it's already broken in lots of ways exactly another one you mentioned already was like distributed system message delivery you know what what guarantees can you and can you not make oh man there's just so many i can't even i don't even have a running list it's just like when i encounter them i go oh ouch i've got this scar tissue that started tingling when i saw this yeah yeah yeah i guess i don't want to just run through things i thing that that would be way too technical for this podcast it would be but but it would be a great book i think where it's like look if you take nothing else from this book just read all

the chapter headings each one of the chapters is a subject where if you have to work on code that does that triple your estimates probably yeah it's probably broken already yeah it's probably already broken in ways that you just have no idea it's kind of like code smells but at a at a larger level code smells are sort of like this is a sign that this code might be brittle and this is more like this is a problem domain that is probably broken it's just so many like oh you have to process files do you know about file encoding or string encoding you know yeah it's just so many if you ever have to say the words f-sync then you probably have data integrity issues yeah oh man well sorry this is just it's giving me cold sweats good news we're managers now so we don't

have to worry about any of that stuff we don't break things we just yeah help people not feel terrible when they break things that's our job now yeah no we we break people and organizations not code much better and you just you can't put up a pr to fix the person you broke just so you know no you cannot yeah that's a and you can't leave comments on someone else's person you can't request changes very easily i can't submit a pr yeah look i'm just gonna i'm gonna dial down your ego a few points in this pr yeah i'm gonna block you from merging this personality trait personality request changes pr yeah would you ask your co-workers that was

the other thing that's exactly what i was going to ask next is you know yeah i would i would ask him i'd be like hey listen actually this would go a long way i think oh man i don't know this could backfire if you have evil co-workers but let's just assume you have benevolent co-workers and you come to them and say listen i'm interested in becoming a better software engineer and and contributing better to this team. I've noticed several instances where I have made mistakes that required follow-up work. What would you say? Are you noticing this too? How do I calibrate compared to other engineers you've worked with? Am I doing better, maybe a little worse? Give them plenty of safe space to give you honest feedback on that. And be very specific about what you're asking for

there. Don't just walk up and say, do you have feedback for me? But rather specifically about this, like follow-up work and bugs that I'm introducing. And aside from that, just learning from your mistakes and asking your coworkers to help you calibrate where you are. I don't know what else you do besides just continue marching down the software engineer path, knowing that all the greatest software engineers were forged on the path of just mistake after mistake after mistake. Yeah. I said something earlier about it means you're getting stuff done if you're breaking stuff. But one of the things most correlated with production systems breaking is is changes getting deployed to them it's really hard to modify a system without breaking it ever

that's the that's the dance that's part of what comes with being experienced is you you hopefully get better at that you're able to make bigger changes with less risk and so i think it's good you're thinking about this because i guarantee there are lots of people who do this that do not think about it that are just like pumped to be hucking some code into production it sucks that you feel really guilty about it and you have a pit in your stomach but hopefully talking to your coworkers about it can help. Yeah, because the pit in your stomach probably comes from worrying that your coworkers think you are bad and worrying you're going to get fired or get a bad rating. And just talking to them will resolve that part of it. And the only thing

that will resolve the other part of it is just making sure you learn as much as you can from each mistake. Would you talk about it with your manager to say, hey, I'm working on this? Or would you be worried that would risk exposing this weakness? Maybe they didn't know and now it is going to show up on your rating you know it depends on how hands-on my manager is because if your manager is really hands-on knows the code works in the code with you they might actually have good advice to offer you but if they're super hands-off then it maybe can only hurt you to tell them about it what do you think i think it could help in that you would be able to show hey i'm working to improve this area of of uh of weakness yeah because often that's part of the

point of reviews is to say like you need to get better here maybe you could even preempt that by saying look i'm working to get better here and and then if that shows up in your review it can be more like as we've talked and as you're like as you're already doing you need to continue to get better here exactly and i think that's that's the message i would bring to my manager rather than, hey, can you tell me how I'm doing? I would say, here are the things I'm doing proactively to become better in this area. Yeah. Well, we answered the question. I think so. Good luck. It's great that you're introspective about this and recognizing it. I think a lot of people who struggle with this, not a lot, but some of them don't recognize it, don't work on it. And then one day they wake

up and their manager is like, you're not meeting my expectations. And it's like, oh, crap. So it's good that you're getting on top of this early. Yeah. All right. I will read our next question, which is also from an anonymous listener who says, what are your thoughts on low-code platforms? I feel like they will end up like WordPress, small companies with the tools in a varying degree of spaghetti that pay a contractor to clean up. I found myself on a team that wants to use a low-code tool,

and I feel like it's a detriment to my career. I feel like another employer won't take me seriously in an interview as I try to explain my way around it. Is this something I should be concerned about being in too long? i voiced my concerns but it doesn't seem like direction is changing what would you do how do you feel about low code in general i like less code code makes bug code has bugs in it and breaks low code low bug that's right and if you have bad code that breaks you get pits in your stomach and i don't like those either i i would not want my career as a software developer to be using and

working in a low code platform the the question doesn't mention a specific tool and this podcast is not endorsed by any specific low code tool yet yet yeah but like i think it's stuff like webflow where it's it's it's kind of a whizzy wig ish more powerful version of like a site builder or and you can get a lot done without writing a lot of code but then there's always this there's this exponential increase in how much effort it takes to get the last little tweaks that are not easily enabled by the platform done. And some of them have escape patches where you actually can write code in these low-code platforms, and some of them don't. But in my mind, these are tools to enable technical people to get stuff done, not necessarily make it easier for software developers

to get more done right so i i i would be i would be worried about pigeonholing myself if i wanted to be a more general software developer into i would be worried i would i would actually be becoming like a web flow developer which exists people do hire for that but that's like a specific skill set and and not as easily transferable and i think it i might even say it makes me worried about being it makes me more worried than just being pigeonholed because there are some technologies that with which if you get enough skill you even if that's your only skill you are still valuable because people employers perceive your skills as transferable even though you're narrowly working in one skill like you may become an expert on one programming language okay fine

people might then assume that you could become an expert in another programming language and they would probably be right like that's pretty pretty common but if you become an expert in a low code tool, they're not, I think most employers are not going to assume that you could transfer that skill to a programming language, like a traditional software development programming language. Yeah. So I'm agreeing with you and I'm actually plus one-ing it and saying, I'll take that vector and increase its magnitude in the same direction. Whoa. It's a big step. It's big. So yeah, I think the answer is yes. I would be concerned about being in it for too long.

Yeah, me too. what would you do honestly i would look for a a different job it's a really bad time to be doing that but still i would maybe you don't find anything but i would look for a job that helps me build the skills that i want to work in i mean some of these platforms have like plug-in architectures and those are often high code like you're building you're building stuff for other people to use in a low code environment maybe there's something there where you can say i want of like build the tools that get used in this low-code platform. But yeah, I wouldn't want to be, I don't know this for sure, but my assumption is that you get paid less if you are an expert in

a low-code tool versus a general software developer. I think that's true. My gut says it's true. And my gut only fails me about 30% of the time. Your gut never lies that I know of. Yeah. Because it doesn't make easily verifiable claims. Yeah, that's right. It avoids those like the plague because, you know, it knows it's wrong a lot. It would harm its reputation. I find myself on a team that wants to use it. I feel like, yeah, there is a balance here, though. I mean, if there is a legitimate business case for your company to use this tool, you also don't want to be fighting against that for your own personal career benefit because the company will pick themselves over your career every time. So I would be delicate about this if you're trying to change the company's or team's mind to not use this tool,

unless you feel like it's a really genuinely better thing for the company. Which it might be. Yeah, yeah, it might be, it might not. And if you're like blocking or putting your foot down against using this because you don't want to work in it, even though it'll be cheaper,

it'll be even cheaper to not pay you. you know like i especially have to get this low code no code solution deployed so they don't need you yep yeah i would be looking around for something maybe a different team if you like the environment yeah me too well have we answered this question i think so but i'll throw out one more caveat which is depending on your particular skill set and your background low code might be great for you so i i don't want anyone to hear what jameson and i are saying and think oh low code avoid like the plague no like if you're just getting into software development this could be a great stepping stone or frankly even a permanent career path for you but if you're already into

software development and you're the kind of software development you do is writing code building applications this might be a step back in terms of pay and technical expertise required to use so and and it might close doors to you that are that are currently open so it kind of it depends on the background you're coming from just a little bit yeah yeah there there is certainly a hierarchy of like prestige and pay here that doesn't mean you are a better or worse person but it does exist i mean it does in jameson's eyes obviously but i try and hide that part of myself from this podcast dave no like yeah you will probably get paid less as a as a wordpress developer than as a i don't know a software engineer but a way i've seen people

take this is if these tools genuinely make you more productive and help you get more stuff done you can become like a freelancer or a consultant and then you just say it'll be x x dollars for your website please and then because of this low-code tool you can crank it out really fast yep so so there is some ability to specialize and and benefit from like the abstractions and productivity gains that these hopefully provide yep but if you're just using them at work and yeah i would be i'd be worried about that yeah for sure if you're just employed as a software developer to use one of these tools because part of the point is you can get someone without as specialized of a skill set hopefully or part of the appeal of these tools to companies is

is cost saving you need a less yeah yeah which kind of tells you everything you need to know about about your career yeah yeah you don't want to be in it's a good general principle you don't want to be in a cost savings career unless it's like i will thus be able to get way more done in volume or i'm the one on the receiving end of the beneficiary end of the cost savings you know yeah like i own the company that is saving the costs that's different than i'm the worker that's being laid off because of the cost savings my cost is being saved shoot i feel so good about my contribution yeah okay well have we answered the question i think so good luck best of luck to you i would love to know how it goes what should people do if they want their own questions

answered dave go to soft skills that audio and click the ask a question button there and fill out our form thank you so much to everyone who does that and also we've noticed a few people recently have written in to comment on the answers that we gave them from a previous episode you can use the same form for that and we love hearing your stories especially when i am wrong and jameson is right i just like hearing them i don't care if who's who's right because i'm better it's uh no yeah we do love hearing follow-up and it's it's always interesting to hear how the real world differs from the version of reality that we imagine from reading a couple paragraphs

and extrapolating it's cool i appreciate it thank you for listening we will catch you next week