Not long ago, a blog I otherwise like a lot included this passage:

Designers have been saying this for years. Cameras don’t take pictures, photographers do. Tools don’t make you a better designer. Now the PM world is arriving at the same conclusion.

I am not linking to the post because I hear this argument from time to time, and I want to comment on the general notion.

I think I understand the sentiment behind it: You’re not a designer because you know all the Figma shortcuts. You’re not a perfect typewriter away from The Next Great American Novel. Mastery of a tool is not mastery of the subject matter. And there is definitely a certain amount of performative pretense of an insta photo of a meticulously arranged desk with a bougie keyboard, going at length about the only correct set of presets and plugins, or an idea that “if only you do this one creative habit, a firehose of creativity will follow.”

But I also disagree. Good tools do make you a better designer.

A good tool can make you go faster and, as a result, let you spend more time doing revs and trying new things. A good tool can make you go slower when needed, practicing a connection with the material underneath.

A good tool will prevent you from shooting yourself in a foot, will teach you new things about what you’re doing – and perhaps even about yourself.

A good tool will value your growth, make you reflect on your growing body of work, and push you to try harder.

A good tool can inspire you. A great tool can make you fall in love. A bad tool can make you walk away, and a horrible tool will make you never want to come back.

A good tool will make you seek out more good tools.

Sure, people wrote books on a BlackBerry. Would you want to? Sure, the best camera is the one you have on you. But wouldn’t you prefer that camera to also be the best camera for whatever it is that makes you tick – a great sensor or glass, an amazing build quality, a friendly user interface, a logo that makes you want to step up, or some particular quirk or sentiment that you can’t even explain, but matters a whole lot to you?

I’m told I should be annoyed if someone’s first reaction to seeing a nice photo I made is “what kind of camera do you use?”, as it diminishes my accomplishments as a photographer. But: I chose the camera, and bolted on the appropriate lens, and realized over the years the aperture priority mode and very precise focus area is what makes my brain happy. I went through other cameras before, and learned I didn’t like them and I liked this one. At some point in my life I even ventured out into the frightening underworld of the settings menu, opened a new browser window, and decided “I will now try to understand all of these terms.” It took years, but I did.

The reason I enjoy scanning and processing old documents is because I invested in my tools. I have a little keypad, a bunch of hard-earned Photoshop actions, and some bespoke Keyboard Maestro combos that boss Photoshop around. This little tool universe doesn’t just make me more efficient, but it also makes me have fun.

I’d go even further. The mastery of the subject matter and the mastery of the tool are both important – but they also have to be joined by fluency with tool choices, and deep understanding of the relationships you have with your tools.

No single writing advice book will give you a perfect recipe, but read ten of them and scan twenty more, and you might compile the right mixtape of practical tidbits for your brain, and inspiration for your soul. Likewise, you have to try out a bunch of tools – some bad ones, a few great ones – to understand what you need. Not just for efficiency, but also for enjoyment, and ambition, and flexibility or maybe rigidity, and this sort of unmeasurable feeling of a tool getting you, or a tool made by someone like you.

Maybe it’s the 1960s typewriter you need, or a newfangled e-ink-based writing implement, or maybe you just have to open TextEdit and close everything else. I’m not going to tell you the novel comes out then. But the novel might never come out if you don’t figure out what tool can help get it out of you.

You also have to recognize the telltale signs when you outgrow the tool, or when the tool starts disappointing you. Over the years, I learned that I hate InDesign, but that I hate LaTeX even more. I switched from Apple Notes to SimpleNote in 2012, went back to Notes in 2017, and just this year moved over to Bear. I once cargo-culted Scrivener for writing and ran away screaming, but I also once cargo-culted DevonThink and still use it today, in awe of its clunkiness and old-fashionedness that match my own.

AI tools are still tools. And generative AI will allow you to build more tools for the solitary audience of just you – but, like elsewhere, it will require some understanding what makes for a good tool and what makes for a good tool for you.

Craig Mod wrote recently about using AI to build his own custom tools:

My situation is pretty unique. I’m dealing with multiple bank accounts in multiple countries. Constantly juggling currencies. Money moves between accounts locally and internationally. I freelance as a writer for clients around the world. I do media work — TV and radio. I make money from book sales paid by Random House via my New York agent, and I make money from book sales sold directly from my Shopify store. […] Simply put: It’s a big mess, and no off-the-shelf accounting software does what I need. So after years of pain, I finally sat down last week and started to build my own.

But I bet Mod knew what tool he needed to build based on his experience with tools that didn’t work for him – and software and design in general.

Elsewhere, Sam Henri Gold in a widely-shared essay that is worth a read, about MacBook Neo and the beginning of the tool journey:

