The Hardest Part Isn't Being Invisible—It's Being Flattened Into One Dimension

Source: Dev.to

The Problem of Compression

My previous article used the language of “visibility” because that’s the vocabulary developers share. We talk about disappearing quietly, becoming ghosts in our own lives, losing presence. That framing is real—it matters, especially for those who feel erased by remote work, asynchronous communication, and the quiet competence the industry rewards.

But that isn’t actually my problem.

• I’m introverted.
• I’m private.
• I don’t mind being invisible. In fact, I lean into it.

The quiet mode of engineering—the low‑friction, low‑visibility, high‑autonomy channel—is where I operate best.

The real threat isn’t erasure by others. It’s compression: the slow collapse into a single function, becoming only the part of you that produces. Developers don’t just disappear. We flatten.

The original article diagnosed one problem—disappearing—where others stop seeing you, and eventually you stop seeing yourself.
A second, quieter problem looks similar from the outside but feels completely different from the inside: collapsing. You remain present, but only as one thing.

• You’re still there, but you become only the reliable node, the problem‑solver, the person who unblocks the pipeline, the function.
• You don’t vanish. You compress. That’s the failure mode I resist.

I don’t need to be seen to feel real. I don’t need social presence to feel alive. I don’t need external recognition to maintain identity. Invisibility is not the enemy; it’s a comfortable operating mode. What I refuse is one‑dimensionality—the reduction of a whole person into a single operational register.

Software work is optimized for reliability, predictability, low emotional footprint, asynchronous execution, and frictionless output. These traits make you effective. They also make you flat. The longer you stay in that mode, the more the rest of you dissolves—not because anyone erased you, but because the job only exercises one part of your architecture. You become a single‑axis creature.

Why Ballroom Helps

In my previous piece, I framed ballroom as a domain where you “can’t disappear,” where you’re “seen whether you want to be or not.” That language was true, but it wasn’t the point.

Ballroom isn’t my antidote to invisibility. It’s my antidote to compression. Ballroom forces me into registers engineering never touches—physical, rhythmic, expressive, relational, partnered, aesthetic, competitive, embodied. It’s not that I’m “seen.” It’s that I’m plural.

Ballroom keeps me from collapsing into a single operational identity. Teaching competitive students on Sundays is the part that reveals the real architecture.

Engineering vs. Teaching

Engineering

• Excellence is extractive.
• Your clarity gets mined.
• Your competence becomes a resource others consume.
• Your identity narrows to your utility—you are what you produce, and what you produce is what gets pulled out of you in meetings, late‑night Slack messages, “quick reviews” that are never quick.
• The better you get, the more you become a function that other people call.

Teaching

• Excellence is generative.
• Your knowledge stays yours even as you transmit it.
• Your leadership isn’t consumption—it’s cultivation.
• Watching someone execute a technique they couldn’t land last week extends you rather than diminishes you.
• Your identity expands instead of compressing.

Teaching is not about being visible. It’s about being more than one thing.

Conclusion

• Some developers need visibility to feel whole.
• Some need community.
• Some need recognition.

I need dimensionality.

I need a second discipline that keeps my long‑arc identity alive. I need a domain where excellence is embodied, not extracted. I need a practice that forces me to inhabit registers engineering doesn’t use.

Ballroom isn’t where I go to be seen. It’s where I go to stay three‑dimensional—rhinestones, frame, breath, and all.