From time to time at work I come across big projects or user stories. They’re so huge that I can’t keep the whole picture of them in mind. I can have a vague idea what I need to do, but as soon as I start working I hit the wall. These overwhelming projects are made of hundreds of decisions to make or actions to take.
Example problems that requires decisions as a part of a bigger project could be:
- Should I create a new bucket for the documents or use the existing one. And what should be the bucket configuration?
- What should be the URL path for the new API? We have new API guidelines. But the API we’re going to create sits in the old service which follows the old approach. Should we ignore the guidelines and risk inconsistency?
- Should we refactor now or later (so never)? If we don’t do it now we can’t write tests for the new code.
- Can we remove that image for simplicity? Otherwise we would have to fetch it from the other service and the logic becomes complex.
- Should we automate that workflow or write a script for now? The former would also need a new API. The latter can fetch data from DB directly and we don’t know if the script will be still used in 2 months.
- Is the solution I proposed secure / GDPR compliant? Could users abuse it?
Sometimes I feel like I’m completely stuck. No matter which direction I want to move, there is a blocker. Or I’m waiting for someone. Or I need a decision to be made.
And most of the time it’s me who has to make that decision. Each option has downsides, and it’s hard to decide which trade-off is the best. That makes me feel helpless.
But a senior engineer should be independent. My role is to deliver solutions to the problems and make the best decisions with the information at hand (or get that information if it’s missing).
At school I’ve learnt about the divide and conquer approach. In theory it relates to algorithms. But maybe we could translate it to daily work? We could break the big project into smaller tasks. I do it by asking myself what are the next possible things I could do. I’m listing all the steps.
Once I have an idea how to approach the project, I would like others’ feedback. I value people’s time. Thus, I prepare a few solutions in advance. I never settle on the first idea.
I describe my approach, both high level and detailed. I list pros and cons. It is much easier to get feedback on something tangible. This scenario is one example why writing is important for software engineers.
Additionally, it helps me surface blockers before I even start coding. I explicitly name all the steps, going into details, to list as many questions as possible:
- How are we going to call this table in the database?
- How are we going to secure this endpoint?
- Are we going to apply a rate limiter on this API?
- How are we going to monitor for potential fraud?
- Where can we take the information X from?
- …and so on.
This way I can proactively solve potential issues, before they accumulate.
This approach works for me. In theory, being proactive requires more effort. I could have relaxed at work waiting for someone to unblock me. But I also take my mental health into account. I feel much better after hard work and gaining results than after a few hours of doing nothing.
