You know the funny thing about being a software engineer? A lot of us got into this career because we liked the idea of talking to computers more than people. Machines are predictable, rational, and (mostly) fair judges of effort. If something isn't working, the feedback loop is immediate. It's not subjective. No politics. No office drama.

And yet, as cozy as that sounds, it's unrealistic. It turns out the human side (the one we might have been trying to avoid) is just as essential. If you want to thrive in your career, you can't afford to be invisible.

Let's get one thing straight: invisibility isn't about your physical presence at HQ or how much you talk during meetings. It's about whether people know who you are, what you do, and why it matters. Because if they don't, your hard work might as well not exist. So, if the idea of "self-promotion" feels awkward or unnecessary, let's reframe that. Being visible isn't about boasting. It's about ensuring your contributions aren't lost in the noise.

Let's start with glue work. You know, the unsung heroics: code reviews, writing documentation, testing, refactoring, fixing those data migrations no one else wants to touch, performance and accessibility enhancements, etc. These are the things that keep the system together, even if they're not the splashy features that make it onto a quarterly presentation slide. But here's the rub: glue work is invisible to most people unless you're intentional about making it visible. When everything's running smoothly, people overlook the maintenance it took to get there. If it breaks someone might remember, but by then it's damage control.

If you're quietly refactoring that state manager or writing documentation for onboarding new folks to a project, don't just silently commit your changes and move on to the next task. Share the backstory with your team or manager. Say, "Hey, that performance slowdown we kept running into was because of XYZ in StateManager? I refactored it and added tests to prevent regressions. We've gained ABC on our scorecards and should make it easier to expand without issues going forward." There's no chest-pounding here, just giving people the context they need to appreciate the value of the work.

Still, I get it. If you're introverted or working remotely, this can feel like climbing uphill in the rain. It's easier to sit back and assume the work will speak for itself, but in reality it rarely does. In the chaos of deadlines, meetings, and Slack notifications, people don't always notice what isn't explicitly put in front of them. Visibility takes effort, but it doesn't mean you have to fundamentally change who you are.

Here are a few achievable ways to get started:

1. Document and share your work: Going beyond code comments, write up short summaries of what you've tackled each sprint. Post in a team channel, write a post (at GitHub we use discussions), or highlight it in a retro.
2. Be active on pull requests: Leave thoughtful comments and reviews (and not just nitpicks about formatting). Engaging in code reviews isn't just about strengthening the code base, it's also an avenue to demonstrate your thought process and let people see the quality of your engineering mind.
3. Speak up during meetings: Even remotely, you have opportunities to chime in. If you've worked on something relevant or have insights to add, don't hesitate to share. Even if it's just a brief, "I wanted to highlight X. we've seen improvement in performance since implementing XYZ." You don't need to dominate the conversation, just be present in it.

Now, beyond making glue work visible, let's talk about prioritization. If you want to be visible, work that aligns with the organization's priorities is your ally. If you're tinkering on side quests nobody has asked for, guess what? No one's paying attention. What's worse, when deadlines crush the team or major blockers flare up, that invisibility isn't going to work in your favor. Focus on initiatives that matter to the broader goals of the team or the company because visibility isn't just about broadcasting what you're doing it's about working on things others care about.

This doesn't mean you should drop everything to chase every flashy thing that crosses your desk. That's a recipe for burnout. But when you have the choice lean toward projects that have a clear impact, lift the team, or make the product demonstrably better. Fix the bug that has bugged QA for the last quarter. Build the feature your customers have been begging for. Do something where the "why" is interesting to your stakeholders. This is especially true if you're angling for a promotion.

I know there's a tendency to roll your eyes at phrases like "stakeholders" or "showing impact" and the like. It sounds corporate. But look, the reality is, software development isn't about writing code. It's delivering a product that meets the needs of users. If you want to be recognized for your work, you need to show how it contributes to that goal. And that means being visible about what you're doing and why it matters.

It also means choosing the right projects to work on, but that's a blog post for another day.

So the next time you think, "They should know what I'm doing," remember that they probably don't. And that's not a failure on their part it's an opportunity on yours.