Failing to Use the Computing Lever (2011) | Hacker News Reader

Failing to Use the Computing Lever (2011)

tratt.net

37 pointsinfinite8s34 comments

The article makes some great points.

> Doing tasks manually instead of automatically. Computers excel at the simple, repetitive tasks which humans are terrible at. I remember seeing someone change a document which used the American English idiom of placing a comma after e.g. (i.e. “e.g., X”) to the less stilted British English idiom without the comma (i.e. “e.g. X”). The person editing did the change by scanning the (rather large) document and manually changing each occurrence, a task which took a couple of rather dispiriting hours. Inevitably, in a large document, some occurrences were missed. I fixed the remaining occurrences with 100% accuracy by using the ‘search and replace’ function in my text editor — which took less than 5 seconds.

This is true, but it's an example where the solution is obvious to many people and the answer -RTFM, or more politely "invest in training"- is simple. A different example would have been better. Consider removing a column of information from a text document. You can kludge this using a spreadsheet or you could do repeated search and replace (depending on the data) but this example asks us to think what people should do when their hammer stops being useful.

What should people do? How does someone doing routine office work learn how to use a database instead of a spreadsheet - and what spreadsheet should they use? More importantly, how do they learn what tools are appropriate?

I think the example is apt enough for the situation of "repetitive tasks which humans are terrible".

I agree that additional more complex examples might be interesting, though.

It seems that there's always going to be a sliding scale, depending on how complex the task is. Some software will provide fairly straight-forward mechanisms for performing some tasks (such as find and replace) and some things will end up being potentially more difficult (maybe, say, find and replace with a regex).

In an office setting I think there's a good case here for having someone that's IT/programming/automation savvy working with people to improve their day to day process.

I've actually done that before at my job, in an informal capacity. I occasionally go sit with the folks on the operations side of the business so I can learn more about what they do, and more effectively build things for them, and often times I end up telling them a lot of tricks in excel, or word, or whatever else, that make there job easier. In a few cases I've managed to create quick tools for them that substantially reduce their workload with minimal effort on my part. In a strict cost-benefit analysis, it's probably not worth my time, but it pays a lot in inter-department relations. Of course, my working environment allows for that, but I mostly mean it as an anecdotal example of what I'm talking about. ymmv.

IT departments in most organizations devote themselves almost exclusively to preventing their users from causing inadvertent damage, and not enough time on enabling them to use the tools provided. Most IT organizations would benefit from sending staff out to work with users, see how they work and identify ways to help them better wield the laptops and software with which they've been provided, instead of hiding behind ticket systems.

Thats a great idea. I worked in IT for a few years and in any company above a certain size there is a sort of balkanization. Each department will just want to claim that any issue is "not our fault. We've performed perfectly!" Rather then everyone working together towards a common goal. The IT staff certainly have knowledge and understanding of the system they maintain + general computer use knowledge that comes from doing 'computery' tasks all day. By seeing how the users operate and sharing the appropriate techniques the users could get a productivity and wellbeing boost and the IT department might end up with less tickets and silly questions from clueless users.

In my experience in IT, as you are going from place to place in the office people would try to 'grab' you to help with something. I always acquiesced to this and would always see if I could share any techniques that would help the user in general based on the workflow I was seeing.

Yeah, I agree. This wouldn't work in most companies because that's just not the culture, but like you said, I think there's definite value in it.

You also have to deal with people perceiving your optimizations as a threat to their job security.

I see it as a form of process improvement, but instead of analyzing inter-employee/department processes, you're analyzing the processes and individual goes through.

Ticketing systems are a pain in the ass. I get the point of them, and I think they can be really valuable, but they so quickly become bureaucracy for the sake of bureaucracy.

My team is pretty free to decide how we do things right now, and we're considering adopting some form of issue tracking so we can get a better idea internally what's going on, but we're wary of it becoming ticket hell. More than likely the ticket will only ever be referenced inside the team and we'll just try to use it as a way to make sure we're collectively not losing track of things.

Some years ago, I looked in on a friend in another department, whom I found stressed out by the tedious job of removing malformed telephone numbers from spreadsheets. I took over her chair, pulled the spreadsheet in to Access, ran a couple of queries, and re-exported. In a couple of minute this did what would have been fifteen minutes or half an hour of work. I then saved the queries, wrote down the steps, and walked her through it again.

We should do more of this stuff, you are correct. The proper question, and maybe after the New Year we can send out a survey asking it, is What tedious and repetitive tasks are getting in the way of your real work?

I would expand on this and make a suggestion to people who write software. Use the computing lever, please. Computers are insanely fast and getting faster. If there is a task that you can perform automatically, do it — don't bother me.

Case in point: almost all OCR software is deeply rooted in the 90's when processing power was a fraction of what it is today. Therefore, you load a scanned book into an OCR program, click "Recognize", the program spends 30 seconds doing its work and happily says "I'm done!", while you are left with 600 errors to correct manually. I'd much rather leave the program running for several hours (overnight!) and get 6 errors to correct manually. There is often a tradeoff that many fail to think of.

We should also consider that needing to type 100 words per minute isn't using a lever either. IDE's have gotten quite good, for example. How about adding voice input? Why can't I simply say 'build', 'run', 'indent line' or 'reformat code'? It also knows the 10 variables that are in scope in a function, so why can't I simply say the variable name that I want to type? Voice recognition should understand that I'm working in camel or snake case.

Of course, I'd like more complicated actions.

'Select line. Wrap in fast for loop'

'rename function'

'Open file x'

This is new for me. How do that? Exist a web service or something similar?

Is it actually the case that the OCR can do that much better given more time?

I think my favorite two examples of getting more out of my computer lever are Sikuli Script and Sublime Text multiple cursors.

Sikuli Script lets me script almost anything that has a visual element/gui. I've been able to automate just about any task that has a gui and is repetitive, in some fashion or another, and at this point I have a backlog of scripts for working with some of the esoteric software I encounter day to day. Definitely worth checking out if you haven't before.

The multiple cursors (which are getting prominent in a lot of text editors) are awesome for small text munging and manipulation. by and large, everything I could do with multiple cursors could have been accomplished with some other tool, such as regex's or whatever else, but the multiple cursors end up being really intuitive and powerful for me. I never have to rethink how they work because they work just like my normal cursor but... with more of them. Combine them with ST2's ability to do a search and place cursors at every found location, and I can get a lot of weird stuff done quickly.

> Combine them with ST2's ability to do a search and place cursors at every found location, and I can get a lot of weird stuff done quickly.

Combine this with excel (use \t and \n in sublime for row and column respectively) and you get really powerful, really fast when it comes to converting information into a useable formats.

I've also made use of excel's data validations to create drop downs in cells for making hundreds of lines of complex config for a rules engine in a few hours. Enter the configuration in excel, export to csv, use a ruby to import csv into a database table via existing orm. (Why not use the UI? The app is too slow.)

I turned what would have been a week long data entry task into an afternoon of copying and pasting out of a another spreadsheet. (Why didn't I used the other spreadsheet? It was in a non-machine readable format. I had to convert the data to the proper format using my knowledge of the system internals.)

I am going to have to waste even more hours this week fixing an excel spreadsheet where the data validation isn't working yet again.

Nice!

Yeah, I've done the excel bit with \n and \t as well. I have a little text-munging javascript app I wrote for splitting and merging things in certain ways.

I also use the excel -> db route a lot, but I'm working with MS SQL Server so I'll just do the data import from excel to db.

I get dirty looks sometimes when I talk about doing things this way, but it's really handy. If I know I'm going to have to do something more than once, I'll usually write a quick script for it, but otherwise, quick ad-hoc text manipulation with ST, excel and the javascript scripts I have is pretty fast and really flexible.

Flexibility is the big thing for me. Often I won't think of every way I really need to manipulate the data right out of the gate, so being able to quickly work through and change things is handy.

Does touch typing versus less than ten finger typing really make a difference if one is programming in a terse language (assembly language, APL, etc.)?

Is touch typing really the only true way to control the computer "lever"? Does that mean an office secretary who touch types uses a more powerful lever than an APL programmer who does not touch type?

If what we are doing with the computer lever is ultimately just manipulating _symbols_ (not long strings of verbose text like this comment), then the question I have is whether entering these these symbols using all ten fingers really makes a difference.

Touch typing is underrated, but certainly, with the requisite knowledge, there is a lot one can do with a computer "lever" without typing more than 30 wpm.

Most decent IDE's or text editors have autocomplete, even the Unix shell has tab complete. Touch typing is overrated.

Try it before you knock it. I took typing class in high school. It was the best leverage class I ever took for my chosen career. I have seen it repeatedly: the colleague that doesn't want to make some change because its going to be too much typing. It creates a potential-energy hump many programmers are not willing to marshall the will to cross. So simple-to-conceive yet hard-to-type things don't get done.

Yeah, touch typing can come in handy. Hopefully someday soon we will create a lever and we won't have to do computer input the hard way.

I imagine one day telling the grandkids "In my day, we had to press down on switches to talk to the computer. There was this board with 96 switches, and you put both hands on it and pushed them as fast as you could. I was pretty good at it!" and they willlaugh and say "Grandpa, stop kidding around, that's ridiculous!"

I have a set of Dorvak stickers on my keyboard (I read it was easier to learn, and easier on your hands). I can touch type with that layout, but its just so much slower, and I find I am too busy concentrating on the typing, so its difficult to think about code.

The typing class consisted of drills in common phrases, 30 iterations of a phrase at a time. It takes time. But its only once per lifetime; then you have it.

FWIW, I regularly type without my pinkies (the left sees most use for Shift/Ctrl and some words with a/z) and can hit 110-140wpm for bursts, with 85-90wpm easily achievable for extended periods of time. I used to only be able to type about 55-60wpm in my high school typing class, but the thing that primarily sped me up over the years was learning piano.

I'm sure practicing proper touch typing (or switching to Dvorak) would speed things up even further, but there's always the option of diversifying finger acrobatics into music.

It may not make much difference in laying down the actual code, but it is still a valuable skill for the coder to acquire. If you can touch type you're more likely to write useful comments, documentation, and notes. I suspect the subconscious barrier to writing these small but essential bits of prose is larger in the non-typist. You'll write better commit messages, and will be more likely to turn your notes into online articles to share your code and ideas.

Yes, and autocomplete won't help on this.

I would also argue that the touch typist is more likely to come up with names like rowIdx (row_idx), colIdx, rowLimit, colLimit, findMatchingRow(), rather than (always punting to) names like i, j, m, n, scan().

This is a great, often-overlooked insight: when there is considerable friction in doing something, you will often not only be slower, but you will do something in a decidedly counterproductive fashion.

So it's not always accurate to use the XKCD comic Is It Worth the Time? (http://xkcd.com/1205/) as a metric...efficiency can't always be measured in seconds/minutes shaved * number of times action is performed...because when it's easy to do something, it's easy to explore...and also, it's easy to follow best practices.

Of course, the other side of it is...even if something does result in a large number of minutes/seconds shaved, you have to consider the opportunity cost of you spending your time implementing an automated system...and at certain early stages in a startup lifecycle, that premature optimization time can be fatal.

Just extrapolating: that highly abstract symbolic language/keyboard, combined with an agile mind (think 'Limitless' the movie) and 10-finger virtuosity, would be an incredible coding force...

Not entirely unrealistic, I might add.

I generally adore Tratt's posts and wholeheartedly agree with them but I can't do so with this one. Most computer professionals I know err on the side of automating even things that pretty obviously should not be automated. And every last one has a big bag of tricks and tools for automating things. I also can't think of any programmer I know who doesn't know at least two or three languages – and many are veritable polyglots, to the point that it can become problematic. I'm not sure who this post is talking about by it does not seem like anyone I know (who knows how to program).

Some of the problems in the list are deep seated and well deserved mistrust of the computer. For example the cut and paste metaphor is broken with the combination of that page and firefox, I can cut and paste the text below but I'm not permitted to cut and paste the number. Why? Someone concerned about usability or maybe screen readers would implement his ordered list as pure text, with an explicit "5. whatever" even though that means a little manual rework for inserts and deletes. Then again, its necessary because ordered HTML lists don't work with cut and paste. Don't believe me? Try it under the latest firefox it won't work. What a POS. You can see why this makes people do work the manual way, the way that at least currently is consistent. (edited to add I'm going to call this the principle of least surprise)

"Not searching for help."

And now for something completely different, I've often wondered if this is a stereotypical introvert vs extrovert thing. Google as "the coworker" for introverts. Meanwhile people who are recharged rather than tired out by interpersonal drama love to walk over and bug people "whats the regex backslash for non-whiteSpace, again?" because it recharges them. All the "google is really fast" is never going to have a negative influence compared to "hurray, I get to go socialize now".

I must remember how one of the colleagues handled that interpersonal drama thing. For the first time someone asks him something (say that regex question), he happily answers and shows why the answer is what it is. But if someone asks him that same question for the second time couple of days later, he says "that'll be $5". In just a couple of weeks number of people who comes to him for the second time drastically reduced :)

This is a good way to express the advantages of an CLI over most common uses of a GUI. A CLI is a way to tell the computer what to do; usually when you are using a GUI you are working for the computer. For example, say you have a directory full of images with white borders that you need to remove. Most people who've never really been educated in how to make a computer work for them will fire up something like Photoshop and open each image in turn, manually selecting the borders, deleting them, and saving the result. They will be mousing and clicking for hours. Other people will type in an Imagemagick command, go get a cup of coffee, and come back to find the work has been done for them by their computer. The command line is a big lever.

People who have learnt how to make Photoshop work will build a PS macro and fire off a batch process. It's not a GUI vs CLI issue, it's an issue with knowing more than just the simplest, shallowest face of your tools.

Some talk about leveraging unix www.confreaks.com/videos/615-cascadiaruby2011-the-unix-chainsaw (yes, same speaker as wat)

(2011)

Thanks, but it's not like people have suddenly stopped manually performing totally repetitive tasks on a computer since 2011, so it's still relevant today. :)

Reply on news.ycombinator.com