# On Building Your Own Libraries I've been working as a developer for a while now. I started working while writing my bachelor's thesis, and I've noticed a clear shift in my way of thinking since those days. $\quad$Between 2017 and 2020, I was strictly writing C++ code, building everything from scratch and putting a lot of effort in the act of writing code. At university we never used open source solutions, that would be considered cheating, rather we had to implement everything. If you needed a `.obj` deserializer, write it yourself $\quad$This time felt really adventurous and exciting. While it is not the most *"productive"* thing in the world one comes to learn that things are never as simple as Python makes it out to seem. I would argue that putting in the effort to write everything myself helped shape me into the programmer that I am today. ## An over-reliance on dependencies > [!note] > Before I continue, I need to make it clear that this **isn't always the case** and **your milage may vary**. Some companies rely far too much on external sources, and some implement everything in-house. I cannot begin to count the number of times where I have been present at a planning meeting, and a new API needs to be implemented in order to deliver a feature and the suggestion is to include another dependency to handle 90% of the work. $\quad$Using a dependency is not bad. Nor is using two. The ability and luxury of not having to implement your own solution is mighty powerful, and as uncle Ben teaches us, *with great power comes great responsibility*. After having worked at companies of varying sizes and hearing some nightmare scenarios from other companies, I do not think that we use our power with responsibility. In fact, I believe that there is an over-reliance on external libraries. $\quad$How many man-hours are spent simply incrementing versions and resolving major version changes? How much of your time is spent reading through documentation trying to understand if you can set custom headers when sending requests through ExDep.v14.4(Example Dep)? $\quad$What is worse is that after some years of working this way, you yourself adopt this mentality, and when you are working on a personal project you will find yourself adding a ridiculous number of dependencies, just because you lack the courage to accept that you have forgotten what you once knew(speaking from personal experience)... ## What can I do about this? If the mentality at your workplace is to actually use a lot of dependencies and to have a *"feature first, code second"* moto, then I do not think that there is too much that you can do, at least not during office hours. $\quad$Having a hobby project is probably the best way to get into creating your own solutions, for whatever it may be. If the project needs to be able to load json, then write your own json-serializer. Know that the project that you are working on is strictly for yourself, and that no harm will come from writing silly code. In fact, you just might find that is really what you need to do to level up. $\quad$Write silly code that makes no sense, and then be proud of it. Too often we get caught up in trying to be productive, forgetting that in order to be good programmers we have to firstly write code and secondly understand it. ## Conclusion > [!conclusion] > If possible at your workplace, do not suggest solving the problem by throwing someone else's solution at it. Argue that it would be better to write your own solution. If not, then working on a hobby project and implementing all of the pieces yourself will help you build up your confidence in coding. / SC