I can't really give you a concise list of "resources and best practices" because there are sooooo many of them. Seriously. The internet is overflowing with great resources. (Yeah... I know, there are also a lot of not-so-great resources out there, but I can't possibly catalog all of them for you into great-or-not-so-great.)
But I can definitely give you one "best practice" that I sincerely hope you take to heart:
One of the themes that I try to highlight (over and over again) in my blogs is: never be a "fanboy" - of anything. In other words, don't ever latch onto a given technology and decide that it's your "favorite". And don't ever decide that you "hate" a given technology. Every technology is a tool in your tool belt. Craftsmen don't believe that the hammer is "good" or that the screwdriver is "bad". They understand that there's a time to use a hammer. And a time to use a screwdriver.
How does this apply to programming??
Well... let's look at Redux, for example. If you read enough of my articles, you'll soon realize that I pretty much "hate" Redux. Even in those areas where I feel Redux has benefits - I also believe it brings problems with it that negate those supposed benefits.
But you know what??? Those are my opinions. And you know what my opinions are worth?? Exactly what you paid for them!
You see... Redux is a tool. It may not be a tool that I prefer to use, but it's still a tool. And there are still some times when Redux might actually be the right tool for the job.
So... LEARN REDUX! And... learn other state management tools. And... learn how to build modern React apps without any state management tools. And... learn how to build apps without React at all!!
IMHO, the goal should be this:
Five years from now, when I've hired you onto my team, and we need to make a critical tech-stack decision, I'll want to hear your opinion. But I won't want to to know that you're making a recommendation based on some dogma that you learned 5 years ago in bootcamp. I'll want to know that you're making a balanced, reasoned recommendation based upon your own experience and based upon your own, honest assessment of the options in front of us.
If you can give a balanced, meaningful assessment of the tech options we're facing, then... you've "won". And you're an extremely valuable developer.
Too many devs, who've been doing this shit for years, can't say the same thing.
I'm a Front-End Software engineer who will be responsible for the complete lifecycle of scalable, secure, and well-designed software products from research and design to implementation.
I can't really give you a concise list of "resources and best practices" because there are sooooo many of them. Seriously. The internet is overflowing with great resources. (Yeah... I know, there are also a lot of not-so-great resources out there, but I can't possibly catalog all of them for you into great-or-not-so-great.)
But I can definitely give you one "best practice" that I sincerely hope you take to heart:
One of the themes that I try to highlight (over and over again) in my blogs is: never be a "fanboy" - of anything. In other words, don't ever latch onto a given technology and decide that it's your "favorite". And don't ever decide that you "hate" a given technology. Every technology is a tool in your tool belt. Craftsmen don't believe that the hammer is "good" or that the screwdriver is "bad". They understand that there's a time to use a hammer. And a time to use a screwdriver.
How does this apply to programming??
Well... let's look at Redux, for example. If you read enough of my articles, you'll soon realize that I pretty much "hate" Redux. Even in those areas where I feel Redux has benefits - I also believe it brings problems with it that negate those supposed benefits.
But you know what??? Those are my opinions. And you know what my opinions are worth?? Exactly what you paid for them!
You see... Redux is a tool. It may not be a tool that I prefer to use, but it's still a tool. And there are still some times when Redux might actually be the right tool for the job.
So... LEARN REDUX! And... learn other state management tools. And... learn how to build modern React apps without any state management tools. And... learn how to build apps without React at all!!
IMHO, the goal should be this:
Five years from now, when I've hired you onto my team, and we need to make a critical tech-stack decision, I'll want to hear your opinion. But I won't want to to know that you're making a recommendation based on some dogma that you learned 5 years ago in bootcamp. I'll want to know that you're making a balanced, reasoned recommendation based upon your own experience and based upon your own, honest assessment of the options in front of us.
If you can give a balanced, meaningful assessment of the tech options we're facing, then... you've "won". And you're an extremely valuable developer.
Too many devs, who've been doing this shit for years, can't say the same thing.
Roger that! Thanks a lot.