Over the years of solving problems, mostly as an Individual contributor, I realised the importance of having a process while trying to solve a problem even if it has been solved million times by someone else. As a Software engineer, it is important that you deeply understand the problem before solving them, and while there might be many ways to solve, I will share a process that worked for me every single time.
1. Research & Breakdown:
There are frameworks to break down a problem into smaller chunks to be able to wrap your head around it. This allows you to look deeper into the problem and connect the dots in the context of your application.
Research if similar problems have been faced/solved by others.
Rethink solutions proposed by the Product team.
Question the intent: Why is this necessary? What will change after implementation?
Consider alternative ways to achieve the same business goal.
Identify the metrics that will be useful to decide whether solution was a success post-implementation and how to make them available for your Product team.
Benefits of following a process is that it will always result in lesser bugs and predictable timelines. Whether you are a fresher or senior engineer, create a process for yourself that you can rely on.
2. Technical Documentation & Scoping:
Think about the extensibility of the solution - can it be divided into reusable components?
Document the API contract between the frontend and backend engineers.
Breakdown the feature to cover all relevant aspects: backend, frontend, DevOps, database, analytics, test cases, and hosting (if required).
3. Estimation & Communication:
Once clear on the problem and solution, estimate the time required for release.
Assign T-shirt estimation to the smaller problem chunks from step 1.
Ensure singular focus: work on one and only one project at a time.
Let’s admit, following a process is hard and I am no exception. In favour of early deliveries I jumped into writing solutions without attempting to understand the business needs. As an Engineer it’s important to empathise with the end user and understand the business value this opportunity will bring. Had I followed the process, I wouldn’t have had to burn the midnight oil closer to the delivery dates.
4. Handling Scope Creeps:
Inquire about the necessity of the scope change.
Evaluate if the current scope can be released, followed by immediate changes.
If scope change is unavoidable, communicate the delay it will cause to the project to all stakeholders, be it in days or hours.
5. Addressing Other Projects or Bug Fixes:
Evaluate the severity of the bug.
Determine if the bug can be addressed post-completion of the ongoing project.
If an immediate shift is essential, communicate the delay it will cause to the ongoing project.
Bonus:
Always stick to these points, no matter what your inner engineer says
Take ownership of the solution as much as possible.
Metrics - Always track success metrics not just because Product team could use it but to understand how your solution impacts the end user.
Do not write business logic in the UI.
Every time a decision has been made, it should reflect on the ticket or the technical document.
Let me know if you have a process that worked well.
GD!!
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.