Whenever you aim to blog about a series of different things all seeking to help out people write quality code (or write anything, really) to help improve their workflow, you’re bound to get feedback, right?
Don’t get me wrong. I welcome it. I think it helps to make for better writing in the future (that is, I ask, what can I do better).
And at the risk of looking like I’m “calling someone out” (which I am not), I want to share an [unattributed] tweet that I received last week:
your title “high-quality code” got me pumped for some hardcore stuffs, but dude ~99% narrative vs ~1% code?? *drops dead on his keyboard*
And I get it. There’s very little code in a post that is aiming to talk about code. But there are reasons for this, and it comes from a few years of both reading articles, writing articles, reading code, and writing code.
So I thought for others who have the same thoughts, it might be worth explaining why I take the approach I do.
Understanding Before Coding
To be clear, nothing here is meant to single anyone or anything out. If anything, it’s my generalist on the topic and why I think talking about, writing, and sharing posts on high-quality code
1. An Oxymoron
Our current programming culture seems to foster and perpetuate the idea of coding first and [maybe] understanding later. This seems backward to me.
I don’t like copy and paste coding because the term is a bit of an oxymoron. You can’t both be writing code and copy and pasting it. It’s either one or the other.
I think Toby’s mentioned it best:
high quality code can not be copied and pasted from the internet.
I think it’s important to make sure that we can write the code on our own. And to do that, we’ve got to have a bit of understanding.
2. Invitation to Understanding
Finally, it’s called code for a reason. In my mind, the last thing that we need to worry about is the code itself.
Tools can help, of course, but if you don’t understand the errors, you can’t improve.
That is, it’s important to understand what we’re trying to do and a high-quality or a robust way to do something. Thereof, understand the concepts behind what we’re doing is more important than the actual code.
Because if you don’t understand the concept, you’re not going to understand the code.
Any More Reasons?
Off the top of my head? No, but that doesn’t mean there aren’t more.
But if these are the three that come to mind most easily, then I find they are usually the best reasons for a given approach. This doesn’t mean the approach is right, but at least they are justified.
