> We didn’t use graph paper for the art work. Maybe be very first artists did, but not any I know.

I mean, whether or not pixel-paint software exists, graph paper, even today, is still great for sketching and ideating pixel art [and/or level designs, but I'll just say "pixel art" from here on.] If you try to come up with a design for a 8x8 or 16x16 sprite or icon by freehand sketching it, you'll probably come up with something that won't look legible at that size. Better if you have the constraints of the grid even in your sketchbook; and so, better if your sketchbook is graph paper. (In fact, I believe they've make special-purpose graph-paper sketchbooks for forever now, specifically for ideating cross-stitch and latch-hook art.)

We're really only just barely out of the era of ideating pixel art using physical media, with the advent in the last ten years of cheap tablets that can run pixel-painting software, that are light and convenient enough that an artist would prefer to lug them around in place of their sketchbook.

Of course, after the ideation process—once you've got a draft you like—you'd likely be using some kind of software (visual or not) to input it. Scanner tech, and downsampling algorithms, were both far too crap back then to rely on faithful digitization of "discrete" information like pixel-art pixels. (Unless you were using a special scanner, special software, and special constraints on your inking process. Remember Scantron sheets? A 1980s pixel-art scanner would require basically the same fraught workflow.)

But also, on the other side of the urban-legend scale (that the article thankfully doesn't repeat), no artist was ever having to do bit math to get packed words to type into a resource file. Programmers may have done that for first tests with crappy programmer-art, but even back then, comparative advantage was a thing, and any artists on a project weren't hired to be good at calculating on long strings of numbers.

Instead, from the very beginning of computers being hooked up to displays and having character/tile display modes with configurable character/tile memory, there were already "textual graphics" formats like NetPBM, where you could use a visual editor like DOS edit or Unix vi as your "pixel art editor." These files can then be compiled, resulting in the a C or ASM source file defining some constant as a uint8-array literal. (They weren't necessarily standardized; but it was very easy to reinvent these formats and their tooling, and many companies did in the process of producing early game software.)

There was pixel-paint software too, even in the early 80s... but it wasn't on every platform. And, since you were often stuck on the platform you were targeting, that was a problem. (You were fine when targeting closed platforms like the gameboy, because the SDK would usually be built for a workstation-class system; but when targeting your average 8-bit micro, this was often the case, and 8-bit micros had no niceties like "standardized floppy disk formats" or "networking standards" to transfer in data from your nice graphics workstation. If you want to write e.g. ZX Spectrum software, you write it on a ZX Spectrum—or one of its younger brothers, once those came out.)

But, no matter the platform, if it was display-oriented, you could pretty reliably get a visual text editor. (Even on the ZX Spectrum!) So writing textual "1"s and "0"s into text files was indeed a thing—for a while, at least.