JS Baby Steps! Rome.js wasn’t built in one day either
(or: How not to burn out fast)
Well, maybe it was. After deciding on a title, I found out that there really is a rome.js repo but let’s not get sidetracked by petty details.
“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.” ~ Mark Twain
Who is this article aimed at? Well, I’d say all junior frontend developers just as well as intermediates and seniors that try to make some major changes in the way they work by venturing far beyond the borders of their regular comfort zone.
tl;dr: Don’t try to be perfect from day one. Don’t try to make all the right decisions when you don’t have the knowledge yet to understand them. Set realistic goals and don’t burn out!
A few years ago I had reached a point in my career where I couldn’t grow and expand without breaking some walls. In my case, those walls were the project scope of my former job. Even though I had really loved my team and enjoyed the overall work environment and culture, the limits we had due to our regular projects, tough deadlines and restrictive budgets kept me from experimenting with new tools and acquiring new skills. Working in any web agency is a tough environment full of challenges and restrictions.
Our regular tech stack was based on node/npm, grunt, sass & bootstrap, wrapped in vagrant and with a sprinkle of React here and there (modules, not full apps). As I’ve started my professional career in 2009 and have been learning the ropes of web development since 2003, I knew my way around my styles, barrier-free HTML, browser compatibility and the usual mobile first/progressive enhancement way to build things. I had left the days of jQuery behind and moved on to vanilla.js, prototypes and such but I always knew that there was so much more… So many interesting articles about React/Vue/Angular, functional programming, OLOO, Redux, WebPack, Post-CSS, Jest… I could go on and on.
On a related note, there was a great article about the modern frontend developer by Kamran Ahmed, just in case you are not yet overwhelmed by the choices.
I knew I had to change something and as soon as I was able to free my mind from other stuff (yeah, I’m looking at you, news feeds, smartphone and procrastination in general), I started to make room in my regular “not at work” schedule to learn new stuff and prepare myself for the new position I was planning to take on.
“Code for the job you want, not the one you have!” ~ me
I immediately set up my first react app with create-react-app, digested what I found there, adjusted some smaller details and plugged in Storybook right away because… duh, of course I wanted to have a living style guide for all of my new projects. With that demo working and after separating all parts of my Tic Tac Toe game screen into smaller parts (atomic design of course, and BEM CSS structure), I leaned back and let that sink in. Wow, that was quick… cool.
#1 Takeaway: If you use stuff like create-whatever-framework, that’s cool to kickstart a prototype but if you want to start using said framework for real, try to build it at manually at least once to understand HOW and WHY it works the way it does.
Riding on that new high, I started to lay out my next steps and browsed through 4 years worth of bookmarks about things I had always wanted to use and never found the time for. The basic plan was to start with WebPack[✔️], React[✔️], Storybook[✔️], then build a small set of reusable components[✔️], apply the usual best practices and then add all the cool things that improve code quality, allow for great scaling, automated tests, linting, ES6. While on the topic, why not include the manifest and service workers for a PWA and such, make use of caching, implement the PRPL pattern, use lazy loading, manage bundles, routing, move state handling to redux, use typescript’s static typing, jest for …
#2 Takeaway: Spend some time every now and then to curate your bookmarks, evernotes or whatever… things get out of hand to fast if you don’t find the time to actually try some of that stuff and coming back to that steaming pile of … bookmarks can be a bit discouraging.
About then my head exploded for the first time. I snapped my MacBook shut and went to stare into the fridge for a good 5 minutes while trying to sort my thoughts. A few coffees later I was able to reset myself and try again.
While there is so much knowledge out there, floating around the interwebs and yours for the taking, it is at the same time toxic for an open mind with too little practical experience. Most of the time you are searching for a tutorial to implement X, the author decided to couple it with Y at the same time because hey, that’s the best way to do it. Or the already existing tech stack and code from his repository are based on something you didn’t plan to use yourself. Or maybe, the tutorial is so outdated that most of the syntax changed due to some breaking changes with the latest major version and who would start learning a new tech on a deprecated old version and wilfully not use the latest and coolest features.
#3 Takeaway: Use a repository to manage your learning/hobby projects. Include meaningful commit messages and branch out if you are not sure if you are gonna implement it in the master after a quick trial.
Bonus: Use links to the tutorial you used to implement a feature in the commit descriptions.
Ok, I went back to the drawing board or in my case, git repository and reverted some of my latest changes to a point prior to the point where threw too many changes on the codebase and tried poking it till things work again (or don’t work at all anymore).
Back then, the stable version of Storybook wasn’t compatible with Webpack 4 so after some digging and tinkering, I went back to the very start of my project, made a branch called clean-slate and started over. By then I knew the basics and setting up a new project was even faster than before. I hardly had to check my notes now as I had done it quite a few times lately and it felt good to do it “hands-free”.
Next time I used Webpack 4 in combination with the “@storybook/react”: “4.0.0-alpha.20” and got it running. -> Push and next step. Added the storybook addons I deemed useful from my prior experience with pattern library tools and style guides. Added the storybook config with all the basics. -> Push and next step. Added the Webpack loaders for all content types I wanted to use right now and reimplemented a small demo page to check both Storybook for components, Webpack Dev Server for a page preview and a regular build to see if the result in my dist folder was usable on its own. -> Push and next step.
#4 Takeaway: Having a small set of basic components and a demo page ready to check for errors is mandatory. Every Push into my repo was preceded by me running “yarn start”, “yarn storybook” and “yarn build” to make sure I didn’t break anything.
#5 Takeaway: Don’t try to automate this right now unless you already know how to run automated tests to catch all possible problems but in that case… Why are you still reading this? Go and make some code… jk
At that point, I decided it was about time to raise the bar and the quality of my code. I was sure that I must have missed at least some best practices or made a few small mistakes. Things were running smoothly but the code was kind of messy with many bits copied from different websites. Time to introduce eslint and stylint to my project and adjust the .editorconfig.
BAM, 600 errors… damn, those guys at Airbnb sure are picky! Looking at the console output, I slightly adjusted the presets with my own rules and ran another test… down to 300 errors and 40 warnings.
Time to dig in.
After making some tough decisions with the help of the hive mind we know as the internet and stack overflow, I decided to use no semicolons, .jsx as a file extension and spaces instead of tabs. Renaming my .js files to .jsx, running a Search&Replace over my code for some repeating stuff and deleting my debugging console logs, I got the number down to about 20 errors and 5 warnings (SVGs are too long for the max_line_length) and at that point in my project I learned some new javascript for the first time: eslint made me rewrite some stuff that should be pure, deconstructed etc.
#6 Takeaway: Use eslint (and prettier) with some healthy adjustments, run it with --fix and check the changes in git to understand what was fixed automatically. Then proceed to change the more complex things, you can’t — fix automagically and try to understand why those things are in the presets. They actually make a lot of sense.
Conclusion
It took me about 3 weeks of my time, both on the job as well as at home (don’t do that… it’s unhealthy!) to get to a point where everything ran smooth and was well understood so I could make informed decisions on my status quo and my future steps. During that time, I nearly lost my mind a couple of times and must have gotten on my wife’s nerves quite a lot with my rambling and ranting and cursing but hey, I had made it.
The key for me was to make lots of small iterations, go back, redo it slightly differently. “Fail fast and fail often”, just as those tech giants teach us in their TED talks. It’s alluring to plan 3 steps ahead when starting a new learning exercise project because we all want to do it right but the point is, unless you are some lucky talented and gifted person, you won’t do everything right the first time and that ok. It’s just code. Roll it back, start again (unless it’s a real project but then again, WTF are you doing with highly experimental stuff in a live project)
Looking back at my first steps now, as I was recapping my experience back then for this article and looking at how I build my projects today, I can proudly say, I’ve come a long way. Taking small steps along the way was what I needed to do back then, when enthusiasm and javascript fatigue got the better of me.
