Exponents
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.
If you wanna save some time, watch this older talk “JavaScript Masterclass”, by Angelina Fabbro from JSConf US 2013. I watch it pretty regularly and still learn a lot from it, every one of her points is still relevant 5 years later. Below are things I’ve been trying to do, most of those come from that talk.
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
JavaScript is my first programming language. I worked in PHP for a little bit, but primarily just JavaScript. But I get tunnel visioned since I know how to get things done without having to think too much about it. Spending time in another language, where that cursory knowledge doesn’t exist, forces you to rethink why you’re making the choices you’re making. Vacation in another language; ReasonML and Elixir are pretty damn cool and so is Python or C#.
Coming back to the work you do every day, knowing why the pipe operator exists in Elixir or why C# has namespaces or how immutability works in Python, has made me appreciate JavaScript more and want to see the overarching design patterns in programming.
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.
Static analysis is often a great stop gap to testing and arguably can give you more immediate and relevant value than unit testing alone. I had to learn TypeScript when I started my current contract. The process of learning how to use TypeScript made me rethink how I want to write JavaScript to make sure my code is easier to read, share and annotate.
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.
To be honest, I don’t understand this concept really well. My main take away was that arrays and for loops were not a great answer for everything. Sometimes Maps and Sets in JavaScript were better answers and led me to spend time reading and finding ways to implement them. But the awareness of other options makes a huge difference, in that you’re less isolated with the wrong primitives.
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.
https://medium.com/cesars-tech-insights/big-o-notation-javascript-25c79f50b19b
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.