July 25, 2022

What I Loved And Hated About Being A Developer

In this podcast episode, I shared my unfiltered experience of what being a developer has been like - emphasis on “unfiltered”. You’ve been warned.


🤝  Join our junior friendly developer community:

🔥  Want more personalized help from me? Here are the paid mentorship and review services I offer:

❤️  If you find my content helpful, please consider supporting me by becoming a channel member and get access to additional perks. Every little contribution helps and is actually used to pay my bills.


Disclosure: Some of the links below are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

📚  Web development books and other products I recommend:

Dev Interrupted
Behind every successful tech company is an engineering org. We tell their story.

Listen on: Apple Podcasts   Spotify

End Hype with Callye Keen
Callye shares 15 years experience launching products and growing businesses.

Listen on: Apple Podcasts   Spotify

Don Hansen:

Welcome back to a web development podcast episode, where we help you navigate through all the BS of becoming an aspiring developer, nothing but truth here today. Completely unfiltered. Uh, so today I'm gonna talk about pretty much what I love and hate about coding, right? And so I think sometimes we get this dreamy little illusion and curated social media content. That's really inspirational. And it's. Essentially selling developer positions is this thing that you should put on a pedestal and what are the best positions ever. And it's the dream job you make tons of money, et cetera. And there's a little truth to that. And I think a lot of BS to it. Right. So I didn't plan anything in this episode. So if you're looking for anything curated, this is not for you, we're just gonna wing it. So I was a developer for three different positions. Um, yeah, we're just gonna dive into what I loved and hated about some of those positions. you know, to keep you here, not chase you away from coding. We're gonna go over some of the stuff that I love first, and there's a lot of it. There really is. Um, I'm not gonna go in order. I'm just gonna kind of bounce around and think about some things that like really, I don't know, kept me coding. It kept me moving forward and, uh, progressing as a developer. So yeah, I think, I think all my interviews were really friendly. I think. Software engineering interviews in general are. starting to become a little bit more focused on a lot of soft skills and providing a really good experience. And I think a lot of companies want you to, even if you don't get that interview, they kinda want you to share like, Hey, this is a pretty good experience. Maybe you should apply to it. Maybe you'll get it. Right. And so I think a lot of interviewers are self-aware. Of this and self-aware of how they act in the interviews. And even if you're not a good candidate, they want you to have a good experience. And with all three interviews, that was pretty much the case, which is pretty cool. Cause I've had jobs in the past where they definitely put themselves on a pedestal, no humbleness whatsoever. And I was scared shitless. I'm like, I'm not gonna get this job. I'm not smart enough for this job. Sorry. And like the ways the interview was structured did not help a lot of those self defeating thoughts. In general. I think software engineering is getting better with that. So interviews are pretty friendly, you know, even in one, one of my interviews, I got to skip the technical interview. That was pretty cool. And you know, in my other videos, I shared how I've done that, uh, go back and watch my very first podcast episode, if you wanna hear about it. But I love the interview process. And I remember even first day of one of the companies, I'm like, I'm scared that like, They hired me. I wasn't gonna be prepared for the position and pretty much in every single position, I was way more scared than I needed to be. And I had way more ramp up time than I thought I had. I remember like one of the jobs I'm like, I'm gonna be fired like two day. If I don't get my environment set up, like I was so scared because the environment was so complex. And sometimes when you go into a new position, it could be pretty complex, pretty scary, especially in your earlier positions. So overall, I think teams in general, like if you show whenever I would show humbleness and I'm like, you know, I'm really trying I'd show effort and humbleness. It has to be a combination of both, right. So you have to show that you've at least Googled a little bit, you've done a little bit of research. You try to figure it out on your own and when you could do that, and you're like, I just, you know, I'm kind of stuck here. Um, here, here's what I'm thinking. Right? And so this is what I learned later on, but like wording it, like here's what I'm thinking. Here are a few options. What do you think about those options then you give. Senior engineers kind of that, um, you reassure them that you have done your research. You're not being lazy about asking for, you know, tons of questions and not putting any effort into it, but also if they do have like, they have the solution of mine and you don't really, um, you, you really didn't think of it. You don't have the respective for it, then they'll be like, oh, okay. I get, I get these solutions, but what about this force solution? Have you thought of that? What would you do for that? Right. But in the beginning, you know, I, I was pretty scared that I was gonna ask too many questions and I was gonna get caught that I wasn't qualified enough. And none of that. none of it happened all like my imposter syndrome was all in my head, every single position. It it's actually crazy how much stress I gave myself. And so things I liked about the developer positions were kind of just like how friendly a lot of senior engineers are. Um, I think I discovered that a lot of good senior engineers that have been at the company for a while. They've really practiced talking and comforting junior developers. They really. Put time and inve like companies pretty much are gonna promote people to be able to mentor other parts of the team that have those soft skills and that put effort into those soft skills. Right? So I, I know a lot of people, you think you're anti-social, but you can become very, very social, very comforting, very encouraging. You can become all these things. All these things are trained, even if you don't feel like you're naturally this way. So I feel like overall, as long as I showed humbleness developers are pretty friendly towards me. Like in general. Well, Most of them, not all. We'll we'll get to that later. but as you know, as a newer developer, I would, um, I remember going into meetings for my first time meeting other departments. Um, initially a lot of departments were very friendly. They wanted to get to know me. They wanted to create a good experience for me. They wanted me to stick around at the company cuz I, I. Don't think you realize this, but it takes a long time to hire a developer that the company's confident in right company wants to hire someone that's probably gonna stick around for a while. It's gonna be a good fit, grow with the company. Um, be humble enough to grow themselves and kinda like just blend yourself in with the company culture. And I think a lot of people feel like that, uh, companies are kind of like judging them. I had this, I don't know, maybe as just me, I had this. Mindset, this worry that I was always being judged of my skills, like of my technical skills. Like I, I was always, um, there were kind of just like I was sometimes being tested and I was like, I was gonna get found out. And like, even if I would talk to a designer, it's like, I had to sound smart enough for this designer to have faith in me to be able to produce this feature. A lot of these thoughts were like very early on. Very early on. And I slowly got over that, but you know, every single other department that I met initially, they were all super friendly. They weren't judging me, they weren't testing me. Right. Um, they were kind of just curious, like who I was and, uh, they wanted to essentially pair with me and create a good relationship so we could build features together. I know that, I don't know when I say it out loud, it kind of sounds cheesy, but that's essentially how he felt in every single position. I think in general. Developers really, um, were probably one of the most antisocial parts of a tech team. I'm gonna be honest with you. Probably one of the most antisocial parts of the tech team, everyone else, super social. It it's much more required for the position. You know, it's still required for our position, but don't be scared of other departments. Definitely. Don't be scared of meeting people that you're gonna be working with, working on features with, from other departments. It's gonna go a lot better than you think it is. And 99% of companies, you know, you're always gonna get that, that, uh, off case, but it was a pretty good experience for me. I feel like whenever I needed help, I'm telling you, and this is just a tip it's like when I would show a little effort into, if I needed. Let's say I was diving into like a more advanced feature and I'm like, man, , I don't even know where to start. Right. Um, it was very, I was also afraid of like asking for help right away to get that initial context. And one thing that I. Um, when I started doing this, I got tons of support with it is if I was gonna dive into a different part of the code base, especially if I was newer, I'd always get context from the developer that worked in that part. They'd gimme some context and some of the gotchas, and I'm telling you, like, if you take the effort to do that, you are going to be able to learn that part of the code base and produce a feature a whole lot faster, and you're gonna get support. A lot of developers think they need to figure things out on their own. And actually one of the worst things that you can do is jive into a brand new code based brand new section of the code base, and just figure out all that context and try to figure out how the data's flowing, how everything's organized. And it takes a long time to go through all those files. And if you have that initial context, it really speeds the process up of understanding it. I was, I used to be afraid. Of, um, essentially asking for help, et cetera. So there's times to ask for help and there's times to attempt it on your own and then, you know, showcase to the senior developers. Like here's what I've done so far. Here's what I'm thinking about doing what do you think? But when you're jumping into a new area of the code base, big piece of advice, definitely get context from that developer. If you can, uh, it's gonna speed up the process, cuz it, you can actually create frustration on the team when you didn't even ask. Right. Is dove into it. A lot of the, team's gonna assume, you know what you're doing, but if you're just flat out stuck or you're, you know, you, if you can spend five minutes with a senior engineer that worked on that part of the code base and just get tons of context that would've taken you like three to four hours to grasp and like kind of follow that's huge. Right. You know, essentially a lot of managers want teams to move efficiently and you're not being very efficient when you're always being stubborn and trying to figure stuff out on your own. So, you know, it's kind of a balance. Figuring stuff out on your own and also asking for help. It's a balance that you get better with over time. But in my experience, a lot of developers would in their own way, not always in the friendliest of ways, but in their own way, they would essentially, uh, Um, kind of hint towards if I am asking for help too much, or if I'm not asking for it enough, et cetera, I got that feedback. Please try to be open to the feedback. Um, it's very, I'm telling you it, it can be, sometimes it can be really tough to get that feedback, but a lot of developers just want to see other people on the team grow. They really do. Um, and so a lot of developers were friendly and gave a lot of the right feedback for me. And sometimes they hear, you know, once in a while, like a really bad company team is toxic. Developers are toxic. It's usually just like one or two developers on the team that, you know, create hardship for everyone else. But developers were really friendly and just kind of helping guide me in the right direction. And. Um, I feel like my growth as a developer was always supported. So I worked at companies, my growth as a developer was always supported. I even got, um, I remember asking one of my managers, I'm like, I'm gonna read this a thousand page CSS book. I really wanna get this down. Right. He's like why? And I'm like, cause you know, I, I feel like I forget something to CSS stuff and I'm like, you're gonna forget it. He said, I don't remember what he said, but essentially saying you're gonna forget a whole lot more. You know, if you go through this entire thousand page book and you don't use it. And so a big lesson that I learned, and this is for managers as well, is just do get in there, get your hands dirty. Of course, if you gotta get that initial context, you know, talk to the developer that worked with that part of the code base. you know, get your hands dirty and actually use it, actually solve problems with what you're trying to do. And if you need, if you get stuck, then you look it up. Right. Um, that's a really effective way at learning. Cause I think some people try to just cram all these books and they think like these senior engineers are like brilliant people that just remember all this stuff. They, they read a book and boom, like their senior level goes from like 15 to 20 right now. It's up here. Like there's no way you're gonna catch up. It's like, no. They forget a lot of what they do. A lot of senior engineers forget specific syntax and, you know, specific algorithms. They forget a lot of what they do if they don't use it. Right. So you're gonna, you use it enough times, you solve enough problems of the same problem using the same type of solution. You're going to start remembering it and reinforcing it. And so I got a lot of good feedback from managers on. So growth was really good at all my companies. Um, and I feel like if you, that's something you should aim for, when you're trying to become a developer, you should aim for a manager, a team that's going to support your growth and nurture it in the right way. Right. You can get a few companies that will not do that. Um, and then, yeah, I mean, I've, I've had a little, a lot of good experiences with my growth. Let's see, what else did I like? Um, I liked meeting, meeting other departments. I liked taking a break from the code to meet with other departments. A lot of other developers. Uh, kind of just like to stay in their focus mode. I like bouncing out of it and then bouncing back in, it makes my day more fun. So I got to do that. And other departments appreciated when I would communicate effectively and share the things early as possible. So, you know, if, even if the designer was like, they were kind of working on a new design and I heard they were working on a new design, um, I could even mention like a pattern that we've used that would support that design. If I, and I could just mention that in the standup or whatever, if I hear them talking about it, it, it just. I'm telling you good communication, early communication is going to make your job so much easier as a developer. It's gonna make it fun. It's gonna make, when you feel supported, when you feel supported as a developer on your team, that job gets way easier. It's way more fun. You want to come into work. You want to work with these people, right? And it kind of sometimes, you know, you're gonna deal with certain personalities and sometimes you. Try to take a little bit of a, the bigger person approach and humble yourself. And, um, a lot of people will appreciate that and they'll let their guard down when you can really show that humbleness it's, it's, I'm telling you, it's like the, a secret weapon for people that are like very abrasive people that like, you know, not getting along with other people on the team, you being humble, you being humble. Is a huge key weapon and getting their guard down for them to actually help you and open up to you. And, you know, then it becomes better to be able to work with them. So I've had managers that have like, You know, really cared about my health. I remember going to the hospital for a couple different things. At one point, I remember one manager even recommended, like there was a deal with a really, um, really popular hospital in the United States that dealt with a lot of like stuff he's like even offer. He's like, I, you wanna go on a road trip? And you know, we, we actually have this person as a potential client. And like that to me is like going the extra mile to like really. Kind of care about my personal issues and that, um, cause I remember when I shared that with him, I'm like, he's not gonna care what I think. And like him going the extra mile to say that. Um, it really made me feel like, uh, it was just more than a job. A lot of people say that like a lot of these jobs should be seen as only jobs. Then you go home nine to five, go home. And I think work life balance is important, but I also think a lot of people that give this advice and like really put shade on certain specific positions and you can't enjoy it. You can't love your job. I don't think they've had good experiences and that is unfortu. That's really unfortunate, cuz people can love their job. They can love their experience. I could like really give you a purpose in life too. And um, so, but I also was cautious enough in the interview process and this is the key thing it's like, you have to do your research on the company. You have to go to Glassdoor, you have to look at interview experience this. You have to, um, You have to really do your due diligence and ex and you know, people hate this. When I say it's like, you gotta look at the company values, you gotta look at their mission. What are they what's influencing them. That's going to bring in people that align with that mission. And if that mission has a lot of positive values that, you know, really promote kindness and constructiveness and, um, I don't know, I'm blanking on values. I'm I'm just saying like align your values. Um, but I, I think you're. It, I, I think looking at the company history and just reviews and stuff like that will help you realize if that company is going to support you in the way that you need it to support you. And some people like don't need all that soft stuff. They they're like, I don't, I don't care about this. I don't want a company retreat. I don't like, I don't need my coworkers to be my best friend, et cetera. And that's, that's fine. But then you know that right. You can look at companies that will specialize and focus on other things, but I think it's incredibly important to pair that company, those company values with your values and do they. I'm telling you it's powerful and it also can make you stand out in the interview when you do that. And you've shown that you've done that. That's huge. And I did that and I worked at three companies that did care about me. Um, what else did I love? I loved learning, uh, different patterns in. um, the code bases, very different styles at my three different developer positions. Um, one that like no tests whatsoever, one very few tests. And one, I felt like there were more tests and features. So I've had three different experiences with that. And I've had, I've met developers with very. Passionate opinions on testing. Testing is one thing that developers are pretty much love or hate, quite frankly. Um, you'll get some middle ground, but like most people either love or hate. but even just like learning different technologies and being able to integrate more libraries, like you, you find that when you start working with different libraries and like you start integrating more into your code base, which is pretty, you know, it, it's definitely a common thing in JavaScript environments. You actually get faster at it. You get better at it and you get better at like reading documentation. Cause you're reading a lot of documentation with integrations and bringing in new libraries, et cetera. So you get better at reading documentation. A lot of people are like, I don't wanna deal with all these libraries. Well, first. You know, JavaScript developers get paid quite a bit because of all this incredibly complex stuff and the, these complex systems of libraries and frameworks that we're trying to piece together and well together. Um, there's a reason why JavaScript developers make a lot of money. And that is one of those reasons because there's a lot of knowledge that you have to keep up with. But one of the important things is, um, I was always supported when I would learn new, uh, technologies and be able to integrate it. And, um, I, I got faster with it and I would even help junior, like more junior developers to me, kind of read through documentation and point out what they can do. So I found that when I would go back and help junior developers, as well as I learned stuff, and I would help someone on the team like management really appreciated that senior developers really appreciated that the junior developers that I helped really appreciated that that's something that's usually rewarded and highly valued on a tech team. So if you like teaching others and you like helping them in that way, that's pretty huge. It's gonna make you look good on the team for sure. Um, I loved when business, so I like working in the startup world and I got tons of support, uh, when I would talk to other departments and try to understand their needs. A lot of developers will silo themselves. Right. I talk to who I need to and that's it. Right? And then I'm just a code monkey. You don't wanna just do that. You don't wanna be just a code monkey, typing away building features. You need to be able to understand different departments, concerns, et cetera. And that, um, a again, this is a. It's a skill you have to build up. It doesn't have to be natural right now, but that is a skill that's gonna be highly valued at a company that is a skill that's gonna prevent you, not guaranteed, but it's most likely gonna prevent you from getting laid off versus another developer that didn't really take the time to like, try to understand the business needs and, you know, understand where like, uh, you be able to balance like, um, especially with features, if you can give. Uh, possibilities of like building a feature quite a bit faster where it's not gonna have tons of flexibility. It might not be the most efficient piece of code or, you know, your proudest code, but like you can get this done in a week versus four weeks. And you can kind of understand that, you know, sometimes a business will be in a tight spot and you know, it's just gonna be, uh, a spot you're gonna have to refactor down the road. Uh, people from other departments will appreciate that. Now, as a developer, you, you do have to push back on that kind of stuff and you should, but you also have to know, you have to be flexible. You have to know when to kind of say, okay, I, I understand your concerns. I ideally would like to spend four weeks on this. I can only spend. I get it right. And so I think that's a balance you're gonna have to work. And it depends on the company and the team dynamics, but you being willing to do that and you being willing to be flexible and understand the other, other department's needs. You're gonna get tons of support. right. So the more, what I'm trying to say is the more you try to invest in your relationships, the more you try to build those relationships up and understand other departments. That's when you are the developer, that's gonna get promotions. That's when you are dev, like I'm telling you, this is where companies start, like really, really valuing you. This is where businesses like, can. In a business, you start bringing way more value than just some random developer that doesn't really care to interact with all these other departments and other people and build relationships. It's just night and day developers like this get promoted developers that are antisocial and choose to stay antisocial. They don't really work on their soft skills, you know? Okay. Keep working on that part of the code base. Just maintain it fine. Right. But a lot of senior developers, the expectation is you're gonna. Mentoring junior developers. You're going to be talking with more departments and trying to understand the business needs. And it it's just trust me. When I say this really work on your soft skills, really work on your social skills. It's going to go a long way with a long of successful and amazing long term career. Whether it's at that company or you choose to go to another company and you take those skills to another company, that's fine. Um, so coding was fun. Let's see. Any other positives. Coding was a lot of fun. I liked, I actually, uh, I'm not gonna jump into that dislike. I liked. I liked learning conventions from senior developers and I felt better about my code. You know, every single quarter, I feel like learning architecture and code patterns. And you, you know, once you get into the industry, Learning these patterns and why their patterns, why they exist, what problem they're actually solving. Um, that's going to up your game and your skill levels, a developer big time caring about that kind of stuff is, is it's gonna make a big difference. But I liked learning about that stuff. I don't know about you. I like, um, I like making things more efficient. I like think making things organized. There's something about. I, I don't know, like, you know, with a feature feature driven design with the react versus like, uh, you separate files based on type, right? Um, I think whatever you choose to do, be consistent about it and have a pattern across your code base that feels good. That feels efficient. Have a reason why you chose that feature driven design and you're compartmentalizing everything, or like entire features together. And then compartmentalizing features within that feature. Right. That's kind of my. Preference, but whatever you decide to do, however you organize code. I think you're gonna feel better about it when you start getting more consistent patterns with whatever you're doing and having reason behind what you're doing, rather than initially when you're just starting out, you just wanna get it working. I'm telling you, get it working. Don't worry about a lot of this overhead, but once you get into the industry and you start like, I mean, even right before, but like, especially when you get into the industry, start paying attention to some of the patterns that senior developers have, uh, learned and will have used. And then learn why they chose those patterns have a conversation with them. Uh, there's so much, there's so much knowledge. The more you learn, the more you realize how little, you know, and there's so much knowledge you can get from senior developers. Um, I think it's fun. I think it's just fun. Seeing more complex patterns and like how that scales the application and you know, how large of a. How efficient that pattern is going to be at a certain scale, and this is where it starts breaking off and it's no longer ineffective. And then, you know, once we start getting like 20,000 users a month, once we start getting a hundred thousand users a month, uh, you know, a million users a month now this pattern and being able to organize this application and continue to scale it, it starts to break. And then sometimes you gotta shift. Sometimes you gotta plan ahead for that growth. Um, I think. That, those patterns, that architecture is super interesting to me. I, and I'm gonna say one more thing, then we're gonna jump into the negatives. This ain't all positive. We're gonna jump into the positive and negatives in here, but, um, it's, it's learning about the user it's literally like watching, um, What's the app, like hot jar, just like some sort of application watching the users actually go through and interact with the app. Um, getting listening to testimonials, listening to even just frustrations from the user, or even just like, there was a frustration, you were the developer to fix that, or you adjusted that feature. So it's more usable and now you get a thank you and you know, a lot of, um, sometimes you get like, um, it you'll get different departments called different things that will interact with. The users and shared that feedback with you. And I think it's really cool to get feedback, like positive feedback on a feature that I just pushed out. It's a little bit more usable and friendly and they loved it. Right. It made their experience on our app better. And I was the reason for that. That's awesome. That feels good. I like user feedback and I think more companies should share a lot of that user feedback. Um, because I think. Sometimes developers, we're always told everything's wrong. Everything's a bug everything's broken. We gotta constantly fix it. Now we're creating more bugs. And what are we even doing here? We're just creating problems for the company. And I think sometimes it really, it, you have to get that user feedback. You have to know who you're helping. It's just. I dunno, at least that's that's me. Those are the things I like about coding. Um, I'm sure there are more, but again, I'm just winging this, this ain't planned, so we're gonna dive into then negatives. Um, and I think the negatives are also fun. I think the negatives are gonna bring some more realism into I even record. Okay. I've recorded episodes where I did not press the record button. So I just wanted to double check. This is getting a little bit long, so. All right. What I hate, what did I hate? Uh, one of my positions I switched to WordPress. I couldn't give a fuck about PHP or WordPress. I don't want to dive into it. It generally does not pay well. I don't care to work with WordPress. It's one of the most inefficient C well, it's a CMS. They're all inefficient to some extent, but I, I don't wanna work with WordPress. I don't wanna get better with it. And our company, you know, I, outside of my control, you know, uh, the CTO decided we're gonna work with WordPress. We're gonna push that for our new website, our new marketing website, and I get why it happened. And so I started learning PHP and diving. Well refreshing my knowledge on PHP and diving at a WordPress. And I cannot tell you, my, my work literally shifted from like loving what I'm doing, coming into work. Every day, I even talked to my boss. I was like, I, I would take two hours for lunch and I would actually go work out as well. And I set that up. I'm like, this is the perfect developer job. I love it. Let's keep going. And then we switched to WordPress and then day after day, I wanted to come into work even less, even less. I hated. It wasn't gonna further my career. I wanna get better with JavaScript. I could still, I still had so much growth growing to do to just dive deeper into the JavaScript ecosystem. And now I'm like pivoting into WordPress. I'm like, what the fuck am I doing? And so. It got frustrating. And I think sometimes developers can get stuck with working with technologies that aren't really super marketable that aren't, they don't enjoy the syntax, or they don't enjoy the types of problems that they're solving. And, you know, a lot of my work that I love doing, I actually loved creating pages with CSS and start getting into SVG animations. And it, it was fun. Right. And then the marketing side did that for WordPress. They didn't need me for that. I'm like, okay. So I'm diving in a PHP, all. awesome. Super fun. I hated that. I quit. I quit that position because of that. Um, so, you know, I, I think you, I think the technology stack does matter, and I think in the beginning you might get stuck with that stack that you don't wanna work with. And that's okay. Getting a year of experience, at least under your belt is super helpful for breaking into the industry. And then you have a lot of options from there, but I did not like that. I'm telling you I did not like that. And sometimes we'd hire. I don't know about you. Uh, but sometimes we would hire about a senior engineer that would just come in all that humbleness. I talked about. There's none of that with some senior engineers, none of that cocky motherfuckers, arrogant motherfuckers. And it's like when I encounter people like that, I just like, I, I don't want to talk to them. I don't wanna engage with them. And I put on, you know, when you're at a company, you gotta put on a show and you gotta kind of humble yourself. And I did that again. And, but man, every ounce of arrogance that came out, I can just think of one senior engineer, every ounce of arrogance that came outta that senior engineer. And I had senior engineers that would just. It would be in their domain of stuff to fix. And somehow they would try to manipulate me into doing their work. It's like, fuck that. Right. I've had senior engineers do that. I've had senior engineers that don't hold themselves accountable. Um, so, you know, I'm, I'm telling you, don't put senior engineers on a pedestal. I, I, some, there are some senior engineers that like don't have good social skills that don't ho have good. They don't hold themselves accountable, especially to a lot of the, um, features that they claim that they can build. I, I just like at the end of the day, teams are full of people and not everyone is going to be that ideal person that you wanna work with. I've experienced that in multiple companies. Um, I remember one of my companies, it was almost like. I remember sometimes there was this a team that like was super, like if you get onto a team that like really, really focuses on, um, highly UNS, soft skills on you, can't like their teams were like, you have to walk on eggshells and like teams that are like constantly claiming things as microaggressions teams that are just like, Where you could literally say something in the wrong tone, if you're just a little bit tired and you're in a meeting with their manager, with your manager, um, I don't think I've ever been in that specific of a situation, but I know team members that have, and it's like, holy shit, like you don't ever wanna work at a company where you're just like walking on eggshells. And if you offend someone you're about to get fired, like there are actual. Teams like that. Cause I, I think there's kind of this little bit of a progressive push and F like really focus on soft skills, which can be good and bad in some senses. But you know, the toxic side of it is like you accidentally offend someone you're in a meeting with your boss, right. That's not. It's not a constructive environment. And I think tech in general, I think people need to do a better job at holding themselves accountable for their, how they experience their emotions. Not everything is a microaggression and sometimes like you gotta give each other the benefit of the doubt. I think like most of the people I worked with, even if I said some, like, I can kind of tell when I said something that. Put someone off a little bit and like, if it's really bad, I'll be like, I didn't mean it like that. My bad, this is how, I mean it, or if it's like kind of slight, just like, huh, I wonder why that is. And then I'll kind of phone focus on my interaction with them the next time. And I'll try to work on it a little bit and just try to understand them more. Sometimes you just gotta word things a little bit differently with certain people. Um, and that's okay. But like there's, I've been to an extreme side where like, everything was a microaggression. I'm like, this is, this is actually really ridiculous. This ISN unhealthy, no one actually likes this on this team. Everyone's getting offended. Sometimes that can happen with like projects that are like really rushed and everyone's stressed and everyone's starting to blame each other. The amount of times that different departments start blaming each other. And I've done this. I like, I remember there was a product manager. Where, um, you know, okay. You know what, I'm gonna be honest with you. He started blaming things on me. Right. Features were getting pushed out, but the thing is, the requirements kept changing. It. Wasn't clear about the requirements in the beginning. I'm like, you weren't clear about the requirements. And I remember him saying in one meeting, it's like, oh, it's my fault again. And I'm like, okay, that was kind of unprofessional and immature to say, um, but I don't know. Am I blaming him too much? I, and so sometimes I realized. it's, it's actually more common than you realize when you're trying to push out a feature very quickly. Um, there's gonna be stress in different departments and it's not the most comfortable thing. It isn't because usually that's when people start blaming each other. And I think retros are really good for this to kind of like vent and get all this out retros are essentially like, um, if I'm even using the right term anymore, retros are essentially like, after the sprint, after this major feature project gets done, y'all meet. Talk about it. What went well, what didn't right. You document it and you try to learn from that process. But man, um, It can get pretty messy. And I think the one thing I absolutely hate about coding and I'm telling you, this is AC this actually ruined software engineering for me. I used to put it on a pedestal. It was this wonderful thing. I love creating stuff. It was amazing that I would actually get paid to code. I never thought I'd be a software engineer and be able to do this. And like this actually brought the company tons of money. So I knew I was valuable to that company. And like a lot of things made me feel good. Um, Until I, I started getting deadlines until, until I started. I I'm a pretty empathetic person, so I could pick up on a lot of stress and it kind of, it, it annoys me when people like start a conversation just like frustrated because a certain feature isn't out. Um, cause I, I remember I had this one situation where, um, for the WordPress, I actually, I dove in a WordPress and the product manager. the sure. The designer came over. And, uh, we were just talking about a feature and she was showing me something on her screen and the product manager. I saw a message from, uh, the product manager, this, uh, what was it like this e-commerce still isn't fucking done yet. And I'm like, are you serious? And like the whole day I was actually pissed off. Um, so some people like, you know, you get, you build close relationships and you vent to other people, but I, I think some people turn into assholes when the pressure's. I, I think that happens. And I think some people, I think like really good teams are able to vent a lot of that frustration out and every you're always gonna experience it, but it's, it's something you that needs to be a thing in your company to help people express their emotions and frustrations in a healthy way. Um, because I remember seeing that and I'm like, cuz I was diving in a new part. I, I was really confused about this part with WordPress and like he could have just said, Hey, you know, like a proper thing to say is, Hey, you know, I I've actually, uh, Or, I don't know how, how would I word it? Um, I know we had planned to like release this feature in two weeks. I'm kind of worried that it's not gonna get released. Is there anything that I can do to help speed that along instead of like talking to other people as a team, like, you know, like, I can't believe this isn't fucking done yet. This is super simple, right? Like that's one thing that makes me cringe is other departments that are like, this is just simple, right? We're just like, we're building a button. We're building a button, we're building, um, a link. We're building a little form. What's so hard about it. Like I'm telling you that that shit from other departments pisses me off. I think sometimes other departments don't understand some of the complexities, um, of each feature. And just having to integrate it with other parts of our code base and like understanding, there are certain requirements that are like making this feature really hard to integrate, uh, because they added this like one single requirement. And sometimes that eventually means it's like, Hey, this requirement's gonna take me like four weeks instead of one week, you really want this. And that's a really good conversation to have. And as soon as you realize that you can just communicate with the product manager or whoever, um, Yeah. So, you know, sometimes tech teams can get pretty toxic. Um, what else did I hate? I fuck tech teams that don't respect your, um, your work life balance. Seriously. Fuck them. Like, I, I will never work at a tech company that does not respect my work life balance. I'm serious, like nine to five I'm out. Like there, there's no reason for me to put in extra hours. There is no reason for you to manipulate me into putting extra hours. When I agree to a salary nine to five, there's no reason like if you make it up front, it's gonna be like eight to five or to five 30, et cetera. And you make that upfront. Fine. I'm probably gonna like add, you know, tens of thousands of dollars to be able to accommodate that. Cause that's gonna add up over time if I even wanna do that. But you know, like I got surprised with like being on call when I, that was never given in the interview and I'm like, what the fuck am I like, I don't want to be on call. I don't even like the, with one of my companies, a front end engineers were, um, they were put on call. They didn't understand any of the backend that they had to monitor. I'm like, what the fuck is this? So I'm on call to be able to like ping some other software engineer. That's like gonna be grumpy when I do ping him. And like, he's not even available for like an hour. And like, you know, a big part of the website's down. It's like, I don't, I don't know what to do with this. Um, so I think some companies need to do a better job at preparing people to be able to handle those issues. And you know, when, when developers leave, et cetera, sometimes people are kind of just scooped up for on call cuz you know, to keep the website flow. with very little preparation and then it starts like really eating. I remember one, one manager, and this has pissed me off. We were kind of at an outing at a bar and he's like, uh, you, you own this part of the website. Like you own it. It's your responsibility. Uh, you know, we trust you with it. That's another thing it's like, okay. So you make me feel good. You say you trust me with it. Right. So I like to hear that someone trusts me with something, but that also means. You know, ASCRS, trust me with it. It also means if it goes down at 2:00 AM, I'm responsible for that. I better, I, I remember him telling me, like, you know, we're gonna let you know, we're gonna ping you at two in the morning. You're responsible for it. I'm like, okay. So you kind of like it got you eased me into making me feel good and giving me ownership, which means essentially now I you're creeping into my work life balance and like bugs are going to happen. and I, I, I just hate companies that don't like, put this stuff up front in the interview. Companies need to be upfront about a lot of this and all the work that's gonna be required and companies are not, you cannot trust a company to do that. You just can't, you can't, as an aspiring developer, as a developer, you have to ask these questions. You have to, you know, if you value work life balance. Really drill that in, in the interview. Like you don't wanna make it sound like you you're lazy and you don't wanna work, but you're like, you can bring up an example of like, when you worked way too many hours, you got burned out from developer development. I don't, you know, like if you don't wanna have to quit a company, cuz they're working you too hard, be upfront about that. Right. So sharing some of those experiences that you're like, I just don't wanna get caught up in this. I love what you guys are doing. Um, I wanna support you all the way, but there is a point you start working me too much. I'm gonna find another company. Right. I care about my life. I have a family, I have this, I have that. It's okay to be upfront about it. I think how you word it matters. Oh, what else do I hate about coding? Um, it kind of gets boring after a while. I'm the developer that like, I don't need. A long time to like jump into something. And I definitely don't want to coach for four hours straight without getting up in like, just even a five, 10 minute stretch. I think most developers should do that, but I was always the developer that wanted to talk to people. I like as a newer developer, you're not gonna be talking to a whole lot of people. You're not gonna have a whole lot of meetings. It's gonna be analyzing the code base a lot. And man staring in front of a computer screen, your posture, your posture, first of all, fuck your posture. It's gone. You become a developer, your posture's gone. It's fucked. You're gonna have back problems forever for 99% of people. But if you focus on your fitness, you focus on your posture. You can do corrective exercises to bring it back. I'm telling you. some of you are young. You don't believe me. You're like, Don, my boss's gonna be fine. I work out like couple times a week, you know, go for a jog. I'm gonna be fine. Okay. You, you don't know how bad your posture gets. You don't know how bad that pain gets when you're constantly hunched over. Um, I think it's a big benefit to get like a sit stand desk. I love those. I had, oh man, I loved those. I had 'em at one of my companies. I loved it. Uh, just changing postures, moving, stretching every once in a while. It's super helpful. I'm giving you the key advice. Key life advice. I know a lot of you aren't gonna take it. Um, but yeah, your health is gonna go downhill. A lot of developers, it's very easy to like go to a coffee. Shop, drink a bunch of coffee. That's a really bad habit of developers. Uh, I ended up in the hospital because I drank too much coffee for too. I had like weird neurological stuff. And once I trim back on coffee quite a bit, and it actually took a while for my body to recover, then things calm down a bit, but that coffee will wreck be careful of caffeine. Um, what else? I think in general, I, I really do enjoy coding. I love it. I'm a creator. I love building stuff. And I think it's important to recognize as a software engineer. You're not just a code monkey. You are a problem solver. And when you start instilling that into your mindset and the way you work with other people and your self and your habits. You are a problem solver, you become an extremely valuable developer. You also don't tend to overengineer solutions, which is a huge problem. Can cost a company, a lot of money. You, you really make sure that you understand the problem and things generally start to go better for you. Uh, but that can take a little while to kind of instill that in yourself. Um, I don't know, I could come up with other stories, but I feel like, I feel like I pretty much shared a lot of what I wanted to share. And this is kind of just, I wanna vent a little bit about some of my experiences as a developer. I didn't wanna call any specific companies out. So I kind of, you know, hop between different companies, but, you know, overall there are things I love and hate about coding. And you gotta realize there's a reason why I've always in, you know, take what I say with the grain of salt, cuz there's a reason why I'm printing content right now. There's a reason why I'm coaching people right now. I, I volunteered at the crisis center. I got into psychology a long time ago. I wanted to help people and wanna talk with people and like connect with them at an individual level. I'm super empathetic. I know sometimes I can go off on my rants, but it literally it's, they're all fueled by my empathy. I love engaging with people. And so. You might talk to other developers that might have a different story, might have different, like a different hate, love relationship with being a coder with being a developer. But, um, you know, that's me. So hopefully you can find some of this relatable and at the very least you can. Um, you can actually, well, hopefully get a few different tips to be able to at least analyze your situation and try to get into the development position that you really want. Um, so hopefully this was a window into that, but yeah, we'll be doing more of these rants. I hope you like this one. Um, discord, if you wanna join a junior friendly discord community, that will be in the description. Uh, you are more than welcome to join and, uh, we do a live stream. Right now it's set for every Friday, one 30 central time where you can come ask me questions. Um, that's gonna be on YouTube. So that probably won't change for a while, but, um, yeah, hopefully this helps good luck in all of your projects. Happy coating everyone. Take care, see everything.