I feel like I've been falling into front-end engineering roles for years. I'm mostly self-taught (and that story is detailed more here). Some concept or problem never quite clicked right, something I don't know how to describe well or even understand. I shrug it off, I get back to the job at hand, fervently googling, finding a good fix and moving on. Lately, I'm noticing I want to grow more deliberately versus as just a byproduct of my experience.
Don't get me wrong: practical experience is good. Top shelf; would recommend.
But I don't feel like I grew as an engineer as exponentially as I wanted to and I didn't know what to do other than getting a CS degree (which I didn't feel like investing time or money in). Or more succinctly, I plateaued on experience. So I started working with different senior engineers and seeking advice and cobbling together something of a curriculum.
This post is basically 5 quick behavior changes and shifts in thinking that have helped me grow more as an engineer in the last summer.
1. Read the Source Code
Read the source code of the projects you use. I use React almost everyday, Next.js just as much. I spend time browsing these repositories a lot. I don't understand all the code I read; that's okay. Occasionally I learn something.
This process takes about 20 minutes, a few times a week of the projects you use. With Next.js I found settings that weren't well documented, I understood more about the way data-fetching works in that framework and more importantly made sense of work I was currently doing.
I feel like you'd get more diminishing returns on projects you don't use or care about. Like if I read Angular's source code, I wouldn't necessarily get any value from it, because I have never used it.
2. Spend Time in Another Language
3. Test — Let the Errors Guide You
This one feels like common sense. This is more of a shift in perspective. Errors used to piss me off, so, so much. I watched a preview for Ben Orenstein's Refactoring Rails course and one guiding principle was:
Write the code you wish you had. Let the errors guide you.
First, this makes me want to write more unit tests that are unit tests and not pinning tests; meaning that tests cover the objective versus the hyper specific implementation you have. Then, it gives me a different way to look at errors, instead of angry demands from a cold indifferent universe but as guide-posts towards code I want to have in my project.
4. Learn Big O Notation
Big O is the runtime of an algorithm. It measures how long a piece of code will take to run, the input and how much memory they use. There are different types of algorithms: Constant, Linear, Quadratic, Logarithmic, Factorial. The more iteration, the longer your code needs to run.
If you want to read something about Data Structures and Big O read Itsy Bitsy Data Structures, by Jamie Kyle. It makes these difficult concepts easier to understand.
5. Try Vim
This is more of a bonus. Lately, I'm using a Vim mode inside VSCode because my team really loves the workflow with shared settings; I really miss terminal Vim.
But working in Vim makes you think about how you navigate around a file and how inefficiently you move. Vim uses an idea called "modal editing" which means you update text by switching in and out of modes. Normal Mode doesn't allow you to type, where Insert mode actually allows you to add code to your file. The common wisdom is that you don't live in Insert mode but you should normally be in Normal mode and this switch just causes me to be more deliberate about what I write. It's just a mental switch.
That's all I got so far. Small behavior changes and shifts in thinking. As always: YMMV.