Empathy in Software Engineering: Navigating Team Dynamics and Skills

Empathy for less-skilled teammates emerges from environments that challenge even the most experienced professionals.

### Navigating the Complexities of Software Development: A Deep Dive into Team Dynamics and Skills
* 👕 "Look how sweet that hoodie is," sets the tone for a **casual yet insightful exploration** of team dynamics in software development.
* 💻 The discussion emphasizes the importance of **fostering compassion among team members**, especially towards those who may struggle with certain skills, creating an **empathetic work environment**.
* 🤔 The author reflects on their own experiences, admitting, "**My take is I'm a Noob**," highlighting the **shared challenges faced by developers at all levels**.
* 🛠 There is a critique of the notion that management should solely listen to high performers, suggesting that **team spirit and adaptability** are **equally vital for success**.
* 🧠 The article points out that many programmers, often labeled as the **best**, may actually contribute to **significant problems** due to their **inability to communicate effectively** with less experienced colleagues.
* 📉 The narrative illustrates a project plagued by **poor coding practices and a lack of collaboration**, ultimately leading to a product riddled with **bugs and high costs**.
* 💡 The author stresses the need for **wisdom in choosing the right tools and approaches**, arguing that passion for technology must be balanced with the ability to **discern when to apply specific skills**.
* 🔄 Finally, the text advocates for simplicity in programming, emphasizing that "**just program like you're an idiot**" can often lead to **more effective solutions** than overcomplicating processes.

this article is probably going to describe a lot of us in this chat. Okay, and you know what? We're not going to feel too good about it. No, this is not Rick, I don't think this is Brad, and I don't think this is Tom. I think this is you, so let's find out. You know this face that this AI made that's really creepy and kind of disgusting? Somehow, I make this face regularly, this uncanny impossible face to make. I make that face pre-read, called it. After 25 years of my career, I came to understand that one particular type of programmer is the source of many problems in our industry. Here is the story of a project that was nearly destroyed by two such programmers. Who is it? Who of you did this? One of them was leading frontend development, the other backend, while the rest of the team was slacking off because business requirements were in the works. These two chaps were working hard. The frontend lead bootstrapped an Angular monorepository with NX, RX. Oh, why would you choose it? Why would

you choose it. Oh my goodness, you know I can already see the problem coming. You know the problem is that you guys just don't understand the beautiful nature of functional reactive programming. Okay, you need to think of time like an array. Okay, it's an array that you select over time. Shut up and other trendy technologies at the moment. The corporate environment did not lend itself easily to NX, but he pushed hard to solve or circumvent infrastructure's problem by working with the domain expert. He set up a workflow that, while having Angular as the base framework, bore little resemblance to the official Angular tutorial. Prime loves RX, don't let him say otherwise. Oh, I love it. Please give me that functional reactive goodness. Okay, I was using RX when it used to be called select and select many, not map and flat map. Select and select many. The backend lead was no less motivated to bootstrap the Spring Boot project according to the corporate guidelines while adding a bit of personal touch in the form of the VAV library and highly sophisticated hierarchy of JPA entities with multiple

levels inheritance discriminators and generators. You know nothing, nothing, nothing like a good old-fashioned whiteboard masturbation session that comes out with multiple levels of inheritance. Like, nothing feels better than being able to hit that whiteboard and just ejaculate levels upon levels of classes. Nothing feels better. It is, it's Pinnacle, it's Pinnacle programming. Now, some of you are going to say, Bas, I'm going to say based AB, it's abstract, it's abstract-based class. You wouldn't get it. You probably wouldn't get it. You guys are probably over there programming HLL, telling me how great your monoids are. I don't want your mon mons, bro, okay? I don't want your mons. You can go end or [ __ ] off, okay? He then sprinkled it over with a hierarchy of validators based on Booth spring Bean validation and third-party validation framework, and polished with trendy testing framework hasal mentioned. Let's go, that's always the takeaway. HLL is just the worst language. Whoa, someone mentioned HLL. Cool, yeah, hey.

