Better Developer Tools

While developer tools are important (and you should probably make your own), the goal of this post is to emphasize the importance of embracing tools that will make you a better developer.

If you’ve used one, you know what I’m talking about.

With some tools, some “AHA” moments — you just feel that the better you get at the tool, the better overall developer you become.

I call those tools “Better Developer Tools”, and I believe we should embrace them whenever we can.

How Does One Recognize a Better Developer Tool?

Let me take a step back to the complete opposite, and identify the attributes that are associated with “Worse Developer Tools” (yes, I’m great with naming).

During my development career I’ve seen a few, and here are the key patterns I found:

• Complex Custom Abstractions — They’re based on complex custom abstractions, which makes it hard to reason about or migrate away from.
• Getting Started Is Hard — There’s a lot of content you have to learn ahead of time in order to be productive, and it’s extremely hard to utilize this knowledge in another app.
• “Just Call a Senior” — A lot of the bugs are not Google searchable, and the common way to solve them is to call a senior developer.
• Longer Onboarding Process — The onboarding process involves learning new abstractions and vocabulary, with minimal correlation to previous knowledge.

After we’ve established a baseline, let’s try to deduce the principles “Better Developer Tools” would follow:

• Embrace The Fundamentals — Based on proven fundamentals, while extending and making the underlying technologies/concepts more accessible.
• Getting Started is Easy — Getting started is relatively easy, whether in an existing or a new app, and you can add additional complexity just in time, when needed.
• “Just Google It” — Bugs and patterns are usually Google searchable, and more specifically, they can be found on sites that are not specific to a single tool but the whole platform, like MDN.
• Shorter Onboarding Process — The onboarding process leverages existing knowledge and focuses on topics that you should probably be familiar with already.

Alright, now let’s try to identify those patterns in some of the tools I’d consider a “Better Developer Tool”.

Better Developer Tools Examples

React

• Getting better with React forced me to get better with JavaScript (Classes, Closures, etc.)
• React’s component model helped me reason about separating concerns such as data, logic, and UI
• You can add React to any website and use as little or as much React as you need

Redux

• Redux was my entry point to functional programming (pure functions, reducers) and one-way data flow (Oh, those flux days…)
• Redux’s core is not coupled to any framework and can be used as a data store for any UI layer

Remix

• Remix leverages web fundamentals such as Server Rendering, the Fetch API and HTML
• A lot of the learning curve around Remix, like HTTP Caching, has nothing to do with Remix itself — again, it’s just web fundamentals
• Remix apps can be deployed anywhere, and doesn’t rely on a specific provider

Closing Words

Ryan Florence and Michael Jackson, the creators of React Router, unpkg, and also Remix, inspired the writing of this post, and to wrap up, I’d like to quote part of their own Remix Docs:

If you get good at Remix, you will accidentally get good at web development in general.

Accidentally becoming a better developer.

That’s the pit of success I want to fall into, and I believe we as a community should embrace those “Better Developer Tools” whenever we can. Doing so will help the whole ecosystem improve, one (better developer) tool at a time.

Fiverr is hiring in Tel Aviv and Kyiv. Learn more about us here.