Start Simply, Simply Start

tl;dr:

• Start Simply: Use, build, learn what you need when you need it.

• Simply Start: Don’t let everything get in the way of doing something.

There’s been a lot of talk, writing, presentations, and tweeting over the past year-ish about the sheer pace of development, proliferation of tools, and overall craziness of the JavaScript universe. Whether it’s been endless framework proliferation, tooling insanity, or whatever else, I’ve gotten the sense that people are equally as excited about the new things people are doing with JavaScript as they are fatigued and overwhelmed by everything.

So, JavaScript

Within this swirling storm of craziness, I’ve been very interested to see not just how the thought-leaders in our community have acted/reacted, but also how the junior developer, the absolute beginner, the not-a-JS-expert seem to be taking to things. More seasoned developers can be either cynical or turn into hype machines and I think it presents a difficult view of the community to newcomers.

People are left wondering whether or not everything is amazing or terrible, often, it seems, without any way to find a happy medium or sensible balance. I’ve seen responses from newcomers and beginners ranging from “what is happening” to “so I need to learn Webpack, React, Angular 2, Ember, JSX, and…what is this ES6 thing exactly? What happened to The jQuery™?”

To point, some things happening in JavaScript

• tooling (Webpack, rollup, browserify)
• libraries (React, cycle)
• frameworks (Angular 2, Ember)
• langauges (Elm, &c.)
• paradigms: one-way data-flow over 2-way/MVC
• component-focused thinking
• node foundation
• task runners (gulp, broccoli, &c.)
• ES6/2015/2016: babel
• data-fetching frameworks (Relay/GraphQL, Falcor)
• functional-reactive programming (rx.js)
• npm, jspm, System.js
• “module liberation”

That’s a lot, and it’s not even close to everything. In a dynamic, evolving field like software you’d expect there to be a lot of “stuff” going on. The difference between a normal pace of development and what the JavaScript community has experienced over the past several years is that there’s been a renaissance of sorts happening. And maybe that’s too much to say, but at the very least there seems to be a lot more going on than usual, whatever the reasons.

So, I’m not going to present an extended essay on the state of the JavaScript community or wax poetic about how things are possible now that never were before. Instead, I just want to present two simple principles that can serve as guides for developing in a hurricane.

Start Simply

You don’t need Everything™ for every. single. project. Are you tired of endlessly learning everything to do just one simple thing? If you aren’t, props to you. But I bet you are, and I don’t think you have to be. There are a crazy number of incredible projects, solutions, libraries, and more available to you via npm (unless you want something that rhymes with a company’s legal name¹).

I’m not knocking learning or saying “don’t learn”. You have to if you want to be successful in any field, much less the rapid, dynamic one that we work in. You just need to acknowledge that the amount of what’s learnable & usable is significantly greater than what you need at any given moment.

So, start simply:

• make sure your tools match the complexity of your project
• only “level up” when you really have to
• don’t be cynical. There are better ways.
• don’t be a hype-machine. They’re not all better ways.

Simply Start

Let’s be clever and flip things around — we talked about starting simply, so now let’s simply start. First I have to point out that if you’re trying to learn, use, build with everything, you’re not going to be as fast or effective as someone focused on simplicity — it’s just a function of available time in a given day. Also, if the size of the API surface you’ve included or created for yourself in a given project has size X, that’s all space for possible bugs, future changes to APIs, space to secure, and so on.

But even worse than being slower and creating a huge API surface is not really starting at all. I love this quote from Addy Osmani.

“First do it, then do it right, then do it better”

There’s a dangerous tendency to, for fear of doing things wrong or trying to understand everything first, never really do anything at all. Some call it “developer paralysis”, but whatever the name, it’s a real tendency and a real danger. So do it, do it right, and do it better. Pick a problem and build something with it. Don’t worry about it being perfect the first time. It won’t be. Approach problems by trying to actually solve them, not by only thinking about solving them.

Ryan Florence has pointed out that we should do without the second clause -> “do it right”. I’m sort of split on this. On the one hand, I totally agree; don’t be concerned about doing things “right” (e.g., developing things the exact way everyone seems to be instead of solving problems your own way first). I’ve always thought of “right” as “get it working”, but that’s just me.

But the point remains either way: simply start doing. Curious about how React works? Build it yourself. Maybe not the entire thing, but the core of what makes it work. Frustrated by something in your workflow? Fix it with something you built. Creating something that doesn’t work and make it work.

Once you get to the point where you actually understand what’s going on and what’s what, then you can make the choice to pull something off the shelf and use it. You’ll get what the developer behind it did and what tradeoffs it presents to you.

But if you never do the hard work of understanding and doing first, you’ll forever be dependent on someone else’s work¹. And if you never do, you’re just auditing the class and you won’t get any credit for it. Do the homework, read the books, listen to the lectures, talk with the professor. Get the grade. Take the class. Simply start.

Start simply

Simply start

Repeat

Thoughts? Share them below or on Hacker News.