My worst fear is becoming one of those programmers who are stuck in time. You know who I’m talking about.
These developers, who at some point in time made a terrible unconscious decision. “I know enough, I have tons of experience now.”
And from that point on, they stopped active knowledge seeking. They stopped challenging themselves with new ideas. They now rely solely on their narrow experience for guidance.
This might have worked out for you fine during the glory days of COBOL. But for modern JavaScript developers, this won’t cut it anymore.
We must always be learning.
I’ve been grappling with the question of what separates excellent JavaScript developers from the mediocre for ones for quite some time. Today I would like to share another piece the puzzle.
”Quality is not an act, it is a habit.“ – Aristotle
We are the sum of our habits
When I first the read The Power of Habit there was one immediate thing that rang true for me. It’s the concept of keystone habits.
You see, some habits are more important than others. Some habits trigger in us a “chain reaction” which causes a broader behavior change. For example, exercising regularly could cause you to eat a healthier diet, while smoking will have the opposite effect.
These are keystone habits. Habits that have a way of affecting us in a broader sense than what you would assume.
This discovery got me thinking “What are the keystone habits of effective JavaScript developers?”
”Motivation is what gets you started. Habit is what keeps you going.” Jim Ryun
Always be Learning
In our fast paced JavaScript world, a lot of us take for granted the need to keep learning. In fact, we have a phrase reserved for JavaScript learning exhaustion. But even with all the wealth of information available to us, I’m still encountering a lot of developers who aren’t proactive in their learning.
Excuses may vary. “I don’t have the time,” “I know everything I need to do my job” or “I’m tired of learning about every single new JavaScript framework that comes out.”
We’re all great at making excuses. Especially to ourselves. I should know, I’m a black belt self-excuse machine.
But these excuses won’t stop you from experiencing a JavaScript developer’s greatest fear – falling behind the curve. This is only a little more frightening than the other great JavaScript terror – Getting called names by Douglas Crockford.
Every developer should have their own method of expanding their professional horizons. Let me share mine.
”My fellow developers, ask not what your code can do for you, ask what you can do for your code.” – JFK in an alternate universe.
News and Latest Developments
In our rapid world of JavaScript, it’s difficult to stay ahead with everything. My way of keeping up with the latest JavaScript shenanigans is to subscribe to awesome JavaScript weekly newsletters. I’ve made a habit of going over them every weekend to see what the JavaScript world is up to.
It takes me between a half-hour to an hour until I finish going through all of them. It depends on how interesting and how deep I decide to go. I do find myself deep diving for 2+ hours on occasion when there’s an interesting tutorial to go through.
Finding the right balance is key so that you’ll always feel like you’re in the loop, but without fatiguing yourself to death.
A Side Project is your Friend
This is also a game changer. Developing and maintaining a JavaScript side project is another habit that pays for itself in dividends.
The thing about side projects is that they allow you complete freedom. There are no constraints, no excuses, no deadlines. It’s just you and your vision.
These projects can be as ambitious or as laid back as you want them to be. You could be working on a project you hope will be the next Twitter or a simple pet project that makes your life a little easier. It doesn’t matter.
There are a few tips I want to share about how to get the most out of your side project:
-
You want write to your side project using a language/framework/technology you think is cool and would like to know more about.
-
Your project can be as close to home as using Ember.js instead of React, or as alien to you as trying out Rust for the first time. One will give you practical insights, while the other will open your mind to a whole new way of thinking.
-
Ship your project. I repeat, ship your project! A side project is a perfect opportunity to get familiar with the entire dev release cycle. Setup logging, error reporting, continuous integration, the whole shebang. Rock that Heroku free tier and install all the add-ons 😃
Learn from Open Source Projects
Darwin would have been proud of our open source ecosystem. One of the great things about it is that only the best make it to the top. (Except Angular 😦)
Popular open source libraries tend to solve complex problems in an exceptional way. And while there’s immense diversity among them there’s one thing most of them have in common: They’re developer friendly and easy to work with.
Think about it. The more cumbersome an open source library is, the less likely it is to succeed.
That’s why I always try to learn from the libraries that do make it. React’s Components, Express’s Middleware pattern and Lodash’s method signatures are all learning opportunities in disguise.
Code with your colleagues in mind
This is my take on the old developer quote:
What I try to do, is ask myself throughout the development cycle “If a colleague had created this module, could I understand it and use it without going through the entire source code? Would I be happy to use it and could do so easily?”
Making it a top priority to write code that’s easy to use and understand is well worth the effort. You’d be surprised at the number of times I thought to myself “No one will ever use this code but me” only to be wrong time and time again.
In the end, though, it doesn’t matter whether someone else ends up using a specific module or not. Going through the motions of thinking how to best expose your code to be used by others will make you a better developer. And your colleagues will love you for it.
It’s a great feeling your having colleagues come up to you and ask if a module you’ve made could solve their problem. An even more incredible feeling, however, is when they don’t even have to ask, and you notice it later on in a piece of code you didn’t write.
Another beneficial side-effect is that you’ll be finding yourself having fruitful discussions with your colleagues about how to write code that’s easy to use and understand. Imagine decreasing the “Crap, I can’t believe I have to use module” scenarios and increasing the “Sweet, this module solves my problem” scenarios.
”Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler
Have the ideal solution in mind
Whenever I get a new assignment, I always try to think about the ideal solution before I start coding.
When coming up with the ideal solution the following rules apply:
- There are no time constraints. Imagine you have all the time in the world to do whatever you want.
- There are no architectural constraints. Imagine you could use whatever library you want and don’t have to use anything you don’t like.
Keeping these two rules in mind, I come up with the ideal way I would like to develop the project. Naturally, it’s very rare that I’ll get to execute the ideal plan.
But now I that I know what the ideal solution is, I have something to strive for. When I go back to the annoying reality of deadlines and architectural constraints, I try to remain as close to the ideal as possible.
Another great thing about this approach is that it helps me to sidestep the groupthink trap of “We’ve always done things this way up until now, so that’s how we should do new things too.”
Sometimes, you’ll find yourself asking for extra time so you could get a little closer to the ideal outcome. And since you now have a clear picture of what you’d like to achieve, you’ll have a much easier time justifying it.
Challenging JavaScript Development
The habits of constant learning and challenging yourself isn’t an easy one to develop. But once you get the hang of it, you’ll find them priceless.
It’s the easiest thing in the world to become cynical about our craft and develop a “nothing new under the sun” mentality.
But the truth is, every open source project we use and every assignment we get is another chance for us to leverage our learning skills and become better developers overall.