We use TypeScript for our node.js backends.

We had two that started out vanilla, but it became too painful to maintain.

Writing code that can’t be scientifically proven to be correct on all hardware it might run on means you don’t care about code quality. /s

The Internet is full of people with a bloated ego trying to justify their opinion and gatekeeping others.

I see this more and more in software as well.

Not sure if it’s always been like this, or if I just notice it more.

Same way there’s thousands of people giving you a guide to write a task list in , but as soon as you want to use anything slightly more complex than what you can learn from working a few hours with something you quickly run out of material and is usually left to fend for yourself.

We are all different, but what can be important is to make sure you keep exposing yourself to new ideas and concepts.

Ask to be allowed to go to a conference in which you can learn new things. There are frameworks and technologies out there you might not hear about outside of those places. Things that can potentially make an aspect of your job significantly easier and make the project easier to maintain. I learned about Factory Boy this way, and man does it help save time when building tests! https://factoryboy.readthedocs.io/en/stable/

Another aspect is if the scope grows - or the success of your project grows, so does the risk of being only two developers.

Make sure the business side understands this risk. If you or the other guy decides to leave they won’t find a good resource quickly and would need to rent a resource or go without for a while.

Also, make sure that you don’t let the fact that you like the job become a sleeping pillow for salary growth. The more responsibility you put on the more you should be paid.

I’ve been where you are, now I have six devs under me and a project lead. It’s been a though, but exciting journey.

The toughest part for us has been to push to transform the rest of the company into an organization that understands and cares about software development, and to take technical debt seriously.

In the beginning the business people were like “I like the funny words you say man”, they weren’t quite so entertained when we needed to spend a small year rewriting an app that got bit bad by technical debt. The interest payments were significant.

I see this a lot with a significant portion of my colleagues, maybe around 30%.

Personally I don’t feel like it’s a big issue for me, but on the other hand I’ve been working mostly in Python (snake_casing) for the last six years.

That said I do see people having issues with it even in Python, so it’s not like snake casing cures the issue.

Always lowercase gets a downvote from me though.