I love hll. Hey everybody, I'm a h cool guy. Hey, anyone want to talk about a little bit of little lamb to culus with me? We can discuss some of the merits of why modules being Endo funter actually make a lot of sense when you think about the funter. I can't even, I can't even give a good impersonation 'cause honestly I don't know [ __ ] about functional programming, okay? I don't have the words, I don't have the lingo. All I know is your function that's partially applied will only ever be partially applied by you. That's a maiden joke, by the way. Months flew and the business started spewing requirements as best they could. The empty shells of both back and front end were already too complex for team members to work straight on business requirements, so both development leads worked hard to split business requirements into more manageable technical tickets while doing most of the grunt work along the way. Each of them worked harder than the rest of the team combined. Again, does this

again, is this not just management issues 101? Like, if you come into a project and a bunch of the people cannot reason about the system, and then only the two leads can reason about the system, at like what point do you say, Yo, we got to get Rick to figure things out here because this ain't working out. Then suddenly, the front-end lead quit for greener pastures. I hope they love Angular and RX. Nothing is better than when some jackass litters your whole codebase with RX, and then you got to go debug it. You're like, Dude, why is this thing... what... where's this function even coming from? Going to play the game of like, Go chase the stacks. Oh, so good. The business brought in an expert front-end developer who managed to keep on delivering for a while, then another one who lasted a bit longer. Junior dev kept underused. The load on the back-end lead was ever-increasing. He spent long days and even longer weekends delivering what seemed to be simple CRUD interfaces, but they were so convoluted on the inside.

that little could be done to alleviate his workload. By the way, whenever you make an abstraction and you find that every time you do something simple and it's exceedingly complex, it's always because you got too clever to begin with. This is a tale as old as time. Just program like you're an idiot. You're stupid. It's okay. Be stupid. Be like the rest of us and just be stupid. Don't be clever. Don't come up with some cutesy way to generate all the greatest things you've ever done. And don't worry, this is super flexible and abstract. No, you're too dumb. I'm too dumb. John Carmack's probably too dumb to do it too. It's okay. Just make it simple, one-dimensional. Solve the problem at hand. Don't solve tomorrow's problems because you don't know what they are and you're not that good at it anyways. That's the secret. I'm always stupid. That's funny. I'm always wrecked. A few months later, the backend lead quit as well, and the

team continued to work at a snail's pace under the ever-increasing pressure from the business to meet the deadlines. The quality of code was failing to the point that VY objects were used in null comparisons, and angular typescript was randomly intermixed with plain JS. At the end, the team barely delivered a product full of bugs. The future's looking bleak. None is up to the task to rewrite the many thousands of lines of code produced by the initial lead developer's turnover. High costs are sky-high. You know, I wonder how many times this has to happen before this isn't a problem. Does every single manager ever either has to live on a project that this happens on or has to manage a project that it happens on before they don't do that again? Is this where Rick started? Yeah, he left earlier in the thing. Like, is that the only way to ever learn from this? Is this just an evergreen source of just horrifying? Does this description of a software project feel familiar? I didn't even read that, and I highlighted it, and then I'm talking.

about it. It does for me as I've seen probably a dozen similar projects in different industries, from online media to public services. The programmers I described are usually considered to be the best of us, but I came to perceive them as the worst. Here is a non-exhaustive list of qualities of these people. Watch out for them. Ooh, here we go, here we go, here we go, here we go. Ability to find satisfaction in solving abstract problems. Interesting. Great math skills. Glorious Le code profiles and an aptitude to solve crossword and compose puzzles are signs of a person who can work on problems without real-life utility. They concentrate on the process, not on the outcome. I strictly disagree with this statement. I strictly, strictly hard disagree with this statement. Real talk right now. APM requires us to build in a... where is it? A motion tree. And to build this motion tree required us to be able to build a tree inverted and non-ambiguous. Okay, I think that's legitimate. I think it's fine to have those skills. You just have to know when.

to apply those skills here, okay, so I'm going to actually invert his argument. I'm going to go way deeper. If you don't have those skills and you don't know when to properly apply them, you are just as bad. The only difference is that you make abstractions in your own made-up way as opposed to at least to some sort of standardized way. The ability to put up many hours of work, one has to be healthy and dispose of large swaths of time that they can dedicate to work. Family, kids, carpal syndrome are all signs that you are not of their kind. This is a crazy take. I was following this article hard, okay, so maybe it's because he's describing me. The ability to work long hours is probably some sort of cross-section between passion, motivation, discipline, kind of like life requirement, and genetics, mild insanity potentially. Prime was Rick all along. Prime was the Rick all along. To me, this is kind of C. I like working, you know. I like a good 60 hours a week. That's a

