I began exploring computers in 1993 and landed my first job as a developer in mid-1997. My initial role involved reimplementing industrial control systems written in Clipper, which ran on DOS, and migrating them to Windows — a novelty at the time — using Delphi. The internet existed, but it was more of a curiosity, with access being expensive, slow, and complicated.
Back then, finding information about tools and technologies was far more challenging than it is today. The primary — and often the only — resources were books. I bought the most relevant ones on Clipper and Delphi that I could find. Occasionally, you might know someone working on similar projects who was willing to share ideas and code. Otherwise, you were on your own.
The Rise of the Selfish Developer
As a byproduct of those times, each developer tended to develop their own coding style. In practice, many struggled to use code that wasn’t written in “their way”. Some, driven by more self-serving motives, deliberately made their code difficult to understand, aiming to make themselves “irreplaceable” and, in doing so, secure their jobs.
As the internet evolved and became more accessible, developers gained access to specialized forums populated by people from all over the world, sharing code snippets that could quickly solve immediate problems. I remember many developers being hesitant to use these snippets, simply because they couldn’t comprehend code written by someone else. The thought of supporting or maintaining that “alien” code was even more daunting.
Other People’s (Better) Code
Eventually, the open-source movement gained traction, bringing libraries and frameworks into the mainstream. These tools often came with high-quality code, crafted by the collective intelligence of developers who typically adhered to best practices. It was no longer necessary to reinvent wheels; instead, developers had to step off their pedestal and embrace what others had built.
Adopting a well-established framework is, above all, an exercise in humility. It forces the recognition that some people are more skilled or knowledgeable than you are. A framework offers a trade-off: it provides you with tested, ready-to-use tools, but in return, it demands that you follow its imposed workflow. You won’t be able to do things “your way” as easily anymore. Anyone who has worked with Angular, for example, understands this well. The result is that you no longer write code just for yourself, but for others who will maintain it after you.
That said, not everything is a framework. There are still tools that allow for more freedom and can be gradually integrated into projects as needed. These are libraries, such as React regards itself. They suggest workflows, but leave you the choice to follow one out them — or none at all.
No Silver Bullet
As expected, the use of frameworks and libraries requires careful consideration, taking into account the goals and specific needs of the project. Depending on the experience and expertise of the team, a new framework or library might even emerge. However, it’s risky for an individual to take on such a large task alone.
The truth is, the era of the “selfish developer” is over. Given the current complexity of applications, it’s nearly impossible to build anything substantial without the aid of frameworks or libraries. The ability to work with code written by others is now a critical skill for any modern developer.
Happy coding!
Featured image credits: Freepik