Software, Development, and WordPress

Tag: Software Development (Page 4 of 17)

Musing on Modern Package Managers

I was recently talking with a friend about all of the available tools that are on the market for us today (some free, some open source) that help us with our development needs.

Modern Package Managers: Yarn

These include things like:

Of course, each of the above is not necessarily comparable because some are front-end tools, others are backend tools, and there are some that offer a hybrid of sorts.

Further, some are premium, some are open source, some appear to be abandoned, and some have even lead to broken build processes.

This leads to a series of questions several of which I’d like to cover. So here, if nothing else but musings on modern package managers, are the things about which I’ve been thinking.

Continue reading

What’s The Simplest Thing That’s Needed?

There’s a quote often attributed to Albert Einstein that I quite like (and I’m sure most do):

Everything should be made as simple as possible, but no simpler.

There is some investigation as to if he said it or not, but the point remains regardless of who said it.

The Simplest Thing Possible: And No Simpler

It’s easy to take this idea and apply it to things that we do in everyday life that we don’t want to do, right?

  • I don’t want to clean my room, so I’ll tidy it up just enough.
  • I’ll do just enough work to satisfy the clients, and that’s enough.
  • I’ll fulfill [whatever responsibility] the to [lowest degree possible] and because Einstein [allegedly] said it, who am I to argue.

Even though I don’t agree with it (and the discussion for that is outside the scope of this post), I do consider this idea within the context of web development.

And to be clear, I’m not talking about web design. I’m not a designer. I don’t want to speak on behalf of something of which I’m not a part. But regarding providing solutions for people using software or, rather, web development, I’m far more inclined and positioned to talk about this.

Strictly speaking, I find myself often wondering if we’ve made web development more complicated (and why we’ve done so) and if using the simplest thing that’s needed is all that’s really needed when building solutions for others.

Continue reading

Ship It or Die (With or Without Quality, Though?)

One of the ideas that intrigue me is the “ship it or die” mentality. Regarding what it’s called, there are variations thereof, but the idea behind the phrase is simple:

If you have an idea, get it from concept to product as quickly as possible.

Sure, the idea of getting to concept to a product may also be called “concept to cash” but there’s never a guarantee that you’re going to generate cash, right? There is a guarantee that you can get it into a tangible product, though.

And in software development circles, there’s always a lot that a person can argue for or against the idea. Off the top of my head, the two pros and cons that come immediately to mind are:

  1. Pro. Getting something done quickly that works and that [potentially] generates revenue.
  2. Con. Weak architecture, maintenance, scalability, testability, and so on.

In short, there may be a tradeoff between how fast you can get ship something for a market and the architecture behind the project. Sometimes there is, sometimes there isn’t. Generally speaking, though, I think it’s safe to assume the former.

Furthermore, some may see the former as the easy way out, some may see the latter as an exercise in YAGNI or, even more simply, that the problem can be addressed whenever it comes up.

But what does this have to do with anything at the moment?

Continue reading

Let the Code Review Process Stand on Its Own

The more projects I work on with people who I hold in high-esteem, especially as it relates to programming, the more I find myself wanting to pre-justify the reasons I’ve made a decision about how I’ve solved a problem.

This isn’t to say that I try to be defensive about what I’ve done from the start. Instead, it’s more of an attempt to try to justify or rationalize the reason I did something so the person reviewing my code understands it and doesn’t think ill of it. The thing is, I’ve never really had an experience – at least not in the last, say, half a decade or more – completely obliterate my confidence.

Code Review Process: Part 1

Code Review, Part 1 via xkcd

Instead, they’ve done one of three things:

  • The person reviewing the code has made a recommendation as to how the code can be improved,
  • The person reviewing the code has asked why I did what I did (either to better their understanding or to see if there’s not a better way the problem could be solved),
  • The person has provided insight on how to rearchitect the solution simply.

And regardless of which of the above is used, I’m generally grateful.

Thus, one of the things I’ve been trying to get better at doing is merely deciding on how to implement a solution, commit the code, and let the code review process do its thing.

Continue reading

It’s Easier to Find a Solution (With Someone Else)

One of the most frustrating aspects of programming is working on a solution to a problem and bumping up against something that we should know how to do or be able to figure out how to do, but we’re unable to do so.

There’s probably a proper psychological term for this or an acronym given that I’m talking about programmers. 🤷🏻‍♂️

Case in point:

Let’s say that I’m working on a project and it has to make an Ajax request. I get the response, I display it, and I also cache the response for 24 hours.

If the user requests the information again, I pull it from the cache, and it looks fine. But what about whenever you’re the first person to hit it in the next 24 hours?

That is, you get a cache-miss, and then you get not only a longer-than-normal request, but you also get a response that needs some additional processing before rendering it to the user?

Easier to Find a Solution

Reading this, you’ve likely got a laundry list of things you’d try to do. And I’d venture to say that everything you’re thinking is likely worth trying if not right.

Ultimately, that’s proving my point. And that’s this: When you’re not as close to the problem, it’s easier to find a solution.

Continue reading

« Older posts Newer posts »

© 2022 Tom McFarlin

Theme by Anders NorenUp ↑