good good amount for me 'cause for me, for me to be able to learn and understand new things and to be able to get deeper into situations I'm doing. I don't know, just makes me, it makes me happy, passion, and what the [ __ ] is going on in this list. A bright and motivated programmer can always find a way to fit technology he enjoys at the moment inside a project that pays his bills. Business is dull, coding is easy, so why not make it slightly more enjoyable by dragging in the latest technology everyone is excited about. Moreover, this will be yet another trendy item on the resume. I love this right here, I love this one right here. I need to spend about 10 hours a week learning stuff or I start to really hate my existence, kind of a lot, dude. This is me. If I don't spend some amount of time just learning something, I hate it. Can I try to invert what he's trying to say here? Can I invert this a little bit? What I think he's saying all three.

of these points point to the same problem: it is not wisdom, not the ability to solve a problem, but the ability to understand which problem to solve. Wisdom is extremely important. If you like working a lot, that's fine. If you like solving abstract problems, fine. If you have a passion for software engineering and you like to learn about new things and the best ways to do things as much as you possibly can, I think that's a positive. But if you don't have the wisdom to know when to apply those and not, you are a fool. Let me give you a quick example. My previous project, I wrote it in Node because everyone said, Hey, we got to do it in Node. Hey, we got to do it in these things. Hey, we got to be using this. Hey, it's the standard path. It's all this kind of stuff. Well, it ended up being millions upon millions of events coming in that are encoded in JSON and which are done in Node, which was adding minutes of processing, if not hours, due to how slow Node was. Well, really, how slow JavaScript plus how slow

asynchronous operations are in node plus how slow like say a for loop. I removed dot for each and replaced it with literally four let I equals whatever it took seconds off of execution time. My mistake was I used the technology that was safe. I didn't use the technology that I knew I should have used which was probably rust or go. That was my fault. I made that mistake. I'm literally doing it again and guess what language I chose. I chose rust because I'm not going to get boned again by node and JavaScript not being the fastest language when you are doing millions and millions of lines of processing. Is Passion good yeah but wisdom is good too and I chose the right tool. I believe I did choose the right tool for the job cuz I chose the tool that people could contribute to. No One contributes no one will ever contribute to your tool. I chose the tool that would work best with our ecosystem and it did except for I had to make a bunch of stuff that was plainly available in other things you know what I mean.

anyways, okay, narcissism and self-confidence. Ooh, this is interesting. This is probably related to the Dunning-Kruger effect in that the worst of our kind are usually relatively young, bright people in their late 20s or 30s. They are consistently praised as overachievers and do not encounter much criticism. You keep using the word. I don't think it means what you think it means. Just in case, we'll let it go one more time. You keep using that word. I don't think it means what you think it means. Can I be real with you guys? I know that people often cite Dunning-Kruger as thinking you're smarter than you actually are, but I know that the meaning of Dunning-Kruger is supposed to be different, and I never remember what it is 'cause I'm too stupid to remember, and I don't think used it correct here. People keep using this to prove some sort of point, and they almost always prove it's the exact opposite. I know that I

just don't really know what it was. He even he didn't spell. Please tell me that's true. Please tell me it's two ends. Oh my goodness, let's go, let's go. Oh, oh no, oh, it's so good. Oh, it's so good. Oh, it's so good to misspell Dunning Krueger. Oh my goodness, that is the greatest thing ever. I would say that from here on out, I'm only going to misspell it. From here on out, I will only misspell Dunning Krueger. It's the only thing you can do. Mandela effect, Shazam. How not to handle the worst kind. Appealing to management does not work. After all, the management in a business environment is usually non-technical, and the worst kind are the best performers. I've never wholeheartedly disagreed with an article more in my lifetime than this. I mean, I think we got a selection bias problem here. Selection bias being that if you've only, you only get to work with so many people, and that's going to

