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.

Not saying they’re assholes, but self-centered maybe.

That is a good question.

I suspect the answer can be found by looking at the Linux ecosystem.

20,000 opinions and 200 of them are willing to build their own distribution.

Don’t get me wrong, I love Unix and Linux, but there’s a metric ton of toxic personalities involved.

I’m sure a lot of it can be attributed to people having to be somewhere on the spectrum to even spend time contributing to free software on their own spare time, but a lot of people who build their own stuff tend to get quite attached to it as well.

Maybe all this friction actually is a good thing and it causes progress, but on the other hand I can’t help to think about where we could have been if everyone was pulling in the same direction.

On the same line 😈

I’m a naughty programmer. What are the signs of that?

Step one: Create random package that does something trivial that’s done often.

Step two: Start making PR’s to lots of open source projects replacing a number of lines of code with your new package.

Step three: Work hard to get your package into another package that’s used by many.

Step four: Update your CV to reflect that you build software that thousands of companies depend upon.

Step five: Profit from the stupid incentives created by companies hiring people that pad their CV’s by making redundant software and push them into everything they can to make sure everyday is dependency hell.

I’m always wary when someone talks loudly about architecture.

I’m not saying it’s not important, by all means, but in my 10 years as a professional developer I’ve found that the people who are most devoted to preaching architecture don’t contribute to good architecture.

I’ve only met a few persons that fit that bill, so obviously nothing statistical, but the experience has left me wary when people start to become loud about it.

I’m not saying this is you, but if everyone is pushing back it might just be that you are part of the problem, not the solution.

Architecture can be many things.

However, there are individuals who believe that the only way is that one way they read about in a book once, or even worse, they’ve read it multiple times and it’s their Bible. Maybe they’ve read multiple books by the same author and has basically adopted someone else’s viewpoints without any critical thinking.

Exposing yourself to different architectural strategies, viewpoints on architecture from multiple people.

And remember that all architecture serves a point. It is the job of the architect, and the team, to build an architecture that solves the needs of the project.

“Clean code”, whatever that is interpreted as, is probably not one of them.

“Good test-ability”, modularity, multi-platform, performance, package-size, internationalization, accessibility, etc. might on the other hand be needs and goals that can be used to guide the project architecture.

Uncle Bob’s layer cake probably isn’t.

If you want better takes than mine on criticisms of Uncle Bob’s Clean Code I suggest to Google it. It might cause you to re-think some things as well.