NewSwag: The Project I Will Not Finish.
by AOGPoston on 12/11/23

Why publish this article?

Create, and destroy. Like a child in a sandbox surrounded by bullies, I build something that I love. Then like the bullies, I destroy it. Over and over again I have subjected myself to this cycle when it comes to software. If its not destruction, its hording. I have right now in my github about 30 repos of projects which were going to be unicorn worthy technologies. All of them, fell prey to my cycle of hording and not finishing.

Maybe you are similar.

In my life right now narrative has been pulling me out of terrible behaviors. Sabotaging behaviors. And I wonder if narrative could help in this area of my life as well. There also may be value created (take a shot) by parsing out my rational. If for no other reason than to see how to NOT think about your next big idea.

What was the project? The project is a node script (npm package) which helps

developer change their code styling. The tool would, if it were completed and working, ask the user which code style or ESLint rule they would like to correct. An exmaple of this would be changing camel case to kebab case. An example of the ESLint correction, the tool would correct the "one var" rule by concatinating all variable similar instantiatons (i.e. var with var, let with let, etc... )

Why did I create the project The idea for the project came from an anxious

desire to complete an ElectronJS rerwite as fast as possible. I built an app for a client a year ago which used Vue3 and ElectronJS. At the time I decided to use a boilerplat which had SQLite and some other tools already integrated. When coming back to this several months after completing the application, I discovered the hot-reloading for ElectronJS was broken. Without hot reloading, the project becomes a hassel to fix and debug. So, I decided to just do a re-write of the whole app. I thought it would take a few hours tops since I would only need to re-do the outer shell, if you will, of the project and could keep the bulk of the code untouched. I found another boilerplat with similar things to what I need and started there then moved over files into the proper source directory just to see what errors would come up. And thats when I was hit with 3099 ESLint errors.

1000s of the errors were unfixable by eslint but were simple, seemingly, to create a script to fix them. This is when I got the idea to create my tool. The hope was, I could create value (take a shot) for myself by fixing the errors and also create value (take a shot) for others since this isnt my first time having this sort of issue, so I know theres hundreds of others who also have this issue. It would also be something nice to show off on github.

What is the value prop? The value prop specifically is having the ability to

speed up re-writes, refactors, and linting errors fixes which are not fixed by eslint. The latter, I think is more of an emotional relief than anything. So, really the value would be time. Take less time to do a refactor. That sort of thing.

Why stop the project? Im stopping the project because its not that valueable

in and of itself to make chaning the style of code easier or faster. While it may be somewhat common of an experience to have a bunch of linting errors, up until this point the fix has been either to fix the errors, which isnt that crazy of a task and its is rewarding to go through your code with a fine tooth comb, or to simply ignore or disable toe rule as you clearly have a desire to use a different codestyle. The amount of people who would have this issue on an entreprise level where its mission critical to change the camelcase variables to kebob case, for example, is likely very low. Not zero, but very low. Perhaps not high enough to warrent a publically available tool, since in those scenarios the SR devs would likely just write a tool themselves.

That brings up the second point, accuracy. This tool would be difficult to create with a high accuracy rate since theres so many edge cases which could turn a codebase into a nightmare if left uncaught.And at this point of my career, Im focused on creating value (take a shot) but not at the cost of quality. Gone are the days of creating fun toys for people to give me internet upvotes for being smart. Im trying to give people genuine solutions to problems while creating minimal problems. And a broad strokes, ad-hoc, code style changer would likely create many errors for its users.

So Im stopping development on this tool.

Why would I continue the project? Probably not. To be real, the more I think

about it, the more I come to the conclusion that this problem just isnt that big of a problem. If this was happening at a company and they reached out looking for a solution, perhaps then I would revisit the issue. But, until that happens Im affectively solving a problem only I have which is spawned out of my own poor decisions to use boilerplate projects instead of building from scratch.

Amon