The new year is finally among us, and I think many can agree, that it took a while to get here. With this new start though, there is new opportunity in the air to pick up that new framework, language and/or technology that you have been reading so much about and to become that elite developer that you always knew you would be.
But there's alot more to learn in order to better grow your overall skills than just a language and a framework. A new language is great, for sure, and playing around with a brand new framework can feel like you're on the cutting edge of development. But it might not necessarily carve the very best version of your programming self.
As I said, there's alot more. Being a programmer (particularly a full-stack one) means coding, yes. But it also means working with and managing databases, configuring security settings on a server, learning how to optimize the delivery of resources and performing other web-related tasks.
So this year, do yourself a favor, and put down that new React textbook that you picked up for the holidays (at least for a little while), and put some focus on these other elements that will inevitably make you into a much better and overall well-rounded web developer.
Source control
Source control is one of those things that offers little benefit when you're coding alone in your coding den, aside from offering a secure backup location in case anything goes awry on your local machine.
The real benefit of source control however lies with the collaboration features that allow you and multiple people to work on the very same codebase without causing mass conflict and confusion. At least, to reduce the likelihood, because you can't truly get rid of those issues.
And the bigger the team, the more complicated things can get.
Aside from the standard clone, push and pull commands that every developer gets acquainted with early on in their careers, programmers should also be familiar with the various keywords used to create, manage and merge branches, rollback commits and perform hard resets if need be.
They also need to understand what the various response messages that often times seem cryptic mean in the context of the application. While Google can help you out (usually), it doesn't yet know what you are working on and so can only show you potentially viable solutions.
Most of those scenarios aren't really applicable unless you are working on a team however, so much of the practice will inevitably come from the job itself.
Architecture
Architecture is a loaded term and it encompasses more than this paragraph that I am about to write. Alot more. It involves everything from the file and directory structure to the way that you absorb API's into your client.
And it's not easy, because as you may have guessed, there is no one single way to go about doing it. And the correct way of doing it isn't always the most clear and obvious.
But it pretty much affects how you write every single line of code in your system. If you have all of API's on a back-end server separate from your client, then you'll have to worry about maintaining some form of middleware that facilitates that communication. You also have to maintain multiple servers as well.
If you have an application that is split into a service, controller and model structure, then you will have to figure out how to best write code to fit that mold.
So in a sense, architecture is everything that you do, but with more mindfulness and awareness as to how it is being done.
Security best practices
Security often gets placed on the backburners in place of funner and flashier code. Why worry about validation and formatting, when you have that fancy new npm library to play around with? At least, that's how we all mainly feel.
I personally don't enjoy writing any sort of validation logic, mainly because its usually tedious to write and very repetitive. But I do it because it is necessary for any application that is going to live on a public server.
And there's alot to do in this regard. There are simple things such as encoding and decoding any type of user input. This varies based on on the framework and language that you are using. Some frameworks handle this for you by default for example.
You also have to audit your applications for potential XSS vulnerabilities and then patch up those holes as you find them. Because if you miss any such vulnerability, at some point somebody else will find it for you.
If you are working with a database engine of any kind you also have to guard against SQL Injection attacks of any kind as well. You'll need to know ways of mitigation such threats on that particular database engine.
As I said earlier, there is alot to do. Some of these things involve code, yes, but often times security best practices comes down to how you are configuring your servers and what you are doing to monitor your code.
Deployment strategies
In the days of old, you could easily get away with firing up an FTP editor and dragging a zip folder over in order to deploy your weekly coding updates. And if things went wrong, then you would unzip the backup folder that you had at the ready.
It was crude, but it worked for the most part. And truthfully, there are probably still some organizations that operate in the same way.
But things are different now though. They're complicated. Code isn't just compiled or transpiled or interpreted and ready to be shipped to a single server.
Companies have adopted new complex workflows designed to scale up and reduce the possibility of any downtime. And that complexity means that new deployment strategies need to be implemented.
For example, continuous deployment has become a popular deployment strategy that relies on software automatically building and deploying your code in real time.
And that means learning how your particular hosting service handles such workflows.
Alot of this supplemental knowledge that you will inevitably need to learn, really comes down to learning how various new tools function with your code and in keeping up with the latest best practices, methodologies and constantly evolving workflows.