Stepping outside your role - how to gain an edge at work

Source: Dev.to

Why I started

Recently my project at work moved from development to a maintenance stage. For me, that felt less like a problem and more like an opportunity.

• I began doing smaller work for other products, which was refreshing after ~4.5 years on a single product.
• I was nudged toward writing more automated tests. I helped when needed, even though testing isn’t my favorite activity. At first I saw it as an inconvenience, but now I view it as a positive.

I realized I had become the “go‑to” person for any topic, even those most people would avoid. As a frontend developer I’ve written automated tests, configured Kibana dashboards, built a performance‑test dashboard, and created a full‑stack emergency app. I’ve also started working with our backend, which is written in Java (reactive Spring Boot).

Why do something that nobody wants to do

Specialisation is important, and there is a place for deep experts. However, only a small percentage of engineers reach a level of specialisation that outweighs the value of a solid senior developer.

• Specialisation makes sense in large teams with clear boundaries or when you’re building a deep‑expert profile.
• In smaller teams or during long maintenance phases, being able to cover more ground usually pays off more.

In my view, most of the time there’s a need for engineers who simply get things done—the role I now aim to fill.

Doing a variety of small tasks lets you learn new things while getting paid for it. Side projects also teach you, but “for free.” At work you’ll inevitably encounter topics outside your comfort zone, and you never know when you’ll need that knowledge later. The more diverse tasks you take on, the more room you create for the work you truly care about—my next point.

Java as a tool, not a target

This year I’m trying to lift my full‑stack skills by writing more backend code. My first step was a tiny optimisation: avoid an unnecessary SQL query when we already know it isn’t needed.

Context
We have stocks of products and related products (the latter are relatively rare). In the function that builds the related‑product DTO we:

1. Pass a map of related‑product IDs.
2. Call the stock service.
3. Build the DTO.

If the map of IDs is empty, the stock call is wasteful. The optimisation was simply to skip that call—only three lines of code, but it took me a whole day to locate the relevant spot in the codebase.

I don’t consider myself a Java person and have often told myself I don’t like it. I suspect that bias comes from my familiarity with JavaScript, where everything feels “easier.” I’m now trying to shift my mindset from closed to open: treat Java as a tool for becoming a better full‑stack developer. Seeing it this way makes me more willing to learn and, perhaps, to like it.

Example of how my work looks based on a sprint timeline

Starting small worked for me, and I gradually took on bigger tasks. Over three sprints the breakdown looked like this:

Sprint 1

• Automation tasks – 5 story points
• Small backend task & repo setup – 3 story points

Sprint 2

• Slightly bigger backend task – a low‑severity bug – 3 story points
• Automation tasks – 3 story points

Sprint 3

• More important backend task – cost optimisation by switching an endpoint from REST to a queue – 5 story points
• Automation tasks – 3 story points

You can see a clear progression toward more complex work. As I become more comfortable with Java, I can reduce the automation load and deliver higher‑value backend features. My perception within the team is also shifting—I’m receiving more trust. One of the tasks even required me to own an end‑to‑end feature: I defined the API, wrote the backend implementation, and integrated the frontend.

Along the way I’ve learned about hexagonal architecture and Domain‑Driven Design (DDD). The key lesson: start small, then gradually take on bigger tasks. This builds confidence—for both you and your coworkers—and balances learning with delivering value.

Conclusion

When a project enters a maintenance phase, it’s an ideal moment to start learning new things. You can:

• Gain an edge at your current job (or future ones).
• Build confidence in your skills.
• Avoid rushing—ask for small, incremental tasks and grow into larger ones.

Adopting a learner mindset and staying open to new challenges lets you find pleasure in both learning and doing work that might initially feel outside your comfort zone.

The team. Sometimes we don't like new things because, at the start, we are bad at them. When you are a developer with plenty of experience, it can be hard to swallow your pride and start from a beginner level. But try it. I've been trying it for a month now, and I think it will be worth it.