I love gatherings where people come together to share ideas, pizza, and beer. Whether it’s with students or developer communities, I often get asked to define what it means to be a Senior, Junior, or—worse—Semi-Senior.

Let me just say it straight: I don’t care at all. These labels are at the very bottom of my worry list. Compared to everything else I could be thinking about, these definitions simply don’t matter. I don’t care if they change, stay the same, or disappear altogether. So yeah, it’s fair to say there’s almost nothing I care less about than these definitions.

(Although, I’ll admit… I feel a bit bad for dragging you through this! Since you’re already here, let me relax and try to explain it anyway.)

Let’s analyze this issue from another perspective to see if we can focus on what really matters.

Junior, Semi-Senior, and Senior—Do They Really Matter?

We could spend hours debating what a software engineer should know, do, or be responsible for at each level. But in my opinion, a simple way to measure a developer’s “maturity level” is by looking at how well they can handle their daily tasks autonomously.

How do you know if someone is autonomous? Easy. If they can do their job without someone constantly looking over their shoulder, they’re autonomous. Usually, they’re motivated, know what they’re doing, and can handle their responsibilities well. They’re good at prioritizing, completing tasks on time, setting their own goals, and working hard to reach them.

Why does this matter? Well, we’ve seen that to thrive in startups, workers need independence: the ability to adapt to changing circumstances, solve problems creatively, and take initiative when needed. This applies to every startup, but for tech-driven ones, having autonomous software developers isn’t just nice—it’s a necessity.

Tell Me Your Daily Routine, and I’ll Measure Your Seniority

Imagine a developer describing their work like this:

“Usually, I start my day by checking my task board. I grab the first card (the most important one) from the To-Do column, move it to In Progress, and start coding. Most of the time, I ask other developers how to handle certain coding or design things. I rarely attend many online meetings because I like to stay focused on my board, maintain productivity, and finish all the tasks assigned for the current project phase.”

This description screams ticket closer: someone who mainly spends time knocking tasks off a board, with little impact on team-level decisions. They seem more like executors than thinkers, lacking influence in planning or strategy. That could be due to limited experience, misalignment of their ideas with the team’s direction, or simply not having had the chance to contribute.

Still, being a ticket closer isn’t always bad. It shows they’re reliable, solid at solving problems, and—given the right chance—they could become key contributors in team conversations.

Now, check out this second description:

“I usually grab tasks from the board and start working. While I’m at it, people often ask me questions about different issues. We’ll usually have a quick brainstorming session where I pitch in suggestions to solve the challenge, interacting with teammates in our digital workspace. Sometimes, if I feel something is critical or harmful to the business, I dive in to fix it before returning to my previous task.”

This points to a problem solver. These developers are flexible, visionary, and strong communicators. They can juggle multiple tasks, manage their time well, and prioritize what’s most urgent for the business. They’re good collaborators, actively engaging with teammates to fix problems and share knowledge. They step up when things get tough, but they’re also there to support others—without letting their own coding fall behind.

And then there’s this last description:

“I love starting my day by scanning the In Progress column to see if anything’s stuck. If I spot something, I check in with the developer on it. We usually end up pair programming until it’s fixed. That often leads me to identify issues or opportunities that align with our long-term strategy, so I add new tasks to the backlog. When I’m not coding alongside others, I’m either tackling basic tasks or deciding which ones will make the biggest impact in our next iteration.”

This is what I call a problem organizer. They’re the ones who can spot challenges or opportunities, shape them into detailed backlog items, and decide whether to prioritize them. Their decisions are guided by business understanding, strategic discussions, and hands-on experience.

But that’s not all. At their core, they’re still developers—so they need broad knowledge of programming languages, tech concepts, and software development practices. They’re not just coders; they’re system designers, independent problem-solvers, and innovative thinkers who keep learning to stay sharp. They keep the team aligned on progress and blockers, and they’re committed to delivering high-quality results.

Conclusion

So what does all this have to do with my rant against the labels Junior/Senior? Well, I bet you’ve already made the connection.

If you twist my arm, I’d define a Junior as a ticket closer, a Semi-Senior as a problem solver, and a Senior as a problem organizer.

Why do I think this definition makes more sense? Because it ties back to autonomy. If someone only completes tasks and often asks coding-related questions (ticket closers), they’re less independent than those who define new tasks and support other devs (problem solvers). If you can solve problems independently, help shape tasks, and still collaborate with teammates, you’re more self-sufficient. And at the top level, problem organizers don’t rely on anyone else—they’re the ones who can tell their boss, “That’s an interesting idea, but my time is better spent elsewhere”—and not get fired for it. That’s maximum autonomy.

As we like to say at Howdy: the office is wherever your heart is, meaning that being able to work remotely and independently lets you be efficient while enjoying life at the same time.