color your perception of however you think the world of software engineering is. And so, I've worked luckily with a bunch of people who were really, really good, and they produced a lot of code, and they did a lot of good stuff. I, at one point, produced shitty code, but a lot of it. And I was, I mean, I was this person. I just happened to be 21 when I was that person. I still produce shitty code in a lot of it. It's just that I usually make time and have a better idea of how to refactor it into something that's good, you know what I mean? I usually just only program shitty but put it behind a nice module and then refactor when it's time and when I know it's time to refactor it. And you know what? Second off, it is literally Management's job to make sure that this doesn't happen. Management's job is to ensure that a team can work cohesively together. One high-performing person when no one else can work with them isn't a high

performing person. This is like management 101. People who should the management listen to. If not the best performers, their performance is quantifiable, and team spirit is not. Team spirit is very quantifiable. How are you doing? Oh wow, you're feeling really confused. That's funny 'cause Jimmy and Charlene said the same thing. Talking directly to the worst kind also does not work. They listen and kindly respond to their critique of their engineering choices, but the discussion of teamwork falls on deaf ears. They cannot adapt their engineering choices to the least experienced team members, just like some adults cannot adapt their speech when addressing kids. So, I've actually worked with the inverse of this. I've worked with people who refuse to not use things that aren't widely used, and that also causes a lot of problems in an inverse weird sense. It's very hard to describe without being hyperspecific, and I do not wish to be hyperspecific. I mean, I've worked with the opposite side where it's just like we will only use the

things that everybody else uses that is the most industry standard. And sometimes when you have a bespoke problem and there is a general solution out there, or you can solve it with the general tool, and it can get you half the way, but at some point, half the way no longer works well, and you have to become bespoke to go all the way. What can be done? The first step to tackling this problem is to recognize it exists. The second is to spell it out. Most software is written by teams. It has to be approachable by every team member. The third is to look around for existing ideas to tackle the problem. Surprisingly, many contemporary ideas in software engineering can be viewed as ways to fix the problem of the best of us. Goang, Lua, and other simplistic languages. Ooh, I do like those two languages quite a bit. There is broad consensus that Goang is simple to the point of being simplistic. It is in a way opposed to Rust as a means to an end and not, let's see, and not a subject of discussion. Golang team strive, Rust teams.

rust because the language encourages concentration on itself, not on the outcomes of engineering projects. It's just skill issues. I will agree that rust takes more time to become proficient in. I think we can all agree with that. Rust takes a significant chunk of time to become very proficient in. But when I'm doing string processing and command line utilities, you know what language I reach for first? Rust. It's the best. It's literally the best at command line tools. Node? No. Shut up. Always JS [__]. You nice rust is annoying with the unwrapping a skill [Laughter] issue. I have never seen such a you. That was the greatest. That was so good. Thank you for that. Thank you for that. I too used to think rust was really annoying with the unwrapping. I had skill issues. It seems so narrow though to limit it to CLI tools. Yeah, that's because that's where my expertise in Rust is, is in string processing and C tools. It has an amazing iterator pattern from and options and results. It's really good. It

can be really, really good. One largely unappreciated aspect of Scrum is the interchangeable nature of team members. Oh, goodness gracious, what are we? I feel like we're about to say something positive about Scrum, and I'm about to be sick. Well, there are many specializations. Team members are expected to handle any task from the Sprint. They should lead to simpler engineering solutions, which are at the reach of all team members. Oh, gosh, I have never felt a more opposite take in my entire lifetime. Sophisticated programmers usually work on niche environments. It is relatively easy to be a sophisticated Spring Boot programmer or a sophisticated C++ programmer. That's actually called a normal C++ programmer. Like, I hate to tell you this, but if you can program any application in C++, you're already more sophisticated than 80% of web developers. DevOps turns everyone into generalists: configuring servers or cloud environments, monitoring, deploying, setting up pipelines, while coding microservices. The sheer number of required skills transforms even the best

of us into noobs fostering compassion towards less-skilled team members. Let me get this straight. I believe the take here was this. Hear me, hear me out, hear me out on this one. I believe the take here was that having an environment in which you have production-critical services on, in which makes you occasionally feel like a noob, makes you have empathy for co-workers who have skill issues. Did I read that correct? My take is I'm a Noob. Stop making me look bad. I don't think chat GPT wrote this. This is too novel of a take for chat GPT. I think somebody really believes that scrum is good and devops make you feel like an idiot, therefore everyone should do it because that way you can have empathy. I'm going to throw something completely different out there. I think that you should do devops if you're passionate about devops. I know point point up here about not being passionate. I want you to be passionate about devops. I want you to become really good at it.

