It’s Not Easy

The Meteor Chef
4 min readMar 20, 2017

For the past few weeks, I’ve been spending a lot of time learning. Initially, my focus was on trying to wrap my head around GraphQL and Apollo, and this past weekend, I wanted to take a swing at building a non-Meteor Node.js application. While learning both, it really sunk in: this stuff is hard. Really hard.

GraphQL is a total paradigm shift in respect to handling data, while getting a Node.js app up and running requires a lot of fiddling with complex tools like Webpack. Neither are a walk in the park to wrap your head around, especially on first pass. Even worse, while the internet is littered with examples, most are mystical. Sure, repos exist with examples, but seeing the code is not the same as understanding what the code is doing. Most of my time was spent connecting the dots between various repos and doing a lot of trial-and-error.

Now, if I were to mutter this in a group of even moderately-experienced developers, they’d scoff; at least internally. “Pssh, this is easy! I figured it out in ten minutes.” Without a doubt, whenever I’ve even hinted at struggling with something, there’s always been another developer waiting with baited breath to tell me in so many words that I’m an idiot, they’re smarter than me, and so on.

Web development is not easy. It’s certainly become easier than in the past, but it’s far from easy. When we codify things as “easy,” it inevitably leads to discouragement. If Übernerd A says it’s easy, then I must be an idiot for not getting it…right? Of course not. But this is the sort of culture we’ve begun to engender. When someone doesn’t know, we offer up helpless quips like “read the docs” when we know damn well good documentation is rare.

Instead of peacocking, we should strive to develop a culture where we take the time to properly explain things to other developers. Even if there’s no immediate return, on an altruistic level, we know we’re putting another well-informed developer into the ranks. No, that’s not easy. Yes, that requires selflessness. But even within the confines of your own team, it can mean the difference between someone leveling up quickly–effectively, making your life easier–or cowering away with a brilliant idea because they shudder at what the other developers will say.

What I feel is most important is understanding that the people who are less-experienced are the people who will need to know in the future. It seems a bit counterproductive to create a spirit of isolation around knowledge. If software development was war, wouldn’t it be worth your time to teach the person next to you in the trenches how to load their rifle properly?

Yes, your knowledge was hard-won. That’s a great thing. But what’s also great is being able to help others to understand what your process looked like to get to that point. Did you read the docs, or did you spend six hours one Saturday playing whack-a-mole with some new tech’s API? It’s funny, when you help others out, they tend to help you out in return, without you even asking. Taking the time to counsel others can pay serious dividends later.

“You can get everything in life you want if you will just help enough other people get what they want.”

— Zig Ziglar

Even with something like Meteor, building software is still a challenge. Most of our examples are trivial, so of course, we trick ourselves into thinking “with this new tool, I can build anything in minutes!” Of course, once you try to test the flexibility of any framework or tool, reality sets in. Everything has caveats. Everything has shortcomings. There is no perfect tool. No perfect solution. In order to create anything, you really have to know your stuff. That’s not easy.

If you’re in a position of power or looked up to by other developers in any way, be careful how you speak. Even if factually speaking your brain could “totes crush their brain, dude,” there’s no need to assert that. Whenever you do, you look like an asshole and you discourage the other person from putting in the necessary effort to get to your level. People don’t forget when you’re a jerk, but they also don’t forget when you were really helpful. Guess which side you want to be on.

As for the developers who have been caught in the Vortex of Insecurity™ that is many-a-developer’s ego, understand this: move at your own pace. There’s nothing wrong with not getting things quickly. It takes time. It takes patience. The majority of my own knowledge came from a ton of time spent just hacking at stuff. Putting pieces together, making mistakes, and really grinding it out…over ten years.

“You always want to consider your inner scorecard–how you feel about your own performance and success. You should worry more about how well you perform rather than how well the rest of the world perceives your performance.”

— Warren Buffett

Forge your own path. If it takes you six months to learn some new thing, so be it. Don’t psyche yourself out because the person sitting next to you figured it out quicker or made a little quip about getting there first. Better, learn the thing and then take the time to help another developer who is struggling with it later on.

Oh, and don’t forget to remind them: “just keep at it. It’s not easy.”

--

--

The Meteor Chef

The Meteor Chef teaches you how to build your next big idea using the Meteor JavaScript platform. These are our non-technical essays and blog posts.