Tag: Software Development (Page 4 of 20)

Don’t Forget: Remember to Build Tools

June 13, 2023 / Tom

As programmers, we’re used to leveraging all kinds of tools that help us to do our jobs be it something such as a debugger to something that helps us standardize our code to something that helps us to deploy our code to whatever platform we’re releasing our product.

And there seems to be a pattern that emerges for many of us as we work through our career:

We often try to write everything we can for ourselves (we have the time, energy, and desire to do so).
We start leveraging tools that helps us to achieve our primary goal (we have the know-how to use pre-existing, high quality utilities that help us to write better code or work with a larger project).
We develop a work flow for working in our niche and outsourcing all of the things that can be automated to third-party tools (we know what we need to focus on and leave the rest to other tools).

But do these tools that are part of our workflow always help us get our work done on a small scale? In other words, why don’t we remember to build tools for ourselves to use?

The Architecture Astronauts of WordPress

January 20, 2023 / Tom

One of the things I read – and learned – early on in my career was the term Architecture Astronaut. It was coined by Joel Spolsky (as far as I know) and it goes something like this:

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
Don’t Let Architecture Astronauts Scare You

I really liked the definition because then, just as I am now, I am surrounded by incredibly smart people from whom I can learn.

And for those of us in this field, it allows us all to:

learn great engineering techniques,
the reason why engineers write code a certain way,
and how to approach problem solving in a pragmatic way (pragmatic being the keyword here, but more on that in a moment).

But that’s not how it always is, is it? Not in other fields; not in WordPress. And the more segmented WordPress is becoming between frontend technologies and backend technologies, the more different these discussions are becoming.

For the purposes of this post, the whole architecture astronaut thing is something I hope all backend engineers pay attention to regardless of where they are in their career. (Let’s avoid architecture astronauts of WordPress.)

And here’s why.

On Social Media, WordPress, and Software

December 6, 2022 / Tom

This year’s Thanksgiving Break was the first time that I didn’t write anything I was doing over the break. I’ve been doing so since 2012 so this would’ve been a decade of doing it.

Almost made it 🙃.

But there’s the thing:

As if it isn’t evident already, the frequency of my writing has decreased but the length of the articles has increased.
I’ve also changed the front-page of this site such that it displays more about what I’ve done in my career in software development and WordPress,
And it includes a list to my most recent articles.

Given a post this year would’ve been a consistent decade of writing a traditional holiday post and how that’s changed, I couldn’t help but think about how things have changed within the web development economy as well as the WordPress economy.

And no, this is not going to be a nostalgic, reflective post.

Keep a Journal of What It Takes to Get It Working

April 8, 2022 / Tom

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.

It’s Okay to Write a Kludge, Sometimes

October 18, 2020 / Tom

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.