want you to be able to do your own Kubernetes if you really need to, and guess what? I don't want to hear about that [ __ ]. Yeah, I can make a Docker container. You need me to make a little Docker container? Not a big deal, NBD. I'll throw a little container together. I'll use Alpine Linux. I'll throw curl on that son of a [ __ ]. But like real talk, I don't want to know about any of that, okay? I want to hand you a Docker, and you make it. You make it go. You just make it happen. I don't think about ports. I don't think about any of that. I don't. I don't know what a node balancer does. I don't honestly know how a node balancer works. I don't know how it literally works. I understand ideas about it, and I understand strategies about it. I understand that you really want consistent requests. Like, that's one of the greatest things you could have as a node balancer is that when customer A

makes a request, and then customer A makes another request again. It goes to the same machine because if you can have the same machines with the same customers, you can actually get a lot of local cash efficiencies. But how the hell does that actually work? I have no [__] clue, and that's okay. Alta four, he should be the DevOps guy. Don't make me the DevOps guy, okay? You know what I'm good at? I'm good at going, Hey, these are all the things that go wrong. Let's bring some order to chaos. That's what I'm good at. All I'm going to do is say the word structured logging nine times, and then here's some open-source SL bespoke tooling we need to create. Like, that's all I'm good at. Scrum sucks ass. DevOps should be done by people who like DevOps. Hot take, cold take, [__] off. I don't know which one it is, but this is wild. The name, did you see this sweet hoodie? Extra Life sent me a hoodie. Look at that extra

life hoodie. Look how sweet that hoodie is. A j.

The Worst Kind Of Programmer

This is a place for all the things that are awesome on stream. 

ThePrimeTime

Certain programmers, often perceived as the best, can actually be the source of major issues in software projects.

A specific project was nearly derailed by a frontend and backend lead, whose poor coding practices and focus on abstract problem-solving resulted in a buggy product and high turnover costs.

The article highlights the common traits of these problematic programmers and questions the recurring nature of such project failures in the industry.

The Importance of Wisdom in Software Engineering

The speaker emphasizes the thrill of using multiple levels of inheritance in programming and criticizes the overemphasis on abstract-based classes.

They share a personal experience of using Node.

js for a project, which led to processing delays due to its inefficiency with JSON events.

The speaker advocates for recognizing and addressing common problems in software engineering, suggesting that simple languages like Go and Lua can offer effective solutions.

Narcissism, Self-Confidence, and the Dunning-Kruger Effect

Narcissism and self-confidence are often seen in young, bright individuals who are praised as overachievers, leading to a skewed perception of their abilities.

The Dunning-Kruger effect is commonly misunderstood, with people using it to prove the opposite of its intended meaning.

Management plays a crucial role in ensuring team cohesion and addressing the challenges of high-performing individuals, while the speaker shares their own struggles with producing code and finding order in chaos.

The speaker humorously reflects on misspelling "Dunning Krueger" and critiques the article's perspective on management and team performance.

They emphasize the importance of functional reactive programming and the interchangeable nature of team members in Scrum.

The narrative highlights the struggles of a backend lead under increasing workload and the impact of key team members leaving, leading to a chaotic codebase and delivery challenges.

The Benefits and Challenges of Using Rust

Rust requires significant time to become proficient, but it excels in string processing and command line tools.

The speaker emphasizes the importance of simplicity in programming and avoiding unnecessary complexity.

They share their experience of transitioning from Node.

js to Rust for better performance in processing tasks and highlight the importance of choosing the right tool for the job.

The Impact of Noob Experiences on Team Empathy

The speaker discusses the value of feeling like a noob in a production-critical environment, suggesting it fosters empathy for less-skilled team members.

They argue that passion for DevOps should be the driving force, rather than a sense of obligation.

The speaker also highlights the challenges of addressing skill gaps within a team and the importance of long hours of work, suggesting a complex interplay of passion, motivation, and life circumstances.