DEV Community: t.k.langston

Digital Hoarding

t.k.langston — Thu, 17 Sep 2026 18:00:46 +0000

History of the term “hoarding”

Hoarding certainly isn't a new concept. The word hoard goes all the way back to Old English, where it meant something closer to a treasure or stockpile kept for future use. Somewhere along the way that perfectly reasonable idea of saving something for later took on a much less flattering meaning.

For a lot of us, though, “hoarding” really entered the everyday vocabulary around 2009. That was when Hoarders showed up on A&E and suddenly we all became experts. A stack of newspapers was no longer just a stack of newspapers. That spare bedroom nobody could walk through? We had concerns.

Then came the heightened awareness of the “signs.” Calling out family members... being called out ourselves... identifying which house in the neighborhood should probably be expecting a camera crew next.

Funny thing is, while we were looking at everybody else's garages, basements and spare bedrooms, some of us eventually noticed another form of collecting happening much closer to home.

It was just hiding on a hard drive.

History of digital hoarding

Starting out as a graphic designer in the early 90s, I quickly became aware of the value of clip art. Not that we relied on it as a staple of our design, but it was a way to expedite some of the creative workflow. Add to that the fact that I was working in a more production-driven art department, and having existing assets on hand helped with turnaround.

Whether it was dragging out the “Art Explosion 600,000+” clip art book paired with its folio of CDs, or swapping Zip drives full of company and client assets, there was real value in having a library of material ready to go.

Then came the internet. Those types of assets became more readily available, stock photography exploded, and suddenly there was always something else worth downloading.

Technically, as a designer, you didn't need all of those assets sitting on your own machine. But the “what if I need this later?” mentality started to creep in. So did the feeling that if you had access to a giant library, like iStockphoto or Shutterstock, you might as well get what you were paying for.

Soon enough, you had your own version of Art Explosion... only now it lived across hard drives and a catalog of writable DVDs.

Then hard drives got bigger, storage got cheaper, and the available headroom started to feel limitless. So, much like the house stacked with old newspapers and issues of National Geographic, we found ourselves digitally hoarding.

Only now we weren't just filling our own “houses” with clutter.

We had servers.

For me, the shift into web development added another category entirely. I started collecting bookmarked websites for inspiration, coding tips, tutorials and references. Thanks to services like Delicious for bookmarks and Evernote for web clipping, my digital garage was now overflowing too.

And the thing is... a lot of it really did have value.

That's what makes it difficult.

The problem is that keeping everything isn't free just because storage is cheap. Someone still has to organize it, remember where it is and, eventually, find it again.

Sometimes the time spent curating all of these “assets” starts to rival the amount of time they actually give back.

Am I cured?

Short answer is maybe... or maybe the habit has just shifted again.

The means of collecting these assets and resources has changed over time, but I still find myself filing away one digital thing or another for if and when I need it.

Web bookmarks. New apps to try. Screenshots. Code snippets. Articles. AI-generated images where somehow iteration number 14 still feels different enough from iteration number 13 that I can't quite bring myself to delete it.

The funny part is that we're also living with the opposite behavior at the same time.

We have developed a kind of disposable mentality toward a lot of digital information. With text messaging, the only relevant statement often feels like the latest one. Everything before that gets buried somewhere in the infinite scroll.

The same is increasingly true with AI chats. A conversation can contain something genuinely useful, but a week later you may only vaguely remember that you had the conversation at all. Even the AI can eventually lose track of where the original context began.

So we simultaneously keep everything... and lose everything.

Storage isn't really the scarce resource anymore. Attention is.

The hard drive may have another terabyte available, the cloud account may happily accept another ten thousand files and the bookmark service may never complain about one more saved link.

But my memory and my time don't scale quite as easily.

So I probably still have some house cleaning to do...

My Car Had a Check Engine Light. My Code Has console.log().

t.k.langston — Wed, 26 Aug 2026 15:03:00 +0000

Sometimes the Best Way to Find a Bug Is to Move It

A few weeks ago, the check engine light came on in my 2007 SUV. I plugged in an OBD scanner and got P003F: “Intake Camshaft Profile Control Stuck On, Bank 2.” Sounded menacing enough…

Then there’s me. I know enough about cars to be adventurous. With my dad’s sage advice rattling around in my head, I can change parts, follow instructions and generally understand what some systems are trying to do, but I’m not a mechanic. So I did what most of us do when a warning light appears… went straight to the mechanic. Nah. I pulled out my phone and looked it up. (There’s another whole post on where we are with that process.)

