When we look at it with a straightforward logic, we as frontend developers are considered to be at the end of this flow, because a need or problem arises, ideas are generated to address this problem, designs are created, and then it comes to the developer, resulting in output being produced and presented to users. However, what we overlook at first glance, but which is the most important element that determines this flow, is that we are the ones providing the output. Therefore, parameters such as our competencies, availability, the ideas we can contribute, and our prioritized tasks become critically important in producing a solution to this problem. Because until this point, the work that comes quickly does not serve much purpose if we get stuck and it does not reach a conclusion. Let’s say we have a new product produced by unit X that requires a suitable panel to be written. Here, the fundamental expectation is that this panel is completed at the latest with the product and meets the needs 100%. Once this request reaches us, how we respond to this request, our discussions regarding it, the feedback we provide about suitability, and other reactions can affect the flow, possibly even creating a need for a complete change for some modules.
If we delve a little deeper, before responding to this request, if discussions for the frontend side have started or if they are conducted by our upper management before the request reaches us, the most fundamental issue and the first point of discussion is how this project will be executed, with which framework, and on what kind of system it can be built. Let’s consider that there are options a, b, and c which are similar in terms of the results they will deliver on the end-user side. In deciding here, the competency of developers who can work on the project comes into play. If done with option A, the learning process would take 10 months because the selected developers are not sufficient for this project; if done with option B, we have 1 developer suitable for this, so it could take 8 months; if done with option C, we have 2 developers whose competencies are appropriate, and we could achieve a result in as short as 3 months. Here, since both the completion of the work and the cost align with option C, we proceed with that. In such matters, as the ball continuously comes to us and the most suitable path is found, both the workflow and designs proceed in this direction, allowing the project to be completed without errors in a very short time since it’s clear how to move forward.
If the topic were not this way and there was a straightforward flow where ideas were generated, designs presented, and you were simply told to do it this way, there could be a 100% inability to respond to requests due to a lack of mastery of the subject and also the risk of inappropriate choices, potentially delaying the completion of the project and leading to unforeseen costs.
It is possible to multiply examples like this, but essentially, when decisions are made at every step that will be shown to the user, the statements of us frontend developers hold great importance in being able to conclude the work in the fastest and most appropriate way.
