Understanding Your Audience as a Software Engineer

Let's start with the obvious—software engineering isn't just coding. Yeah, no-brainer, right? But let's be honest, it's quite easy to forget in practice. We're all guilty of doing so. After all, what could be better than sinking into your comfy chair, slipping on noise-canceling headphones, looking at your 4K monitor, and diving straight into code using your favorite editor and a custom mechanical keyboard? This is the absolute best part of our job, isn't it? If you got chills and/or smile on your face you know exactly what I'm talking about. Unfortunately, there has has never been a job in history that consists only of fun parts (well, that's why it's called a job and not fun to begin with). Software engineering is no exception. More often than not, software engineers are labeled as self-preserving introverts (thank you, Hollywood for cementing that stereotype), while it's not wrong, it's not exactly accurate all the time. I'm an introvert by nature, but software engineering actually taught me how to switch gears and be more social, because, surprisingly enough, software engineering is a pretty social activity. Usually we don't just sit alone in a creepy dark room full of servers, wearing sunglasses, smashing all the buttons at once, and magically generating random green characters on the screen for no reason (BTW, the famous green code from the Matrix is actually just Japanese sushi recipes from one of the movie designer's cookbooks at home). Instead we usually work as a part of a team where each member contributes their pieces of the puzzle that eventually come together as a finished product. At the time of writing this article (03/23/2025), I've been professionally coding for almost 8 years, and if there’s one thing I’ve learned, it's that effective collaboration between teammates is absolutely critical (whether they're developers or not). When you become a software engineer, you immediately find yourself engaging with multiple audiences. The trickiest part? These audiences are totally different from one another, and each requires a unique approach. Disclaimer: Unlike some, I'm not against higher education like colleges and universities because they provide a valuable set of skills essential for a professional career (TODO: this deserves a separate article). However, this particular skill isn't something you can learn in a classroom. It’s something you develop through real-world experience—by recognizing patterns, adapting to different situations, and figuring out what works best in each context. Throughout my software engineering career, I’ve worked in almost every type of role—full-time and part-time, on-site and remote, at startups and enterprises. I’ve been part of large teams, small teams, Scrum teams, and completely independent teams. I’ve worked as a solo developer, junior/middle/senior developer, managed development team(s) as a principal software engineer, collaborated across departments, and navigated both fast-paced agile environments and structured corporate settings. Each situation was quite different in terms of understanding and managing my audience; however, certain patterns consistently apply to any situation. My goal for the rest of this article is to narrow them down to the most common ones. First, let's list the main roles you might interact with (the list might not be perfect as different companies can have different structures, roles, policies, etc.). CEO/CTO Engineering Managers Product Managers QA Engineers UI/UX Designers Support Teams DevOps Engineers Clients Users (sometimes users and clients are the same, but not always) Other Developers Other Roles As a developer, you need to understand how to interact with these roles; however, there are only a handful of positions that can be considered as your core audience; they have special front-row seats to your performance. These are as follows: 1. Users Whenever you write code, you always do it for someone. It could be: A public-facing application used by customers A library consumed by other developers A back-end service facilitating machine-to-machine communication Even if you're creating an application for yourself, you still have a user/client/customer—yourself 2. Other (peer) developers Alright, this is a major topic and deserves a whole separate article (TODO: expand on this in the future). However, let's cover the most important and critical aspects:

Mar 25, 2025 - 20:48

Understanding Your Audience as a Software Engineer

Let's start with the obvious—software engineering isn't just coding. Yeah, no-brainer, right? But let's be honest, it's quite easy to forget in practice. We're all guilty of doing so. After all, what could be better than sinking into your comfy chair, slipping on noise-canceling headphones, looking at your 4K monitor, and diving straight into code using your favorite editor and a custom mechanical keyboard? This is the absolute best part of our job, isn't it? If you got chills and/or smile on your face you know exactly what I'm talking about.

Unfortunately, there has has never been a job in history that consists only of fun parts (well, that's why it's called a job and not fun to begin with). Software engineering is no exception. More often than not, software engineers are labeled as self-preserving introverts (thank you, Hollywood for cementing that stereotype), while it's not wrong, it's not exactly accurate all the time. I'm an introvert by nature, but software engineering actually taught me how to switch gears and be more social, because, surprisingly enough, software engineering is a pretty social activity. Usually we don't just sit alone in a creepy dark room full of servers, wearing sunglasses, smashing all the buttons at once, and magically generating random green characters on the screen for no reason (BTW, the famous green code from the Matrix is actually just Japanese sushi recipes from one of the movie designer's cookbooks at home). Instead we usually work as a part of a team where each member contributes their pieces of the puzzle that eventually come together as a finished product. At the time of writing this article (03/23/2025), I've been professionally coding for almost 8 years, and if there’s one thing I’ve learned, it's that effective collaboration between teammates is absolutely critical (whether they're developers or not).

When you become a software engineer, you immediately find yourself engaging with multiple audiences. The trickiest part? These audiences are totally different from one another, and each requires a unique approach. Disclaimer: Unlike some, I'm not against higher education like colleges and universities because they provide a valuable set of skills essential for a professional career (TODO: this deserves a separate article). However, this particular skill isn't something you can learn in a classroom. It’s something you develop through real-world experience—by recognizing patterns, adapting to different situations, and figuring out what works best in each context.

Throughout my software engineering career, I’ve worked in almost every type of role—full-time and part-time, on-site and remote, at startups and enterprises. I’ve been part of large teams, small teams, Scrum teams, and completely independent teams. I’ve worked as a solo developer, junior/middle/senior developer, managed development team(s) as a principal software engineer, collaborated across departments, and navigated both fast-paced agile environments and structured corporate settings. Each situation was quite different in terms of understanding and managing my audience; however, certain patterns consistently apply to any situation.

My goal for the rest of this article is to narrow them down to the most common ones.

First, let's list the main roles you might interact with (the list might not be perfect as different companies can have different structures, roles, policies, etc.).

CEO/CTO
Engineering Managers
Product Managers
QA Engineers
UI/UX Designers
Support Teams
DevOps Engineers
Clients
Users (sometimes users and clients are the same, but not always)
Other Developers
Other Roles

As a developer, you need to understand how to interact with these roles; however, there are only a handful of positions that can be considered as your core audience; they have special front-row seats to your performance.

These are as follows:

1. Users

Whenever you write code, you always do it for someone. It could be:

A public-facing application used by customers
A library consumed by other developers
A back-end service facilitating machine-to-machine communication
Even if you're creating an application for yourself, you still have a user/client/customer—yourself

2. Other (peer) developers

Alright, this is a major topic and deserves a whole separate article (TODO: expand on this in the future). However, let's cover the most important and critical aspects: