when programmers get it right (…the first time)

chances are, im going to say a number of things that that author of the blog entry im critiquing will readily agree with. either way, there are so many things you could say about it.

if this sounds like a defense of programmers, or bugs, its far from it. but lets start with this tagline from the blog itself:

Technology should work for you. No excuses!

the core of my complaint is part of the reason i cant stand most peoples “solutions” in the first place– and there are millions of people living in similar circumstances. we (such people) have sufficient understanding of the underlying “thing” that– while most of us are far from the scientists a casual observer may have us pegged for– we can moan about the shortcomings of our tools and sometimes even fix them!

therefore, this is not just a critique for its own sake. but lets get to a quote of yesterdays entry itself:

Technology makes our lives better to the extent we don’t have to think about it.

well, sure. i mean if i had to write a pdf viewer (or drive to the library) every time i wanted to read a book, i would probably read fewer pdfs, or books. its easy to dismiss this as laziness, but the bottom line is: putting such things into our periphery lets us pay attention to other, hopefully more important things. thats productivity in a nutshell, and a lot of things designed for that purpose have the opposite effect. they turn us into this poor guy, focused on the direct drudgery of the thing itself:


by the way, apple (i mean xerox) pioneered that, and its called a direct manipulation interface: https://en.wikipedia.org/wiki/Direct_manipulation_interface (sorry, a little mild cynicism there.)

the blog author, “cxwinnectaland” is actually talking about the example of a pdf viewer they use on a regular basis:

“For the last two years, I have been using Google Chrome to view PDFs at work.  Dozens a day, usually with at least five open at a time.  For the last two years, every time I have rotated the view clockwise or counterclockwise, my page has shifted off-screen and I have had to scroll to get back to it.”

whats funny is that this blog starts about talking about how technology is best when we dont have to think about it– i would counter-argue that technology is best when it lets us put the thought of it aside most of the time– thats a little bit different. because when you choose a tool, you might choose it based on first impressions…

“oh, this is easy to use and fairly good looking…” (a reasonable impression)

“oh, suddenly a common task is easier! im being productive!” (building a preference)

later on:

“hey, its being stupid! im just going to square-peg this into my workflow!”

the point is, this blogger is talking about how great it is that they finally fixed the little annoying “doo-dad” where to make the everyday viewer work properly, the tool has distracted the user with an anti-feature/tedious need for a kludge/workaround. i sort of agree– fixing those things can make a world of difference.

but how about all the steps that made the user more likely to be helpless:

  • so many pdfs, when text and html exist and are better for viewing… with everyone using the wrong tool for the job, the user is expected to also.
  • a pdf viewer that isnt even a pdf viewer, meaning that fixing a small bug is a low priority (and introducing one is easy for the same reason: its not even a vital feature.)
  • countless layers of abstraction/absurdity: graphics layers implemented in the web browser, to show a vectorized implementation of simulated paper designed for printing, instead of an interface designed for simple text and graphics– which is actually what the web browser was before they bolted on the pdf viewer!

if someone just made a good pdf viewer, then it would be a top priority when it had a display bug. instead, we are bolting everything onto the browser like a swiss-army knife.

i appreciate that in computing, sometimes the swiss-army knife model isnt like its namesake: all the little parts arent inferior to the “full-size” stand-alone versions. i mean the way we make “stand-alone” devices is to take a general-purpose machine and hobble it until it can only do one thing. im certainly not in favor of that.

and lets not forget that the whole reason we know about the swiss-army knife is that sometimes its handy when a browser (or gadget) can do everything. im using it to write this instead of a word processor; dont think im unaware that this ancient laptop would perform a lot more nicely with libreoffice than this cloud-like thingy that wordpress has me typing in.

in some cases, i would use something else.

but thats my whole point here!

not thinking about technology actually is what most people do– and it is the true source of so much cost– using a crappy tool (or a good tool with crappy side effects) when there are countless other tools out there that work better, or are designed to do a job well– if the user accepts no responsibility for tool selection (and even has a choice, but simply doesnt bother) then not thinking about technology is the problem, and thinking about it is the solution.

while it is good for developers to fix these things, it couldve been fixed sooner by the user, or by a society that didnt decide that making a frozen, simulated printout into something dynamic was better than simply making a document that is itself dynamic– even in an application already designed around the latter idea.

we do so many bizarre, overcomplicated things because we dont think about how much nonsense we pile atop nonsense, its a complete wonder that devs can still fix anything.

but thats the magic of computing. if instead of reading text from a screen, youd rather read text from a window running in a compositor over a gui that shows a smooth scrolling portion of a document that is simulated using fourier transform algorithms to create an approximation of a actual printed document with margins and custom fonts that you may not like, so it gets loaded into a pdf library that reformats the page after extracting the text from the digital file that is more than a few orders of magnitude larger than a simple text file would be with a one line note as to what font should be used–

you can do all that, and you can put the developers through that level of absurdity. and to an extent, its really their fault for catering to such a sprawling design. i mean its fun to go overboard sometimes– we know, because we have fun using tools that way.

the thing is though, if you ever stepped back from the details that pop out of everyday use– “no excuses?” how about “youre doing it to yourself?” thats not an excuse, its a fact of life sometimes.

many years ago, plato said: “the unexamined life is not worth living.” somewhat more recently, arthur c. clarke said: “any sufficiently advanced technology is indistinguishable from magic.

i will bite off these to say: “the unexamined workflow will become indistinguishable from a horrifying pile of workarounds.” ok, so its not catchy.

real life is messy: but if you find yourself pooping where you drink, and you already have working sinks and toilets but youve simply decided to “change your workflow” in how you utilize them, maybe its time to stand back and think about your technology.

a lot of your gripes come from too many workarounds, and not enough thought about where the real problems are coming from.

this blog entry is part of a philosophical series where “computer types” talk about the world and everything wrong with humanity– i mean, users– i mean, computing. a favorite author of such pieces is andy mender, who wrote the most recent example (also this, this and this) that i can think of. cheers, andy. and devwrench: sorry for jumping all over it! its either a difference in personal philosophy, or i simply read it a lot differently than it was intended. hopefully a good point or two came out of the whole thing.

and to the user: i defend, even champion your right and room to do what works for you– but the odds of that happening are more likely if you have to consider the results and even some of the actual causes, now and again. youre not more likely to find the best tool for you if you always trust people selling one-size-fits-all.


  • this work is in the public domain.
  • …that probably even includes the picture.
  • …got it from here and edited it myself.



2 thoughts on “when programmers get it right (…the first time)

  1. Thanks for reading and responding! Sorry I haven’t had a chance to continue the conversation yet, but I am looking forward to doing so. At the moment, my first crack at a better way involves pdf2txt, xmlstarlet, GNU Octave, and some Python I have yet to write. 🙂 More to come.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s