He is going to go through System Settings, panel by panel, and adjust everything he can adjust just to see how he likes it. He is going to make a folder called “Projects” with nothing in it. He is going to download Blender because someone on Reddit said it was free, and then stare at the interface for forty-five minutes. He is going to open GarageBand and make something that is not a song. He is going to take screenshots of fonts he likes and put them in a folder called “cool fonts” and not know why. Then he is going to have Blender and GarageBand and Safari and Xcode all open at once, not because he’s working in all of them but because he doesn’t know you’re not supposed to do that, and the machine is going to get hot and slow and he is going to learn what the spinning beachball cursor means. None of this will look, from the outside, like the beginning of anything. But one of those things is going to stick longer than the others. He won’t know which one until later. He’ll just know he keeps opening it.

I am bothered by black-and-white, LinkedIn-ready statements. “Tools don’t make you a better designer” feels like another version of the abused and misunderstood “less is more.”

My camera taught me to be a better photographer. DevonThink told me how to better organize my thoughts. Norton Utilities showed me how to have fun when doing serious things, and Autodesk Animator how to be serious about having fun.

I’m a toolmaker, so perhaps I arrive at this biased. I endured some crappy tools, wrote some okay ones, benefitted from some great ones. I don’t think I would have become a designer without them.

Beagle Bros was a 1980s software company making apps for Apple II that is still remembered fondly for their personality.

The company had a hobbyist slant, selling various small tools and collections with fun names like Beagle Bag (in the “Indoor Sports” collection) and DOS Boss and Utility City – similar perhaps to Norton Utilities on the PC side, but with a lot more fun and charisma. This is one of their loading screens, also showing both their recognizable logo and their endearing quirkiness:

The fun and well-photographed interview in Softalk in 1983 starts like this:

How do you understand a man who has three clocks on his wall, showing the time in three different cities-San Diego, Fresno, and Seattle-all, of course, showing the same time (″If anything changes in those cities, we’ll know about it”)?

…and has images like these:

Beagle Bros catalogs and manuals were filled with old-timey woodcut illustrations repurposed to tell jokes:

(I find the anachronistic combination of hedcuts and dot matrix printer typography particularly fascinating.)

Some of their software was more serious; Beagle Bros released many useful tools and even text editing and presentation apps. They also made practical posters:

But other stuff…? It was just goofing off:

How does this relate to craft and quality?

There is this interesting question about how much product and marketing and vibes and lore correlate. Did we forgive Sierra On-Line the numerous flaws of their games because we liked the company? Do we love Panic because we like what they do, or because of how they do it? Did Google put doodles on its homepage to distract people from more nefarious things, or because it just felt like a fun way to celebrate things? Is there such a thing as pure selflessness? What is the nature of free will?

Those are, perhaps, topics for future posts.

But Beagle Bros must have been doing something right if there is still a living, elaborate catalog of their works online, 40+ years later. Jeff Atwood also argued in 2015 that it was more than just fun – or that “fun” itself can give back in great ways:

Here were a bunch of goofballs writing terrible AppleSoft BASIC code like me, but doing it for a living – and clearly having fun in the process. Apparently, the best way to create fun programs for users is to make sure you had fun writing them in the first place.

But more than that, they taught me how much more fun it was to learn by playing with an interactive, dynamic program instead of passively reading about concepts in a book. […]

One of the programs on these Beagle Bros floppies, and I can’t for the life of me remember which one, or in what context this happened, printed the following on the screen: “One day, all books will be interactive and animated.”

I thought, wow. That’s it. That’s what these floppies were trying to be! Interactive, animated textbooks that taught you about programming and the Apple II! Incredible.

Steven Frank, the co-founder of Panic, wrote this in 1999, with similar themes:

You never knew exactly what you were going to get. I remember one program listing printed on the side of a bird that, when run, produced a series of wild chirping noises from the Apple’s speaker. And this was from a program that was only five to ten lines long. As a neophyte BASIC programmer myself, I was stunned and amazed. How could you make something this cool with this small amount of code? […]

Beagle Bros’ tools were fantastic. They literally let you do the (allegedly) impossible, like change the names of operating system commands. And they always packed the disks full with extra stuff. Demos of their other products, and strange graphics hacks that existed for no reason other than the fact that they were cool, and because there was spare room on the disk. Beagle Bros. had a lot to do with why I ever wanted to learn programming in the first place. […]

I’ll never forget the book. […] The book was a huge compilation of all around interesting stuff. Weird Apple II tricks that were pointless, but endlessly fascinating. Like the fact that there were extra offscreen pixels of lo-res graphics memory that you could write to, that never got displayed. Or how to put “impossible” inverted or flashing characters into your disk directory listing. Or how to modify system error messages. Not very useful, but really fun to know and really, really cool to mess with. My dad was convinced I was going to somehow break the computer with all this hacking, but a simple reboot always fixed everything.

