Labels like “junior” and “senior” engineers are often used to define a developer’s role based on years of experience. But do these labels really capture a developer’s true value? While experience can shape skills, it doesn’t always reflect the initiative, ownership, or creativity that a developer brings to the table. Sometimes, a so-called junior can outperform their senior counterparts in ways that truly matter.

So, if years of experience aren’t the whole story, what should we be looking for in developers? Let’s challenge these conventional labels and explore a more meaningful way to think about developer impact.

Also read: On being an expert

Why “junior” and “senior” labels fall short

Often times, seniority is measured by years of experience. A developer with a decade or more in the field is often called “senior,” while someone with only a few years is considered “junior.” But this distinction based on time can be very misleading.

For instance, a junior developer might lack certain technical skills or experience, but they make up for it by showing a high level of drive and initiative. They could be assigned a small feature to work on, but instead of stopping there, they take a holistic view of the product, identifying potential improvements or proposing long-term solutions. This developer, despite their lack of experience, demonstrates responsibility and ownership.

Reading tip: Never hire senior developers (*)

On the other hand, a senior developer might possess a wealth of technical skills and years of experience but resist adapting or thinking differently when necessary. They may complete tasks efficiently, but they stick rigidly to what’s assigned, focusing on execution without considering the broader product strategy. In this case, their experience doesn’t translate into the initiative or willingness to challenge the status quo.

In an ideal world, qualities like ownership, proactive thinking, and a contribute to the product would define seniority. However, seniority is still too often tied to years in the field and/or technical experience, even when a less experienced developer may contribute more effectively.

Push vs Pull Developers

To better understand how developers contribute to a team, I like to think in terms of being a push or pull developer. Whether someone is waiting for instructions or actively seeking out work defines their impact.

  • Push Developers: These developers tend to wait for work to be assigned. They execute tasks when given clear instructions, often following a ticketing system. They work reactively and may not look beyond the immediate task in front of them. You need to push work to them.
  • Pull Developers: These developers seek out work. They take ownership of projects, think ahead, and proactively find ways to contribute. They’re the ones pulling work toward themselves, constantly looking for ways to move the product forward without needing detailed instructions.

Conclusion

Having enough pull developers in your team can make a big impact. At madewithlove, we often use the term “a responsible developer” to describe the type of developer who embodies this proactive, ownership-driven mentality. A responsible developer takes full responsibility for the product’s quality and success, not just their individual tasks. It’s not about years of experience—it’s about stepping up, thinking critically, and ensuring the product moves forward with purpose and care.

This is the kind of developer every team needs.