Tag: Software Development (Page 1 of 17)

This is not new information and this is not a new idea that you’re about to read. This isn’t a novel idea. This isn’t something that no one has ever discussed. This is the furthest thing from a new idea.

Instead, this is me re-iterating something that people in our field talk about over and over and over. It bears repeating though because it still comes up again. And with good reason: It’s a good reminder that we should be doing this.

We should be keeping a journal of the work we do. Really.

I don’t mean a blog, as much as I think they’re important, and I don’t mean Twitter threads, I don’t mean comments on Hacker News, and I don’t mean Stack Overflow questions or answers.

I mean text files or markdown files or HTML files or whatever it is you want to use. Here’s why: The longer you work in software, specifically on the web, the more likely you’re going to encounter all sorts of other software required just to get The Thing™️ working. And the less likely your exact situation is identical to someone else’s.

Sure they – or you – can say “Have you tried [doing this]?” or they can recommend “Upgrade [this particular package]?” or “Bypass [this particular dependency] because it’s likely not needed.”

That still leaves a lot of unknowns. They are suggestions.

TL;DR: Don’t avoid writing a kludge of code when the situation necessitates it. Sometimes, factors outside of our control dictate how quickly we can turn a solution around. At the minimum, leave a code comment that explains what the code does and optionally why it’s not included in a way that’s as consistent with the rest of the module in which you’re working.

When I first started in my career (as I imagine most people in our industry do), I was bent on writing the best solutions possible to the problems that I was given.

Nevermind that fact that I may not have had the experience of my peers, managers, or so on. I was bent on making sure that given the level of information I had, I was going to write the best code possible and aim to both prove myself but to show what I was capable of doing.

I was young. 🤷🏻‍♂️

Fast-forward over a decade, and things have changed.

When I decided that I was going to commit the journey of my career to building solutions on WordPress, I was – at the time – all in. That is to say that HTML, CSS, JavaScript, PHP, and MySQL were at a place where I could stay involved with all of them and work competently down the stack as needed for whatever it is I was building.

But as both my family [and I] have grown and as WordPress has changed over the past half-decade (let alone decade), that entire perspective has changed.

Not just that, though.

For as long as I’ve been writing on this site, I’ve used a combination of syntax highlighting, GitHub gists, or code or pre tags to help share code relevant to a given post.

But the more technical articles I read and the more that I see we, as an entire industry, start to rely versus utilize tools of Stack Overflow and other sites, the more I wonder how much we really understand what we’re writing (or even care) so long as the end results just works.

This isn’t a commentary on how quickly we should ship something. Instead, it’s about how we solve a given problem while also truly learning what it is that we’re incorporating into our codebase.

In previous posts, I’ve talked about the idea of focusing on an area and going deep rather than wide. This is personal preference, of course, but it’s mine, nonetheless.

Over the last year, though, one of the byproducts that I’ve found is the longer you stay in a given industry, the more common certain problems become. (This shouldn’t come as a surprise as this is precisely why we have design patterns.)

But the thing about doing this is that you develop a sort of tunnel vision for ways to solve problems.

Case in point: Recently, I was tasked with needing to develop some functionality that was going to parse markup and convert it into a slightly different format.