Weeknotes: 1st June 2020
This week I tried to handle my stress.
The last couple of weeks I’ve been quite stressed. My new service involves working on a vast existing stack which is intimidating and recognised as being a bit janky.
A bit of background: a few years ago we thought it would be sensible to build two back-office systems into one stack. It would mean sharing common code and allow developers to work across both systems at once.
Years later we regret it. The two systems simply aren’t similar enough and we’re now inextricably tied together. Product decisions are hard to make because they typically affect both services.
And it’s a nightmare as a developer. I’ve found myself trying to fix bugs only to cause them for a team working on something different. I’ve had to negotiate changes with other teams. Our release schedule is tied to other services (so e.g. there’s no hotfix process available).
Add to that the multiple technologies, libraries and patterns, and it feels like stumbling around in a dark room full of mousetraps.
Fortunately, I’m surrounded by a great team who I trust. So I can deal with this stress rather than letting it hurt me.
Firstly, I told everyone about it. It’s easy to feel weak or vulnerable when stressed, but it’s an indication that something in the business is wrong. If you feel uneasy speaking up, then the stress will never dissipate, you’ll resent your job, and it’ll hurt you worse.
I talked to my team, close colleagues and our lead developer. They were all supportive and keen to understand the cause of the stress so that could help resolve it. Just feeling like people were on my side helped me personally, and I’m sure it will lead to other decisions to help move forward.
Secondly, I tried to identify the root causes of my stress. That’s hard, because the very nature of stress makes it difficult to focus and, frankly, everything feels awful. I made progress by writing notes of my concerns, then a few days later reviewing them and narrowing them down further. Ultimately it came down to:
- Feeling like I was doing bad quality work
- Having too much responsibility
- Not having enough ownership
- Worrying about getting in others’ way
- Not having an opportunity to develop myself and my skills
Lastly, I spoke to my line manager and principal developer. He encouraged me to go back to focusing on problems and solving them, because that’s what we do.
And, ultimately, my stress seems to come to a simple solution: we need to smash this codebase in half and separate the two systems. It won’t be easy, or fast, but it benefits the business and deals with my causes of stress:
- Building components from scratch, I can build them to my standards
- I’ll be responsible only for our service, not the other one
- I’ll (we’ll) have direct ownership, rather than awkwardly sharing it with others
- There won’t be other teams/services to bump into
- There’ll be lots of new work and I can identify opportunities to improve myself
That conversation was yesterday, so I’m still digesting my new-found clarity. But it’s a good place to start.
Next week I’ll focus on a few things
- Getting buy-in from colleagues that we need to look at splitting
- Documenting the problems splitting will solve
- Identifying opportunities to easily split the codebase
- Identifying dependencies and blockers that might inhibit splitting or the order in which we do it
My worry now is that all of that might lead to more stress. But I’m starting to develop the tools to manage and handle that, and hope I can use them again to focus on what I can do right now and document the rest.
I’ll hopefully update in a couple of weeks in how that’s going.