Solved problems and not re-inventing the wheel

It is a common tendency among inexperienced developers to approach a problem with code first. You’re given a task, and your first thought is, “how would I write the code to solve this?” It’s a totally understandable approach. After all, you’re a software dev – writing code to solve problems is literally what you do.

Unfortunately, most of those efforts are a waste of time. As a junior developer, the problems you will be assigned (or take on yourself, unless you’re seriously over-reaching) will almost always have been solved by someone else already. Those solutions will be better thought out, based on considerably more experience, and have been battle tested in the wild. They’ll handle edge cases and unusual circumstances you haven’t even thought of.

Far better, when faced with a problem, to search the interwebs for the solutions other people have come up with. In our modern era of open-source software, there should be a lot of possible solutions. Your problem shouldn’t be so much finding a solution as choosing a solution from the sea of possibilities.

This will force you to research and better understand your problem. If you’re to choose a good solution, you’ll need to understand what those solutions are actually solving, and whether they’ll actually solve your problem. After all, solutions don’t always do what they say on the readme.

But wait – surely by not actually writing code, you won’t learn how to write code, will you? Well, no. You’ll still be writing code – you’ll need to incorporate all the various libraries and solutions into your system, and wire them all together. There’ll still be a lot of code to write.

In addition to that, you’ll be working with real world examples of (hopefully) good code, which will show you good patterns, rather than you trying to work them out for yourself. We developers, in our arrogance, like to think that we could solve any problem ourselves, without the help of anyone, and we demand the chance to try that first.

But the truth is that really good code is built on the shoulders of giants, so to speak. Anyone who can write code to solve a problem first time, can do so because they have many years of experience solving smaller problems, using techniques and patterns they learnt from others. 95% of a new solution is not new, but the application of patterns learned from previous solutions, most of which this developer did not write.

So the evolution of a great developer seems to be this:

First: our developer tries to do everything themselves. They know few patterns already, and do no research, so they don’t know about solutions that already exist. Most experienced developers will look back at this stage in their development and cringe. I know I do.

Second: our developer learns about the outside world, and all the solutions that already exist. They incorporate like mad, and use existing libraries for everything. At this stage they’re learning what is available, and a little bit about solution architecture, but they don’t often analyse the packages they import.

Third: our developer starts to encounter the limits of the common solutions. The tasks they tackle become more detailed, and they are forced to analyse their solutions in more detail. At this stage they begin to learn how their imported packages actually work, and they find issues and short coming. It is at this stage our now-more-experienced developer will consider becoming an open-source contributor.

Fourth: our developer has a deep understanding of the problems in her field, and the existing solutions. She can take a big-picture view of the issue, and can see where the existing solutions fall short of perfection. Our developer is experienced enough, and knowledgeable enough, to create the new and innovative solution to the problem that she dreamed about in stage one.

So, my advice for new developers: the problem you’re facing has almost certainly been solved before. You do not, at this stage, have the experience or understanding of the problem necessary to produce a radically innovative new solution. I promise. It will come with time. It will come faster, in fact, if you first research what solutions already exist, and use them.

React was not built in a day.