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

# career# devjournal# productivity# testing
Stepping outside your role - how to gain an edge at workAdrian Mostowski

Original post Why I started Recently my project at work started to be more at a...

Original post

Why I started

Recently my project at work started to be more at a maintenance stage than development. However, for me as I interpreted it, it felt more like an opportunity than a problem. First of all I started to do some smaller work for other products. It was a good thing for me because I felt a little stuck working more or less for 4.5 years on one product. The next new thing was a little more of a hindrance for me because I got a hint that I might write more automated tests. Sometimes I helped with that if that was needed but it isn't my favorite thing in the world. At first I treated it like an inconvenience. Now however I think that's a good thing. I realized that I was working for the image of a person "to go to" for any topic even if it's a thing that most people would feel that it isn't their cup of tea. As a frontend developer I sometimes wrote automated tests, configured Kibana dashboards, created a dashboard for performance tests or wrote a full stack emergency app. Now I also started working with our backend which is written in Java (reactive Spring Boot).

Why do something that nobody wants to do

Of course specialization is very important and there is also a place for people who are very specialized in one topic. Nevertheless there is only a small percentage of people who have the guts and strength to get into a level of specialization which is more valuable than a regular senior developer. When does specialization make sense? Often 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. As I view it most of the time there is a need for engineers who get things done. And that is the person I now try to be.

Most often when you do these different little things you can learn something new and get paid for it. When you do your side projects you learn something new but for "free". Of course at the job there is a good chance that you have to learn something that's not in your interest zone but you don't know what you will need some day. And when you do more and more things like that you can gradually make room for the work you care about. Which is my next point.

Java as a tool, not a target

As an example of this - this year I'm trying to get my fullstack skills to the next level and for that I'm trying to write more backend code. Firstly I took a small optimization task which was to not call the SQL query if you know you don't have to. It was like 3 lines of code except that it took me a whole day to find myself in the code. To give some context what was the task: We have stocks of products and related products. Related products are relatively rare. In the function that builds the related product we pass a map of related products IDs, call for stocks and then build a DTO. But there was an unnecessary call for stocks if this map of IDs was empty. And that was the whole optimization. This was small task but I don't really know Java and I always tell myself that I don't like it. Now I'm trying to shift my mindset from closed to open and try it despite that. I know that maybe I didn't like Java because of my familiarity with JavaScript. I just always thought that everything is easier in JavaScript. Now I'm treating Java as a tool for becoming a better fullstack developer. When I see it that way I'm more open to learn it and use it and maybe I will like it (I think I will).

Example of how my work looks based on a sprint timeline

In my case starting small worked and I incrementally took bigger tasks. In the course of 3 sprints it looked something like this. I tried to balance things that have bigger value for me now (automation) and things that I want to learn (smaller tasks that aren't that important now).

Sprint 1:
  • Automation tasks (5 story points)
  • Small backend task and repo setup (3 story points)
Sprint 2:
  • Slightly bigger backend task - a bug with low severity (3 story points)
  • Automation tasks (3 story points)
Sprint 3:
  • More important backend task - cost optimization by changing an endpoint to different source - queue instead of REST. Still relatively easy (5 story points)
  • Automation tasks (3 story points)

As you can see there is a progression of tasks that are more and more complex. I could also lower the automation tasks because now I'm more familiar with Java and I can provide more value for the team. I also see a change in the perception of my work. I see that I'm getting more and more trust. One of these tasks was given to me to do e2e - I'm creating the API definition, backend code for that and then implementing the frontend integration. I'm learning a lot and it's very nice to see progress just like in the old days when you start to learn a completely new language. I can see progress also in higher level architecture and design because I have to also learn hexagonal architecture and DDD. Key lesson from my current experience is that it's better to start small and gradually take on bigger tasks. It gives a lot of confidence (for you and your coworkers that you can do it) and it's a good balance between learning and providing value with other tasks.

Conclusion

When your project is at a maintenance stage it's a good time to start learning new things. You can gain some edge at your current work (or next if you want to change your job someday). It helps when your work becomes mostly maintenance and it's a good way to gain confidence in your skills. If you are a beginner at your new tasks don't rush yourself. Take your time, ask for small incremental tasks and gradually take on bigger ones. It's also important to have a learner mindset and be open to new things. With that you can gain pleasure from learning and from doing things that maybe you don't like but are important for the team. Sometimes we don't like new things because at the start we are bad at it. When you are a developer with plenty of experience it can be hard to swallow your pride and start from beginner level. But try it. I've been trying it for a month now and I think it will be worth it.