Oh, yeah, those were the days?
No, the 1990s weren’t better. We devs weren’t better, the users weren’t better, and, hell, payment wasn’t better.
In fact, one of the pains in the late 90s was to overcome all those things that “just weren’t good enough”. Funny, that’s why it was a good thing. Because, users – the people that created products that paid their and our salaries, were glad and grateful for any help that would ease their pain with the tools they had to use. Tools were introduced by “higher ups” with the reasoning, that “by simply implementing these tools in our workflows, we are more productive”. It never mattered whether that assumption had anything to do with reality, probably because, it hadn’t. New shiny tools were expensive, and expensive, by definition, meant: good.
Among other disciplines like “surviving meetings with no finger food”, “telling higher ups that the latest tool was even more good than the previous most good tool had been”, our “dev job” was to learn how to hack the latest tool. PR was: no tool, no good. Reality was: use the tool but find a workaround that made it work.
So why does it feel, at least to some of the elders of us, like the 90s were “better” than today’s un-out-shinable tools (new tools arriving daily instead of monthly these days!)?
A couple of reasons and one story (mine): Well, we ARE OLD. Back in the days we could run up 6 floors and not even pant louder than we would do when we attended a meeting WITH finger food. We looked better (ok, some of us improved instead of decayed – but that’s a different story). We WERE wizards, we did understand the tools, even the latest ones, we could hack our way. And, believe it or not, pizza was better, too. In hindsight, what feels like “better” oftentimes has more to do with “we tend to forget what was not good” than with “we remember it all bit by bit 100% accurately”.
My story. Well, micro crumbs of it
I have worked in a variety of industries: publishing houses, agencies, film-/photo-/audio-studios, software houses. Many companies with in-house-dev were set up some way like this: Any development department had one or more “user facing” devs. People, that “spoke user”. Women or men that understood what the users of tools had to do in order to pay everyone’s income. They would sit down with users and learn their workflows. They would not simply watch out for “what could be automated”, instead, they noted when things felt awkward and when users sighed about “this will take some time now”.
They would FEEL what users felt. And they’d sit with other developers just as well and respond to questions on “how would they expect this button to work” with hands-on “so”.
And then we would have a meeting with users WITHOUT higher ups, because, we wanted to get things done. Nobody wanted to tell someone how great something was. And that’s where the big difference kicks into what I see today: We would, live, in color and stereo, scribble on a projected blank page the current workflow. We would scribble in, discussing live with users, what should look different. We would set a click-action to a scribbled button that leads to another, scribbled and smiley-garmented, “there’ll be dragons” user dialog. Within one or two hours we would have a “working” click-through workflow that held the state-of-the-is along with the state-of-fantasy and the desired state-of-be-done-faster. No “let me prompt”, which just adds layers of layers on top of something that, often, was as simple as commenting out an unnecessary user-prompt (see what I did there?).
Breaking the flow of dwelling in good ol’ times: Now, I see it every day, prompting has turned into a self-satisfying act. “I’ll interpret what I understood from the one that talked to someone who knows a user. I’ll try to translate what I halfway got into something that the AI doesn’t reject right away as BS. And I’m happy if I get anything out that does something when I click. Even if it’s just printing ERR to stderr, that’s at least something I can copy and paste into the next prompt.” If that is “developing helpful things for users”, I missed the train.
It wasn’t all “rapid prototyping” – we weren’t “prototyping” all of the time. Sure, we were, when it made sense. Yet, often we would solve the pains with the users, we would create work-arounds (be it around new tools or be it around old tools that never really did what they pretended to do). Getting things to work, because, delivering something that LOOKED like it might work but failed in real use cases was way worse than hacking a work-around that got the job done.
That was a world-view. That was what separated companies that made money from investment graveyards.
Some of us were used to making good money for prototyping week after week and getting their pats from higher-ups exclusively. They’re probably more than happy today. Some of us would get out of their caves with brilliant solutions to problems nobody felt they had, which feels like a meme: “vibe code me a game everybody wants to pay $100 for and wake me up when it’s done” – that’s the last we ever heard from that “dev”, she’s still snoring. And then, some of us would enjoy seeing users clicking a button that, until that moment, had done nothing but occasionally crash the software, suddenly did something meaningful and it looked JUST THE WAY THEY WANTED IT.
Happy users.
So what?
Are there happy users today? I bet there are!
It is our job to serve the user, all things considered. If that, for good measure, requires AI: Use AI. Just don’t pretend that AI can bridge the gap between the everyday-survival-knowledge of actual users and developers whose role it is to help them. To me, a job done good is a job done that makes users happy (which includes measurable productivity, not “defined by the price of the tool productivity”). “Burning tokens” in no way reads as “productive”, or does it. The more users see their understanding of workflows being appreciated, their expertise been put to practice IN THE TOOLS they are required to use, the more they see their expected outcome of a button click, the happier they are.
The more we waste our time discussing our limited understanding of what the user wants with an omni-ignorant artificial “SOTA tool”, the less time we have making this crazy world a tiny bit more shiny for everyone.
Thank you for staying with me this far. That's the 90s - I have written way more about the 80s, but that's a different tale :-)
Top comments (0)