Harder does not mean better

Amongst us developers there’s a strange but strong notion that the most optimal way to do anything is to do it the hard and “classical way”. Be it mobile devs that insist that every app has to be written in their respective native language, game devs or software devs that insist garbage collection is horrible and makes you “lazy” as a developer or even web devs that insist you should stick to vanilla javascript and classic CSS and not even think about using something like tailwind or react. It’s almost like a badge of honor that they prefer to do things the hard way, the “classical” way. But is it truly better and does it make you a better developer?

Provide Value to the User

First and foremost our job is to provide value to the end user. Every single piece of software be it Backend or Frontend is at some point or another going to be used by someone. Even if they may not know they are consuming data from your API that cost you multiple weeks to build so that it delivers relevant data to the user at the right time. You are in essence providing that users with a certain value, the only thing that matters in that is that the value the user gets is greater than the value you put into it.

Here’s a good way to look at it, note that this is just one of many examples:

If you’ve spent 2 weeks building an API that will save 1.000 users even just 2h per week or provide them with just 2h of entertainment. You’ve essentially turned 2 weeks worth of work hours (roughly 80h) into 4.000h of entertainment or time saved. That’s a pretty damn good deal and success metric if you ask me.

The end user will never know if you’ve used the most optimized way to create that API, they also won’t care. Just like they won’t care if your app is written in React, Next, Astro(best choice), they also won’t care if you used tailwind or plain old CSS. They will only care if the app works and if it provides them with the value they are looking for.

The Harder Way is not Always Better

If you’ve spent any time on any social media platform out there, you’ve probably encountered the type of person who will tell you that you shouldn’t use X because it’s the lazy or the easy way and should instead do it the hard way first so that you can “learn” from it and have a deeper understanding of the topic.

And that’s fine, they’re probably right to an extent. Heck I’ve been that person before. But I think that’s also missing the point. If your goal is to learn then yes you probably should first attempt to understand the fundementals before you reach for the helper frameworks, libraries and tools, but if your goal is to get your product or your service out there to the public as soon as possible then you should absolutely use the tools that will help you get there faster.

Your mission is to maximize the value you provide to the end user with minimal time investment. If you can do that with a tool that is easy to use and understand then you should absolutely use it.

Don’t take it too far

So obviously we should always be super pragmatic and try to get as much stuff done with the right tools as fast as possible. However try and always be mindful that providing value to the user also means that you deliver a polished and well thought out product to them. Essentially don’t get too hung up on making your code as efficient as possible or as optimized as possible as long as it does not affect the end experience of the user. To put it in simpler terms, make sure you deliver good products that are easy and fun to use and won’t break every 5 minutes.

Do take Pride in your Work

However that doesn’t mean you shouldn’t take pride in your work. I know we all enjoy getting a nice compliment or word of praise from our peers when we’ve done a good job. It verifies that our efforts have been worth it. However always keep in mind that your peers are not your target audience, your userbase or target userbase is.

… Unless of course your peers are your target audience then definitely make sure to write clean and well thought out code that is easy to understand and maintain.

Which brings me to my next point

Move Fast but don’t Break Things

I never liked the motto: “Move Fast and Break Things”. It fools the reader into believing that if you move fast or deliver your products fast that you are required to break some things along the way. That’s not true. We live in a time where we are as developers spoiled for choice with tools that can help us move fast and deliver quality products. We got: Astro, React, Next.js, Svelte, Tailwind, Fastify, Gastby, tRPC, Supabase, Firebase, Railways, MongoDB and so on and so on.

Don’t be afraid to use the damn tools that people have built for you. You are trying to convert you time investment into value for the end user and these tools likewise were built with a time investment from their developers to provide value to you. Use them and use them well.

Too often I see twitter threads still berating people for using tailwind by spouting the same old argument that people should just “learn” css. Trust me if someone is using tailwind to any productive extent, they probably know CSS pretty well, better than most.

Same with tools like React, Next, Astro, Svelte, etc. If you’re using them you probably know vanilla javascript pretty well. You probably know how to write a simple web app without any of these tools. But developers choose to use these tools because they can help them move faster and deliver better products to their users.

So in essence don’t move fast and break things. Move fast and deliver instead.

Conclusion

So in conclusion, don’t be afraid to use the tools that will help you get your job done faster and more efficiently. But also don’t be afraid to take pride in your work and make sure you deliver a good product to your users.