(I swear I did think of Panic above as a spiritual successor to Beagle Bros without knowing that their work literally inspired one of the Panic’s founders!)

Frank’s essay provoked more emails, and this excerpt caught my attention:

The subtlety: They had utilities which would produced formatted Basic listings and they would give example output of these utlities in their ads and catalogs. It was quite a while before I realized that most of those examples were not program excerpts, but complete programs which of course contained the Beagle Bros signature weirdness. And then there were the seemingly innocent hex dumps. My favorite was from the cover of one of their catalogs, which had a classic picture of this fellow sitting in a chair. On the floor next to him is a handbag with a piece of tractor paper sticking out. On the paper is a hex dump: 48 45 4C 50 21 20 and so on, which are ASCII codes that spell out the message: “HELP! GET ME OUT! I’M TRAPPED IN HERE!----SOPHIE”

Toward the end of the prolific 1980s, Beagle Beos tried to strike it big by making an integrated office suite:

After the work the company had done on AppleWorks 3.0, Simonsen felt ready to jump into the Macintosh market with a “Mac AppleWorks” of their own – they called it Beagle Works. Unfortunately, other companies – giants in the Mac market such as Microsoft, Claris, and Symantec – had the same idea. Their resources were far greater than Beagle Bros had imagined, and the race was costly.

The gamble killed the company. It’s likely that the changing software market would anyway.

But the years before seem to still inspire some people. Check out the Beagle Bros Repository – the homepage is a bit confusing (I think it prominently shows last-updated or last-added things for some reason?), but just use the nav at the top. Maybe it will inspire you, too.

A really interesting 28-minute video by daivuk about making a first-person shooter game QUOD that fit in just 64 kilobytes:

I found watching it strangely enthralling and even nerve racking. The creator keeps adding stuff that seemingly has no chance of fitting into such a small space – textures! sounds effects! music! his own language! – and somehow finds a way to squeeze them all in.

This is inspiring, but also practically useful: even though you and I are maybe never likely to need such high optimization, some of these techniques alone could be useful in some tight quarters like a load-bearing CSS file, or embedded software.

As an example, the author wrote his own “music tracker,” which is a clever way to reduce the weight of music: instead of the tune being one big audio file, only the instruments are sampled, and then arranged in repeating patterns.

Except in his case, there were no instruments… just audio effects already existing in the game. And audio effects themselves were generated in a similar way, by combining smaller waves and effects.

The same was done for textures: the creator wrote a bespoke text editor that saves each texture as smaller pieces and combination instructions – a sort of a “PDF” of a texture rather than a more costly scan of the printed page – and re-generates it on entry.

Lastly, this debug view of “cost” was really interesting. (Good debug views, in my opinion, are generally underrated.)

Palette cycling is an interesting technique borne out of limitations of old graphic cards. Today, any pixel can have any color it wants. In the 1970s and 1980s, you were limited to just a few fixed colors: as few as 2 for monochrome displays, or 4, or 8, or – if you were lucky – 16. Some of those fixed palettes, like CGA’s, became iconic:

But there was an interesting hybrid period in between then and now where you still were only allowed 4 or 8 or 16 or 256 color choices in total, but you could assign any of these at will from a much bigger palette.

So, as an example, each one of these three is made out of 16 colors, but each one is 16 different colors:

Moving pixels was slow. But palette swaps were so fast and easy, that it led to a technique known as palette cycling. This is probably the best-known example, from an Atari ST program called NEOchrome.

Despite so much apparent movement, no pixels are changing location, as that’d be prohibitively slow in 1985. Only the palette is changing. If you watch the same animation with the UI visible, you can clearly see which colors are “static,” and which are moving around:

But this was 1985, so why I am mentioning it 40 years later?

I like looking at old computers for a few reasons. Some of these seeminly-ancient techniques are inspiring and remind me that the limitations are often in the eye of the beholder. Seeing someone really good pushing a platform to its limits is just a good thing to load into your neurons – this could be you next time! And, believe it or not, some tips and tricks can still be relevant.

For example, this is a 9-minute video by Steffest from just earlier this year that walks through a modern attempt to make a palette cycling animation, including starting on an iPad:

The end result goes much harder than I expected. It was interesting to see again the technique of dithering to simulate transparency (we’ve seen it before, but this one is more advanced). But what particularly stood out to me here was the artist making his own little tools to aid in the creative process; I’ve always loved the notion that a computer is really just meant to be an accelerant, making it easy for you to avoid drudgery.