A post about what, in my opinion, a developer should do when they are a Senior. I work in a product company, and our engineer participates in the development of a feature from discussing the product solution to implementation in production and analyzing the results. In other companies, the scope may be smaller, something may differ, but the basis will be more or less the same.

Why is this important?

I believe that every developer should understand what they are doing and how it affects the business. Writing code is not enough. Understanding the full flow helps make decisions. This is also called “product thinking.”

So let’s consider the following stages:

Preparation for development

1. At the stage when the product owner presents a new idea, it is necessary to understand what needs to be done. Identify unanswered questions, discuss edge cases, negative scenarios.
2. Determine the technical stack. If this is a new feature/service - technologies, libraries, programming language.
3. Create the architecture of the feature, develop a Tech Design document.
4. Discuss the test plan and test cases with the QA engineer. Identify what to pay attention to, edge cases, auto tests coverage.
5. Discuss with the business analyst which metrics to add (we will use) to conduct A/B testing.
6. Estimate tasks (in days, story points, spherical horses) and assess risks. Be ready to handle risks.
7. Plan the work in the team and also (if necessary) the work in neighboring teams (example: backend needs to create an API for the frontend).

Coding

1. Write code
2. Write tests

Preparation for release

1. Discuss with the product team how to release the feature (A/B test audience)

Release

1. Release to production
2. Monitor the feature in production. Zero-error policy
3. Track issues and fix bugs
4. Help the analyst analyze the results of the A/B test. If there is a drop in metrics in the new functionality, find problems and start a new iteration of the A/B test. A drop in metrics is an expected natural process of changes during the A/B test.

Cleanup

1. Remove the remnants of the A/B test from the code
2. Check the remaining tasks (leftovers) and prioritize them

Takeaways:

1. Every engineer as an individual contributor should be able to handle a task from start to finish. AND we do not devalue teamwork! We do not cancel PR reviews, team help, syncs, and pair programming. The idea is that the main “driver” (driving mechanism) that pushes the feature forward is the developer.
2. Not all stages are relevant to every task.
3. Each task has its own level of complexity. It can be coding complexity, it can be release complexity (many inter-team connections). So the overall complexity of the task is something in between these levels of complexity. It is important for the team lead to understand this when dividing tasks.
4. If you work in an English-speaking environment, English becomes the most important “programming language” (you use JS, Python, Kotlin, whatever only at the “Coding” stage, while other stages require communication with other teams or product people).

Do you think this is too much? 🙂