Your Job Is Not to Create Software, It Is to THINK!

I've got 20+ years of professional experience, and every single place I have worked, I have seen the same anti pattern recurring over and over again. And the "pattern" is as follows; Every single problem has dozens of solutions to choose from. Of course, nobody has the muscles to maintain these solutions, so all solutions ends up becoming sub-optimal, and arguably creates more problems than they fix. It doesn't matter who you work for, the pattern can be found everywhere; Microsoft, IBM, Google and "John Doe Software Consulting". This is such a big problem it's got its own "slogan", which is as follows.

Not invented here syndrom

If you're a noob software developer it's easy to (falsely) believe that your job is to create code. Newsflash; Your job is not to create code, it is to think! Your manager might give you a task for instance, which is to implement support in your latest enterprise application for translations. Wanting to do a great job, might result in that you start creating a module for solving this problem - Of course your manager, often being a non-technical person, might be happy about this approach, thinking to himself "awesome, a module is something we can reuse for later projects."

The problem with the above approach, is that translating stuff is a problem millions of software developers have faced before, and hence you're destined to find thousands of Open Source things out there, helping you with this problem. In fact, I have created at least a couple of solutions down this alley myself.

Do as I say, not as I do ;)

Even if your problem is not a commodity problem, somewhere deep within your employer's git repositories, you will often find that somebody else working there previously solved the same problem years ago. However, if you start out creating code to solve the problem, your employer ends up having two sub-optimal implementations to maintain - Simply since once you've solved the problem for your manager, you're not given the time to maintain your solution, refine it, and modularise it, such that your employer can reuse it for later projects. Such things always ends up on the "back burner."

If you instead had started out looking for Open Source components solving the same problem, and/or asked senior colleagues if similar components had been developed in-house previously, you'd save a lot of time, that you could instead have used on improving the existing systems, making the existing parts function for your specific problem at hand - Resulting in that either the Open Source component you chose, or the in-house development component you chose, ends up becoming better, more generalised, and capable of solving even more problems in the future. This of course, in the long run, has the additional benefit of reducing the cognitive load for your employer, allowing your employer to focus on his primary business model, making more money in the long run.

Downloading a zip file from the internet, or cloning an existing in-house git repository, might not be as "sexy" as starting out with an empty project - But in the long run, it makes you a more valuable employee, and a better software developer - Simply because of the following ...

YOUR JOB IS NOT TO CODE, IT IS TO THINK!

Now please do your job ... ;)