The cure for Javascript fatigue
When I started programming in the 90s, getting online was expensive. Most of the time I was coding I didn’t have internet access. All I had was the API documentation on a CD.
So I had to try things out and experiment to find solutions when I got stuck. I implemented basic functions like substring and strcmp myself because I didn’t know they already existed in standard libraries. I wrote an IRC client in one large C file.
This process of trying and failing made me feel some pains. But I always improved my code. I learned the hard way the reasons behind best practices and clean code.
I only asked questions online or searched AltaVista for tutorials when I was completely stuck for several days.
Now a few decades later we are always online and have constant access to a never-ending flood of content. Our first impulse when getting stuck is to read or ask in a forum. We read and read and read. We want to follow best practices and use the “right” libraries.
But the more we read the more confused and overwhelmed we get. With all information, it gets difficult to differentiate the facts from opinions. This is a well-known problem and people call it Javascript fatigue.
Reaching for blogs and tutorials feels like the correct way to solve problems. But is it really the best use of our time as developers?
I don’t think it is. And I want to share with you some other approaches I use that might inspire you.
Code without internet. Only API as reference
Next time you are on a bus or an airplane without internet access open up your laptop and code anyway. It’s a good exercise. You might feel you are wasting your time coding things that would take 1 min to look up on google. But I can guarantee you are not wasting your time if you are serious about your development as a developer.
You will be forced to think about your problems in another way. You will get new perspectives on the challenges you have.
When having a problem, think deeply instead of asking
Instead of first asking others for help, start by asking yourself. Make sure you are asking yourself the right questions.
Tips for questions you can ask yourself:
- What am I really trying to achieve here? What are the exact requirements for this application/feature?
- What options to do I have?
- What are the pros and cons of each option?
- Look at the bigger picture. Is this even a problem I have to solve?
- Can I solve this problem in a completely different way? Using SaaS? Using a library?
- If the request comes from a customer, product owner or other stakeholders: understand why they want the feature/fix. Often there a better solution than they have come up with.
I have written a whole article about questions you should ask your self when you get stuck.
Measure instead of assuming
“Isn’t SSR slow?”
“I have heard arrow functions are bad for performance.”
“Isn’t looping through a large array with map slow?”
Instead of assuming and guessing - measure it.
Try more than one implementation as an experiment
Are you not sure what style of conditional rendering you should use? Not sure if you need Redux or not?
TRY SOMETHING OUT!!
Go to prod with it. Did it suck? Ok - rewrite it.
Don’t be afraid of writing code that is not “best practice”. And don’t be afraid of refactoring and constantly improving your code base either.
Trying things out is the only way to learn what solution works in your specific application.
Next step
Use this “deep work” mindset for the programming challenge you are facing right now. Don’t fall for the temptation of looking things up on google until you have tried some of the strategies I have presented here.
And subscribe to my email list to get more deep reflections about React programming.