Back on the case: the code pointed toward the cam profile system, but that didn’t mean there was one obvious part to replace. According to the sources I was finding, it could be a solenoid, wiring, a connector, oil flow or something farther into the mechanical side of the engine. The more I read, the more familiar the whole thing started to feel. I had an error message and a collection of possible causes, but the error wasn’t actually telling me which one was responsible.

Basically, I had a bug.

What finally made the diagnosis interesting was discovering that the car has two identical solenoids controlling the same system across two groups of cylinders. That meant I had something much more useful than a list of possible problems. I had a way to test one.

I did what any problem solver would do and swapped the solenoids, cleared the code and drove the car. Sure enough, the check engine light came back, which normally isn’t something to celebrate. This time it was! The code had changed from Bank 2 to Bank 1.

The problem moved with the solenoid.

At that point I wasn’t replacing a part because a forum post said it was probably bad. I had taken a component from one side of the system, moved it to the other side and watched the fault follow it. The wiring didn’t move. The connector didn’t move. The oil passage didn’t move. The solenoid did… and so did the error. I ordered a new one. At that point, the hard part was over.

Somewhere during all of this it occurred to me that I spend a surprising amount of my working life doing essentially the same thing, just without an engine cover in the way.

Finding where it went wrong

When something breaks in a website or application, the visible error tends to get most of the attention. Maybe a component doesn’t render, an API request fails, a Lambda function throws an error or the browser reports that something is undefined. That’s where you first see the problem, so naturally that’s where you start looking.

But that’s not necessarily where anything went wrong.

A front-end problem can begin several steps before the browser finally complains about it. The API may have returned something I wasn’t expecting. The API may be fine, but I transformed the response incorrectly. The error is often just the point where the system finally admits it has a problem.

That’s where the car analogy started to stick with me. P003F told me Bank 2 had a problem. It didn’t tell me that Bank 2 was the problem. Once I moved the suspect component somewhere else, the distinction became obvious.

We can do the same thing with code, and in many ways we have it easier because software lets us move things around without getting our hands dirty.

Say I click a button and the number that appears on screen is wrong. There are a few places that could have happened: maybe I read the wrong value from the form, maybe the calculation is wrong, or maybe the function that puts the result on the page isn’t doing what I think it is. Rather than staring at all of it, I can give that last function a value I already know is correct. If it displays $125.00 when I hand it 125, then I haven’t fixed the bug… but I’ve probably eliminated the display code as the source of it.

So I move backward. What value came out of the calculation? If that’s wrong, what values went into it? I might hard-code one of those values, bypass a function for a moment or drop a console.log() between two steps to see exactly where the expected number changes. Each little test changes one thing and asks the system the same question the car test did: does the problem stay here… or does it move?

That is a much different mindset than changing code until something starts working again.

`console.log()` as a diagnostic tool

This is probably why I’ve never quite accepted the idea that console.log() is somehow an unsophisticated way to debug. Used badly, sure. A dozen logs that say HERE, HERE 2, and WHY IS THIS NOT WORKING aren’t exactly observability.

I’ve certainly written them anyway.

Used deliberately, though, logging is really just a way of putting gauges, or breakpoints, along the route. When something goes wrong somewhere in a chain of JavaScript functions, I want to know what the data looked like along the way. I don’t necessarily need to read every line between point A and point B. I need to find the last place where everything was still what I expected it to be.

So I might put a log before a function and another after it. If the value is right going in and wrong coming out… well, we’ve narrowed things down considerably. If there are eight meaningful stages between the user’s click and the bad result on screen, I might start somewhere around stage four rather than stage one.

If everything looks right there, half of the system becomes considerably less interesting. If it’s already wrong, the other half does. Then I split the remaining half again. It’s essentially binary search applied to debugging, although I’d never really thought about it in those terms while doing it. Half the code on, half off. Bypass this section. Feed that section known-good data. Find the point where good becomes bad.

Eventually there isn’t much room left for the bug to hide. Squeeze that little bugger…

The important part is resisting the urge to change too much along the way. We’ve all had the debugging session where you modify three functions, update a package, clear a cache, restart something and suddenly everything works. Great… except now you don’t actually know why.

The car test worked precisely because I didn’t do that. I changed one thing. I moved the solenoid. When the fault moved with it, the car had answered the question for me.

No lack of tooling

