I would like to point out a possible problem with the generic advice "read books" "follow blogs etc."
=> technological bias
As you are from Node/Express and Mongodb background the biggest risk is trying to become only better in these technologies. So you will only know how to make faster horses, how to train them for the best, but you will never learn car exists.
More than best practices, what makes a great developer valuable (especially in a position like you where other people in your company are less experienced than you) is your ability to see wider not deeper.
Try to challenge the status quo ? Why MongoDB? What kind of alternative do you have ? Same for Node + Express.
Doing so will force you to see where your tool shine and where it reach its limit. Doing so will permit you to know when you need to dig deeper on "how to use better this tool", and when to step back and "wait a minute, no amount of best-practices/knowledge will balance the fact that MongoDB is just no the right tool here"
So read a lot, but also from people that are not from your community (and to be honest HN is a good starter on getting different point of view)
The other important things is about perspective, it's not because a googler/guy from netflix wrote about how they needed to split the code in microservices, or needed to implement $design-pattern-with-a-very-cool-name that it does apply to you.
Especially looking to the size of your dev team, I think the worst things that could happen to you in your journey of trying to be a "better developer" is to try to be use too complex tools and too complex developments techniques
Being able to stop your fellow developers from writing too smart code will be even more valuable for the companies you will work for. And at the end of the day, that what will define if you are a good software developer for your boss.
"As you are from Node/Express and Mongodb background the biggest risk is trying to become only better in these technologies. So you will only know how to make faster horses, how to train them for the best, but you will never learn car exists.
More than best practices, what makes a great developer valuable (especially in a position like you where other people in your company are less experienced than you) is your ability to see wider not deeper."
Yes, you need to balance the need to be proficient with the stack that you have now with the big level-ups that come from learning something quite different. The best way to grow as a developer really is to learn a different programming language, and the thinking that goes with it.
I've never written a line of production code in Clojure, but learning Clojure taught me lessons about immutability and functional thinking that changed the way that that I wrote everything afterwards.
=> technological bias
As you are from Node/Express and Mongodb background the biggest risk is trying to become only better in these technologies. So you will only know how to make faster horses, how to train them for the best, but you will never learn car exists.
More than best practices, what makes a great developer valuable (especially in a position like you where other people in your company are less experienced than you) is your ability to see wider not deeper.
Try to challenge the status quo ? Why MongoDB? What kind of alternative do you have ? Same for Node + Express.
Doing so will force you to see where your tool shine and where it reach its limit. Doing so will permit you to know when you need to dig deeper on "how to use better this tool", and when to step back and "wait a minute, no amount of best-practices/knowledge will balance the fact that MongoDB is just no the right tool here"
So read a lot, but also from people that are not from your community (and to be honest HN is a good starter on getting different point of view)
The other important things is about perspective, it's not because a googler/guy from netflix wrote about how they needed to split the code in microservices, or needed to implement $design-pattern-with-a-very-cool-name that it does apply to you.
Especially looking to the size of your dev team, I think the worst things that could happen to you in your journey of trying to be a "better developer" is to try to be use too complex tools and too complex developments techniques
these articles explains better what I mean:
https://programmingisterrible.com/post/139222674273/write-co... https://medium.com/@rdsubhas/10-modern-software-engineering-...
Being able to stop your fellow developers from writing too smart code will be even more valuable for the companies you will work for. And at the end of the day, that what will define if you are a good software developer for your boss.