with a grain of salt.

August 23, 2020

editor's note.

As I'm editing this, I'm realizing that I probably should go ahead and apologize for the RIDICULOUS amount of links in this post. However, I really do encourage you to click through them, especially the two "modern web" articles so that you can get all of the context. Also, I really do encourage you to listen to the No Plans to Merge episode, too, because those guys go into way deeper detail and have a much longer discussion about all of this (and because it's just a really great podcast to listen to).

Ok, on with the post.

the question.

A few weeks ago, I was approached with a question: "If you could tell one thing to every person out there who is starting to learn programming, what would it be?"

Well. That's a lot of pressure.

I honestly don't remember what I said on the spot, but I'm sure it was something generic like "never give up" or "don't forget to test your code". Whatever I settled on, after having a few weeks roll by with that thought rattling around in my head, I think I've come up with my real answer. It's funny, though, because I feel like this advice is pretty evergreen—I know new programmers and professional programmers alike who need this advice, myself included.

"Take everything you see with a grain of salt."

the answer.

That might seem a bit pessimistic: take everything you see with a grain of salt, but I think that it's not entirely off-base. Now, I'm a believer that there is some amount of objective truth in the world, and following closely behind that, I'm also a believer that, in programming especially, there are best-practices that most developers would do well to follow. However, especially in programming, there's always the danger of falling for anything we read in a tech article, hear on a tech podcast, or see in a tech video. And that happens more frequently to most of us more than we'd all probably like to admit.

It all comes back to the same issue: one size doesn't fit all.

one size doesn't fit all.

This is something that I've been clamoring about for a few years now, but it's not a new idea. Jeffrey Way has been preaching the idea that you have to do what's right for the situation for years now on Laracasts and on his podcast, The Laracasts Snippet (both of which you should check out if you're a PHP developer), even taking the same approach with TDD on a recent episode of the podcast, TDD Dogmatism. What really sent me over the edge, to the point where I felt I needed to put out my own content in favor of this idea, was listening to the No Plans to Merge podcast with Caleb Porzio and Daniel Coulbourne earlier today.

On their episode, "The Modern Web" (yes, the quotes are included in the episode title), they talk about the two articles written by Tom MacWright and Rich Harris that go back and forth about the issue of "the modern web". For reference, Tom's article, Second Guessing the Modern Web was written first, and Rich's article, In Defense of the Modern Web was written in response. I'm not going to go into detail about the two sides of the story (you're just going to have to listen to the podcast to find that out), but I do want to affirm the point of view that Caleb and Daniel landed on in the episode.

It seems like most developers (myself included) have a really hard time with the idea that something isn't the perfect solution to all use cases. Maybe that's just a human thing, but I'm 100% not qualified to answer that question. Regardless, it's really easy to fall into the trap of thinking that there is a perfect answer to all of the use cases and reasons why we build websites, and, like Caleb and Daniel talk about in their episode, I, too, think that's where these articles miss the point. Now, I have nothing against either of these articles in their own right, because I think they're great illustrations of the pros and cons of using front-end-based application frameworks and using server-side-based frameworks. However, putting aside the idea that front-end and back-end frameworks are really horrible ways of describing these things (that's a rabbit hole for another time), we land back on the idea that one size doesn't fit all.

There are a million reasons why a developer would choose to build an SPA instead of a server-side rendered app, and a million reasons why the opposite would be true, too. It all comes down to which tool fits the use-case best. It's like the (probably cliche) saying goes: "When all you have is a hammer, everything starts to look like a nail." I know that I'm a huge fan of building my applications as monolithic, TALL-stack-based applications, but I also know that there's a limit to what that stack can achieve. My skills and abilities with that stack allow it to go really far, much farther than it would for someone who's never written server-side code a day in their life, but there's still a point where there's probably a better solution. And that's ok. It's ok for a library or framework to not cover every use-case in the world. Not only does one size not fit all, more often than not, one size fits all ends up fitting no one.

So beginner devs of the world, remember, don't take everything you see as perfect truth. Take everything with a grain of salt, because there's never going to be a "golden hammer" that solves every problem in programming. But also don't be afraid to push your preferred way of programming to its limits! It's one thing to hear about the edges and limits of a library or framework, but it's not until you actually venture to those limits that you understand the true extent of them. And once you understand those limits, it's much easier to see what shiny, new tool to place right next to your trusty hammer so that you can use each for the things they're best at.

Oh also, if you got to the end of this post and are thinking that this is the way that you and everyone else should look at things, maybe go read the post again 😉.

Join my mailing list!

No spam, just a weekly newsletter with thoughts, discoveries, and cool new things in the world of programming.