Of course, software gives us another advantage. We have an absurd amount of tooling designed to catch problems before we ever get to this stage. Linters, types, tests and IDE warnings are all standing along the road waving little flags before the check engine light even comes on. We’re a long way from hunting through 1,698 lines of JavaScript for the missing semicolon.

console.log() isn’t the Holy Grail here. It’s just one particularly simple diagnostic tool, and one that happens to make the parallel with the car especially obvious.

Taking things apart

Somewhere in the middle of all this, I realized I’d probably been primed to think about the problem this way because I’ve spent an unreasonable amount of time watching Mat Armstrong rebuild damaged cars on YouTube. He buys cars that most sensible people would look at and immediately decide should remain someone else’s problem, then starts taking them apart.

A McLaren or Ferrari can look catastrophically damaged when it arrives, but the interesting part is figuring out what is actually damaged. Some things obviously need replacing. Others look terrible but are fine. Something that appears fine turns out not to be. One repair reveals the next problem, and eventually what began as a wreck becomes a collection of smaller, understandable problems.

I find it captivating to watch them chase those problems down, probably because it scratches the same problem-solving itch that development does.

I rarely understand the whole problem at the beginning. I have a symptom and a rough mental model of the system, then I start taking it apart, figuratively at least, until I understand enough of it to make the next decision.

That might be the real parallel here. I didn’t understand the entire cam profile system when that check engine light came on, and I didn’t need to. I just needed to understand enough to figure out what to test next.

The same is true when I’m staring at a piece of code that isn’t doing what I expected. I don’t necessarily need to understand the entire system before I can start narrowing things down. I need a hypothesis, a way to test it and enough patience not to change three other things while I’m waiting for the answer.

Sometimes that means better tooling. Sometimes it means a breakpoint. Sometimes it means turning half the code off.

And sometimes it’s just console.log().

Either way, the goal is the same… give the problem fewer and fewer places to hide.

Art Director’s Advantage in the AI Gen Era

t.k.langston — Wed, 22 Jul 2026 18:53:42 +0000

Round and round we go

Gaining an advantage in AI design workflow's isn't based on better prompting. It's something we've been doing for decades...

First off, this isn’t an "AI is taking my job" post. It’s a "who’s already got an edge?" post.

As AI settles into creative workflows, a divide is opening up. Some people consistently get better results. Experience helps, but something deeper is at play... an insight sitting in plain sight.

Enter the Art Director

I’ve never carried the title, but I’ve worked with enough Art Directors to appreciate their superpower. It isn’t simply seeing the vision... it’s being able to articulate it. They instinctively know how to explain why something isn’t working and what needs to change.

They choose words that shape an idea. Words that push, pull, tighten, soften, emphasize, and refine.

Think about a typical creative brief. It rarely says, "Make a brochure." It says:

"The typography should feel established, but not corporate."
"Give the layout room to breathe."
"The call-to-action should feel confident, not aggressive."

None of those are technical instructions. They're creative direction. Today, the prompt bar is simply a new creative brief. Those same words can guide an AI model to the same destination.

Prompt Seekers Lament

Sometimes we become prompt seekers, searching for a magical combination of words that will produce perfection on the first try.

Anyone in design knows how unrealistic that is.

The first concept is rarely the finished concept. Designer presents, client reacts, designer refines, client reacts again... and round you go.

Iteration wasn't a workaround. It was the process all along.

Yet the trend on X is always some eye-catching image with everyone asking for the "one-and-done" prompt.

AI is great at creating options. It's much less impressive at knowing which option is right.

Cue the Director

Instead of saying, "Something isn't right," an Art Director diagnoses the problem:

"The composition is balanced, but the visual hierarchy competes with the message. Reduce secondary elements, increase contrast on the subject, and let negative space do the work."

That's the difference. It isn't better prompting.

It's knowing what to ask for next. The ongoing conversation is where the real creative direction happens.

Sometimes that direction means knowing when AI isn't the right tool. Today's workflow might mean moving from ChatGPT to Nano Banana, switching image models, or (wild concept) handing it off to another human.

The role of an Art Director has never been to personally create every piece of work. It's knowing how to get the best work out of the tools and people available.

We already do this when we bounce between models based on their strengths or plug in system prompts and style references. But style matching isn't direction.

No specific lessons here... or are there? Just an observation.

Well, a shared one (as Adobe recently noted in their piece, "Creative direction: The secret to great AI images").