As far as I can remember, I have never worked alone.
Even when I started making end-to-end websites as a webmaster, from the very beginning, I involved graphic designers to help me with tasks that took too much time for me, but also to be more motivated, not only in my interactions with clients but also thanks to my collaborators and partners.
A couple years later, things started to be more complicated. It was the late 2000s and it was the time when early frameworks and CMSes were created. However to be beneficial from these it was one condition – learning new syntax, logic and style to learn on top of any other plain language or technology.
Spending time to learn anything I could potentially use to speed up with implementation or keep things more consistent was a big investment of time.
To be honest, it wasn’t always profitable to learn many of these. Later, it became too difficult to understand how the raw language or technology worked, so it was difficult to fill the gaps due to the limited possibilities of a framework or CMSes, and the lack of knowledge and experience in using the limitless nature of the language. So, I kept working with plain languages and anything that, at some point, due to complexity, had been split into more roles like frontend developer, backend developer, DevOps, and many more. This gave a narrower spectrum for developers to learn and master one discipline. Thus, collaboration gained greater importance, where a group of people worked on the same projects, communicating more often to be synchronized with the progress of their part of the project.
To be motivated and effective at work as an individual, being skilled in one’s own discipline and strictly aligned with one’s responsibilities is, in most cases, not enough to be successful. There are more factors involved in any project – non-technical ones.
End-to-end communication is the key.
Everything starts with knowing the goals set by project owners, which often lead to specific implementation plans and technical requirements. Developers are often not involved in discussions about the broader goals, budget, and timelines. Frequently, solutions suggested without input from the development teams are not precise or adequate. This is because decision-makers who do not involve developers, and thus lack technical insight and real-world use cases, may not see all possible solutions. Consequently, the underlying problem is often overlooked, and the focus shifts from collaboratively finding solutions to simply executing the stated technical requirements.
It’s quite obvious that any requirement is an implication of a problem solution. In most cases, these are business or user-related.
“Later, as part of the development process, sharing the status of progress and completed functionalities in documentation has a long-term impact on future collaboration and improves the product in a more predictable and effective way.
Leave a comment