When I sat down to write this post, I didn’t have an idea as to convey what I wanted to say. (And that’s a ridiculous thing to feel when you’re writing. )

Honestly, I just had a single sentence that I’d jotted down a few days ago and was going to flesh out in more detail.

I wrote:

You begin to develop a sense of intuition for how something should be designed or implemented.

It’s not even really a fully developed thought. It’s just a statement (and I’m not even sure it’s a good one) that I was going to explain in more detail. But then I stumbled across this post and found this statement:

I’ve become a big fan of the “do less & be lazy” approach to building things.

And though the post is about the performance of pages using web fonts, it’s still related to what I want to convey.

All that to say I didn’t have a post, just a statement, and I needed an opener. In reading another post, I found it in the quote above.

Continue reading

The idea of using some type of configuration files for a project isn’t anything new. Nor is the idea of using a format such as JSON.

Look in any directory for a number of major applications that you use, be it a source control manager, IDE, a build tool, et al., and you’re likely to find some type of configuration file. (And when it comes to build tools, many of us already write configuration files using JSON specifically to tell the build tool information about our project.)

Configuration Files as seen in VS Code.

Yesterday, I shared some of the challenges that can come with creatively solving problems and said that I was going to talk about something I’ve been working on:

With all of that said, it wouldn’t be particularly honest of me if I didn’t discuss and share my code, though, would it?

So that’s the purpose of this post: To talk about one way that I’ve been looking to solve a problem in a project on which I’m working.

Continue reading

One of the things about programming in the same “environment” for an extended period is that you get comfortable with the way you tackle similar problems.

Case in point:

When you start writing a plugin, you likely have an idea as to how you will implement something before writing it.

I’d venture to say that this begins to happen while the client is describing their problem. I don’t think there’s anything inherently wrong about this. In fact, I believe that it’s probably a good thing as it’s a sign you’re learning your way around the API, how to structure files, assets, and so on.

But at what point do we start coasting on autopilot? Or, perhaps a better way to ask it, is when are we just going through the motions of solving different-but-similar problems?

Continue reading