As a developer, I have suffered from the “software engineer syndrome”. After taking a quick tour on dev twitter or stack overflow, etc, it’s such a relief to see that I am not the only one.

What is the software engineer syndrome? It is a very serious yet really first world problem that developers have about making small decisions. You have probably seen people complaining about stuff like “why do we need semicolons”, “use tabs instead of spaces” to name a few but the list goes on (I got you there for a second 😂).

The problem

Something quite common in a few teams I have worked with is that we (developers) spend way too much time arguing about the small things that are not necessarily making us more productive nor are solving any real business problems. Isn’t it more productive if we take advantage of tools that solve such problems for us? For example prettier amongst tons of others, it solves the tab vs spaces problem. That way, we don’t end up having the same conversation over and over again in Pull Requests reviews.

Another example of such a problem is when creating new files like React components, util functions and other pieces of code that we deal with on a daily basis. Questions may arise like where will this new code live within our project structure? What naming convention shall we use? How will we separate the concerns? Will we include tests?

All these are valid concerns for teams to have, but hopefully after a quick catch up with the rest of the group, a plan can be made. However, that plan needs to be documented so that it is available for everyone to use as a guide. It can also be really valuable when onboarding new developers. That way we keep being consistent and then really hope for the best.

It’s not so rare to see that we easily forget (or at least pretend to forget) that initial plan. Then the team changes, new minds with new standards come in and… you know… dev life happened. That results in the code structure taking the wrong direction. Then by looking at the code in our project, it looks like 20 different coding styles were applied and the question “which style shall I follow” soon arises. What comes next is that developers take it personally, start complaining that we need to refactor stuff and arrange a plan to get rid of that infamous technical debt we created. This not only takes a lot of time, but it is possible to bring new bugs to the surface because this massive re-styling is going to touch many many files. So what is the solution here?

Let’s aim at the point when we create the code in the first place. How about we let the tools do all the annoying / hard work for us? That will also save us time! You may be thinking “it only takes 2 minutes to create a new folder and add a couple of files in it, why bother?”. However, considering how many times we do that per day or week, at the end of the month it may save a lot more time than we think. Ok I think it’s time to finally get to the point. 😅

The solution with code-gen-library

To solve this problem, I created a small CLI tool that takes all of these considerations away from our heads. If you want check it out, it is a lightweight npm library called code-gen-library. (Yep the name is not the most creative one 🤣)

How does it work? We simply install it as dev dependency and run it as a script. Yes that simple. Here’s a quick preview of how it works.