There are many blogs about coding horrors. There’s even a blog called “Coding Horror.” As I gained a decent amount of professional experience, different leadership roles in development began to emerge. Some were formal and planned, while others were informal, where I had to step in simply because no one else wanted to handle the challenges. This happened to me a few times throughout my career, where I had to step up and take on the responsibility.

When it comes to software development, I split problems into two categories. The first category involves moving parts, which mainly includes people over whom I have some influence but no direct control. This blog will focus on the first category—moving parts, or people—what they mean to me, and how to effectively deal with them.

Designers are usually creative types—some can be a bit chaotic, while others are more organized. The level of “chaos” a designer brings often inversely correlates with their creativity. It’s crucial to understand the type of designer you’re working with. If they’re highly creative, they might also be somewhat disorganized (though not always), so it’s important to closely follow their designs and point out mistakes, like uneven margins or too much variety. Let them be themselves, but step in to apply the brakes when needed, and everything will work out fine.

An uncreative, neat designer is often a former developer who transitioned into design. They’ll deliver everything by the book, and their work will usually be flawless in terms of execution. However, because they lack creativity, the result may appear too bland. When working with an orderly designer, you’ll need to participate in brainstorming sessions, or someone else will, to avoid producing sterile designs that some clients may find unappealing. If you’re involved in team selection, choose creative designers for flashier apps aimed at a younger audience and orderly designers for back-office applications or projects that need to have a more professional tone.

Backend developers are the ones we tend to envy since they don’t have to deal with as many moving parts as we do, and they can do most of their work right in the terminal. That’s just my pro-backend bias talking. Working with backend teams is usually straightforward. I find it best to have open conversations and discussions about the areas where our work overlaps—things like the request-response cycle, APIs, payloads, and security. Once everything is clearly defined and we’re on the same page, API integration becomes a breeze. We’re often mentally aligned when it comes to problem-solving, which makes communication smooth and efficient.

QA specialists are the ones every frontend developer loves to hate, but they are essential to every process. Developers have a “solve the problem” mindset, while QA specialists have a “create the problem” mindset, and that’s where the friction arises. But it’s not really a problem—it’s actually the solution. After all, how can I solve an issue if I don’t know it exists? QA will point that out for me! While they sometimes drive me crazy, especially when I have to fix something I consider less important at the moment, it’s crucial to cooperate with them. Addressing problems early will save a lot of headaches down the road. I’ll also try to build a good relationship with them so maybe, just maybe, some of my bugs can become features.

Project Managers (PM), Product Owners (PO), and Scrum Masters are your best allies. They are the ones who help me stay on top of everything. It’s important to work closely with them and follow their lead. It’s also smart to give them input on organization. For example, if I’m leading a team of 10 people, it’s easy to lose track of who’s doing what, and these folks are there to help with that. With a well-organized Kanban board, everything will stay tight and neat, as long as I have a clear reference of what’s happening. They are also my line of defense against unreasonable requests within a project. They serve as the best source of truth. Therefore, having a clear line of communication with them is essential. If they don’t understand a particular aspect of development, I’ll gladly explain it. It’s important that we stay on the same page.

These are all the moving parts I’ve encountered in my career as a software developer, and this is how I approach working with them, how I utilize their strengths, and how I perceive their roles. Some may disagree, and that’s okay—everyone has their own dynamics. In my next post, I’ll dive into a development cycle I refer to as the Planning-Decision/Delivery-Execution cycle, and how I approach it effectively.