Being a self taught developer, a lot of times the path you follow is arbitrary
and there's a very rare chance that 2 developers follow the same learning train.
One might start Frontend development, stick to it and excel only at that, one
might be a curious one and jump from language to language and try to learn
everything he/she possibly can.
Neither one is a bad developer.
I wished I had a mentor, might have changed the way I look at code altogether
and maybe even be a better coder but then I was always the guy who could teach
himself instead of the one who'd learn better from teachers.
Now, backstory aside, here's a list of things I wished I did sooner.
Ironic coming from the person who changes his tech stack every 2 weeks but have
a goto tech stack that you can depend on when confused on what to choose.
This helps you when you just want to test the waters and create a prototype or
something where you wouldn't want to invest a lot of time setting up
architecture but getting the base functionalities up and running to test. I've
previously made the mistake of trying to setup the perfect architecture and
failing to ever start the project because of that mind block.
These are stacks that I've personally worked with.
Obviously you could add redis, ES , etc etc for additional requirements but I'll
leave this to be the base you start with.
The one I use has an experimental server layer so I wouldn't recommend people
use it right now but here goes,
While I know Next.js can be used for the server part as well, I choose not too,
I like keeping the UI and Server far away from each other , I did build a full
monolith using Next.js but I figured that both, the amount of control and
deployment time can be improved if I split them.
Now this is one step people avoid because everything is available on
StackOverflow and various other blog posts and one of the reason I think there's
a slow down in learning but that's a rant I can pick up later.
Have a place where you maintain code snippets , libraries , everything that you
find useful. You can even store stack overflow answers if you'd like.
The point of having a resource collection is avoid fumbling around the web when
you've solved a problem before already. I've written time formatters multiple
times now, while not proud of it I still end up writing most of my logic again
and again when I could've just picked it up from a previous codebase but then
looking through 100 repositories for it is a bad idea and I could write the
formatter again till then.
If you've not seen it yet, reaper.im has a collections
section where I now store snippets I use a lot or type again and again.
You don't have to do this to your website but use something like Github Gist to
store these snippets and something like Pocket to store blog and website links.
While it's mostly a luxury and shouldn't be done for prototype projects. It is
still mandatory for you to learn how to write tests and learn at-least one test
engine / test suite. It can be a full batteries included test suite or it can be
a combination of test runner and a test functions library.
As, when the codebase moves forward from the prototype phase, it's necessary
that you spend minimum time trying to figure out what has broken from an already
working flow. Addition of new flows/functionalities will take longer since you
have to now write tests for these but you gotta do them just once and that one
time should be done properly.
It's ironic that I'm giving this suggestion when none of my repos actually have
test cases but that's because none of them have moved out of the prototype stage
to begin with and the one which is into beta is
TillWhen and it has test cases to make sure
the base functionality works at all times.
Last but not the least and probably the most important one of the bunch, keep
digging through what your code editor has to offer. If you're using VSCode,
learn to use it's task runners, learn to use it's in-built debugger, add
visualiser plugins to test performance of code, etc ,etc.
If you're using Vim, learn to create macros , get to know how to manipulate
larger chunks of text faster, again add plugins to speed up repetetive tasks.
Each famous code editor has a few tricks up its sleeves that can help you in
productivity and getting faster at coding. As a programmer the editor is your
home and something you spend your precious hours with.
Learn It, Practice It, MASTER IT!
Read through the release notes, check if a release has added something useful,
try it out , check if it's easy to use when working on code to use this
functionality. I use eslint's tasks in VsCode almost instantly at this point.
Command + P , Run Task, Lint whole folder, my fingers do it in seconds and I
don't have to wait for VS Code's internal plugin runners to do the linting and
lint fixes as that slows down the editor on my low power hardware.
Yeah, I code on multiple hardware at once. Shocker!
Similarly, I've gotten so used to Vim's macro creator that I consider that to be
the first thing that I think off when looking for repetetive tasks on the text.