Start Simply, Simply Start
Originally written/posted on ifelse.io
- 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.
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, and 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 again exactly? What happened to The jQuery™?”
- 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”
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^1).
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.
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^2. 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.
Thoughts? Share them here or discuss on Hacker News.
[^1]: jk, ❤ to npm
[^2]: dependent the worst sense, like coupling between modules. This is not to say that any measure of dependency is inherently bad :)