User Culture Versus Programmer Culture | Hacker News Reader

User Culture Versus Programmer Culture

pgbovine.net

57 pointsslyall49 comments

I find a decent amount of fault with this article, but it's not all bad. It starts off with a really cool premise and then goes on to equate "programmer culture" with using the command line. I think the author is spot on when he describes how user's think about software/apps, but obviously the command line is not the be all and end all of how programmers think about software, it's just (a very important) one of many tools.

One group of people have no idea what programming is, the other group do. It's not that complicated. There is no user/programmer culture divide, it's simply a matter of understanding a complex topic or not.

I think a lot of "programmers" use apps and other software like "users", but when something goes wrong we like to hunt down the solution and fix it, and I think that explains why it is not uncommon to hear programmers complaining about how stupid the people who wrote the software they use everyday must be; because it can be frustrating and annoying when it ends up being something really obscure.

Programmers have a better understanding of how software works, but just like everyone else we get frustrated and annoyed when our app's crash. We can complain in more elaborate and accurate ways than the average person is all.

The command line is just an example of the division you may see between university academic departments and business areas in a large company.

What the writer calls "programmer culture" may well involve running Linux. Then using OpenOffice or Google Docs or LaTeX instead of Word and Excel leading to messed up formatting any time documents are passed back and forth. Maybe sending presentations around as PDFs - which Windows users can't edit. Can I, a Linux-using programmer, understand why you'd want to connect a spreadsheet to a database? It boggles the mind. No, don't bother to send it to me, I can't open excel files. And in the opposite direction, us Linux users will happily recommend software that works great for us, and which is notionally cross-platform, but on other platforms the user experience is much worse. And that's just for technology which has barely changed since Office 95. God forbid if you want to embed a video into a presentation and have it play on several platforms.

I've seen a similar schism within the programming community. Web culture is of course closely related to Unix culture. The web is really an outgrowth of Unix.

At places like Google, and other web companies, the Unix shell and emacs/vim reign supreme. Most people on HN work at web companies.

I used to work in the game industry, and have referred several coworkers to Google. Invariably they are shocked that people still use emacs and vim, and find / xargs. They are visual people and prefer IDEs. The command line just seems primitive and unproductive. A lot of people with a Java background have a similar reaction. And no, it's not related to the quality of programmer, since James Gosling (who wrote the original emacs I think) had the same reaction to google's tool chain.

I think programmers can roughly be divided into "language people" or "visual people". That is probably true of non-programmers as well. I have taught programming using the terminal and vim at Google, a web company, but I realize that in a different setting, this would be the wrong toolset.

Interestingly, I would expect Unix / verbal culture to be most relevant to librarians. If you were teaching a bunch of technical artists programming, Unix would be inappropriate and almost certainly a disaster.

While the cultural observations are all true, the class he's using as an example just seems really poorly planned.

It's not hard at all to motivate why programming is different from all those alternatives. The instructors just picked really terrible examples.

You can keep a room of nonprogrammers at rapt attention for an hour with 30 lines of Processing. Do something cool.

sorry i should've provided context: these classes are meant especially for working professionals -- mostly in academia: librarians, research staff, scientists -- to learn skills to make themselves more productive at work. 30 lines of Processing is cool, but won't make them more productive in grepping through gigabytes of ill-formed archival data files, organizing and visualizing them, and making reports for their bosses.

This article confuses teaching Unix with teaching programming. They are separate subjects. It used to be a prerequisite to teach Unix first because most programming tools were command line, but I'm not sure whether this is still true. I spend far less time in the shell than I did 15 years ago because the GUI tools are now so good. To use the example from the article, back then I would have used the find command because it was the best way, but now like his users I would just use Spotlight. I think memorising command parameters and key sequences has become a badge of honor because it is difficult but the command line is no longer the most efficient way of doing everything.

> This article confuses teaching Unix with teaching programming

I don't think thats true, he references programming in python in there, but he uses the tools programmers generally use (on unix based systems) to program to more sharply contrast it with what the user might expect based on software that they use

> but the command line is no longer the most efficient way of doing everything

I agree with you, but the fact that most of the most gifted programmers I know usually gravitate towards some truly esoteric tools because of the complete control it affords them, negatively (sadly) impacts the rest of the programmers that look up to them

>> but the command line is no longer the most efficient way of doing everything

> I agree with you, but the fact that most of the most gifted programmers I know usually gravitate towards some truly esoteric tools because of the complete control it affords them, negatively (sadly) impacts the rest of the programmers that look up to them

I spent years programming with Visual Studio and other IDEs that preceded it. I now work exclusively with "command line" tools because I can't physically use a mouse as my primary input device. I also use Linux now since it isn't possible to navigate OSX as efficiently as I can navigate using xmonad, tmux, and Vim on Linux.

It isn't an exaggeration to say that I owe my career, and my business, to the gifted programmers who maintained and improved the tools that I depend on now over the last several decades.

Is it possible the command line is the most efficient way of doing things and you just haven't discovered that yet?

I have worked with a very large number of programmers of wildly different skills and technical cultures, and never once have I seen someone harming themselves by trying to overuse a shell. It has always been the reverse: people wasting hours and days doing things that should be automated by two lines of bash scripting.

Similarly, the grandparent comment's speculation that it's just a "badge of honor because it's harder" just sounds silly. Maybe if you're 14 and you're trying to convince another ignorant kid that you're 733t.

The thing about all these powerful, "esoteric" tools is that the steep learning curve doesn't matter at all across a lifetime career. The investment pays off in spades.

I agree that often guis can do things more efficiently. CLI's shine when you need to do unusual, compound tasks. Suppose you want to get the third line out of every file on the form log*.txt. Quite easy in CLI, but impossible with a gui. Of course, you can outsource writing the "incantation" to some grunt, but what you cannot outsource is the knowledge that it should be done with a CLI / script.

I think the author misses the point. Most users I interact with do not want to learn anything slightly challenging. They either want a magic button to do everything or they want you to do their job. God forbid they read any documentation, watch a quick video or even listen to a simple explanation. They don't need to learn how to program or use the command line, they need to give a shit and do their jobs, which might involve a little initiative and effort.

I often teach programming in a community capacity, and I hate hate HATE the "User Culture" that this article points out.

That said, it's absolutely correct, and it gets things done. It makes the users happy, and after a certain point they can pay for better tools or get minions to do the repetitive tasks (scale by hiring more minions, be flexible by hiring smarter minions, etc.)

When teaching you really do need to be careful to take it slow--it's really really easy to jump off into jargon and lose your audience, and people will generally play along to avoid looking stupid. And then they'll never come back.

Communication is the art of projecting your ideas onto someone else's experience, and many first-time programmers don't have anything other than everyday metaphors to rely on. We've gotta be careful with the noobies. :)

I think non-programmers have this vision of The Matrix, Swordfish and all non realistic vision of programming. Swarms of text floating down the screen, whilst you're supposed to be pounding the keyboard and writing lots of numbers and equations.

Whilst it's true, we do look at a block of text, it's not always moving and boring. There is a lot of testing and visual feedback for us. Perhaps they get overwhelmed by the Terminal because they think "Oh god, The Matrix. My eyes." but it's not always like that.

have you seen the output of make? or pdflatex? if anyone walks by your screen while you're compiling anything, it's going to look like The Matrix, especially if you use a dark terminal color scheme :)

> have you seen the output of make?

Yes. That's a good point. Make is awful to read through quickly.

Hey, Philip - thanks for posting this and also the previous write-up of your experiences as a helper in the 'boot camp' (http://pgbovine.net/teaching-librarians-programming.htm). It is very valuable, including the photos. Very nice, multi-generational group - must have been quite a challenge!

But I agree with calhoun137 when he says there is no fundamental user/programmer culture divide. Programmers are users with a deeper understanding and wider toolset. We all want to get stuff done quickly and move on with our lives rather than drown in computer-driven drudge work. So it seems like a course for beginners should start from that common point, and really be focused on (a) uncovering the problems they're already solving by hacking together the tools they know (e.g. getting data into Excel charts, or whatever) and (b) using the inefficiencies in their solutions to motivate learning or building tools with more leverage, etc.

I can't help but think from your description, the student "regular users" are the ones with a pragmatic/hacker approach, using the limited tools they know -- while the instructor "programmers" are the users stuck in religious attachment to their arcane tools. Maybe the course would go better adopting some of that "regular user culture", AKA hacking ;)

I'm sure it was more complicated than that and for one thing I can really empathize with having to deal with massive variety of platforms etc. Might be worth setting up a common VirtualBox image that everyone (students and instructors) use from day 1, to avoid some of that headache?

Anyway, thanks again for the write-up.

Eric

He makes a good point about the difference between users and programmers and how they see software in general. But it seems like the teachers were hopelessly prepared and the subject content poorly put together. I think he also makes some points that are likely incorrect regarding that nature of programmers and their affinity with Unix, probably born out of his bias based on what is popular in Academia.

Please, please, please do not teach programming in a 1960s-era style text editor with one font color. Syntax highlighting exists for a reason- it breaks down code into units that we can easily see and understand. If your code is all one color, new programmers will see it as a bunch of foreign gobbledegook, and it will be harder to single out the differences between functions, variables, includes, etc.

Would you say the same about another field? Please, when you're teaching literature, don't make all of Shakespeare the same color. The students will think it's all a bunch of foreign gobbledegook. It will be harder to sort the nouns from the verbs and it will be total chaos.

I think you underestimate people.

You could publish a book without the use of bold, italics, underlining, indentation... hell, even spaces (http://en.wikipedia.org/wiki/Scriptio_continua)!

But why would you? Emphasis is useful. Syntax coloring is emphasis.

Or as HN user 'trevvvor sarcasticly put it: "Traffic lights should be monotone and drivers should just know what position means what." -- https://news.ycombinator.com/item?id=6750761

OK, so let's consider a spectrum:

* Text being unreadable due to its color.

* Text (in this sense, literature) being unreadable because there are no bold, italics, underlining, indentation.

* Text being unreadable due to no spaces at all.

Would you at least agree that two of these sound a bit like whining in comparison to the third?

Perhaps I'm biased due to my own color blindness, but to me a piece of code without color is pretty much the same, or perhaps even better than the alternative, as I've found the colors and bold can actually make things harder to read. (In particular I've often glossed over comments because some "helpful" text editor made them colorful and less legible.) I thought it was also a clear-cut analogy, though apparently not universal around these parts, that most prose usually tends to read just fine without that emphasis you speak of.

Most of all I was bothered by this careless disparagement of anyone who would dream of seeing text in one color as "1960s" -- as if that means anything.

Few points here:

> Text being unreadable due to no spaces at all."

Text without spaces is readable. Text with spaces is more readable. Readability is a continuum. Literature is certainly readable without bold, italics, underlining, and indentation.

Colored text, for people with normal vision, remains clear. Clarity is not lost, another channel for transmitting information to the user is added.

We don't use color highlighting in books, but perhaps we should. I haven't tried it, so I cannot say it would not be better. I have heard it suggested that coloring lines of dialog would make literature easier to read. I think it is very plausible that Shakespeare in particular could be made more accessible with the use of color. With the rise of ebooks, this sort of experimentation is now feasible and I think that it is likely that we will see people experimenting with this sort of thing as the new capabilities that ebook devices provide give us an opportunity to revisit some traditions that were originally set in place by material constraint.

And lastly, code is not read as literature typically is. Most literature is written with linearity in mind. Most code is written under the assumption that the reader will jump up and down it repetitively, frequently jumping to random locations in the file. Coloring code therefore becomes useful in much the same way that coloring road atlases are useful. You don't need to trace a road back to the nearest label to find out that it is an interstate; you can tell right away because it is blue. That big area inside of that squiggly line? It's a state park, you can tell because it is slightly green, so you don't need to look around on either side for the dotted line surrounding it. That green area in the middle? That's a comment, you can tell without scanning your eyes to either side looking for comment characters...

Rubrication used to be a normal thing. It was just harder to do economically for a very long time; there's no reason why we shouldn't do it now for general publications (at least in hardcover and electronic editions).

One difference is that many professional programmers use syntax highlighting when working, but I don't think many professional English literature scholars colour the words in Shakespeare.

Teaching Shakespeare should only happen with students who are already literate. This discussion is about people who are learning to read.

Perhaps programming should be taught with smaller programs, if it requires syntax highlighting to "[break]down code into units".

(Personally, I hate syntax highlighting because it looks like "like a clown vomited all over the page"; I find it incredibly distracting, especially when different colours have different contrasts against the background. The only time I find it a little useful is to match opening parentheses with their closing ones, and even there I prefer shades of grey to colour.)

(i should add that as a parenthetical in the article)

this is exactly what a newbie would see if they opened up a built-in text editor on, say, their mac. something similar would happen for windows. (same goes for lack of fancy terminal customizations.)

getting a syntax-highlighting editor is an extra installation step that can take hours to set up and explain in a class, due to people's different environmental setups. e.g., someone has some obscure virus checker installed that prevents gVim or Emacs or Sublime Text or whatever from installing, or crashes on startup.

edit: also, it's putting lipstick on a porcine. the code examples i've shown will be equally cryptic to a beginner even with syntax highlighting.

nano supports syntax highlighting, so that's not necessarily an issue.

I think that the base premise is faulty here. I use shell (fish, specifically), git and sublime text every day. However, I use them for specific purposes.

If you want to show people what's so good about git, put them in situation where renaming files won't cut it. If the task they have at hand can be effectively solved with renaming files and emailing them, then they don't really need git. Another example: excel. It's an excellent tool for data analysis, especially on the first stage; on my bioinformatics course, it was the first, and by far, the most useful tool I've been taught.

put them in situation where renaming files won't cut it

completely agreed, but often the first example you show people needs to be simple enough to grok, not to mention to type. even showing a simple git example takes about an hour to account for typos, environmental mismatches, etc. showing a forking-diff-diffing-fork-merging-rebase-rebasing-merge-pulling-clone-while-solving-two-generals-problem-without-paxos will make people's heads explode. and first impressions often matter, for better or worse.

I say this as humbly as possible. I've taught a few classes to newbies for work, and yes, I'm frustrated with how fast the powers that be expect classes to be taught. But one also has to accept how slowly you have to go to teach new material to newbies. I've gotten unsolicited feedback from students thanking me, and one even sent me an email saying I inspired him to learn more, which was really touching. I've also received the "my god, you do it so fast!" comment. So with all due respect reading that post, that's not a symptom of "two cultures" per se, its a symptom of bad teaching, and a complete miss-match of material/audience.

In what possible universe is presenting to a bunch of librarians unix/grep/git/latex/python considered sane? Were the presenters really that mind-blind?

Half of those things are debate-ably not even programming, and all of them should be separate subjects. There is little/no reason to teach UNIX/regular-expressions/git/latex to someone who is learning to program in python, assuming the course is made up of non-programmers and the goal is to introduce programming. Its going to take them months/years before they're even at a stage where they vaguely have a reason to use those tools rather than the tools at hand, and I'm sorry but most of them are not going to stick with it that long. Do you know how long it takes to get assignment/arrays/loops/functions/variables/types/logic all working together? We're talking YEARS! We all forget about it the same way we forget about how hard it is to speak our native tongues, but you might as well fly into a room of native Japanese people reading shakespeare for the lecture. Non-programmers do not understand "AND" or "OR". And you're worried about unix/collaboration tools when they're going to struggle to write a 10 line program by themselves if they're the gifted ones?

If you want to inspire someone to learn to program (and I'm on the fence as to whether its really possible to do so if someone isn't inclined to hack things themselves anyway), then present them a real world task from their work/life they couldn't solve with their current tools. Then you need to show them how to solve it with programming, and only with the amount of programming learn-able (that's how much they can learn, not how much you can present) in the length of the course, so they could do it themselves without you present.

If you cannot do this, either the kind of people who program are likely going to discover such things by themselves, or you're probably wasting your time, because you can bet that they're just going through the motions at their keyboards and their eyes glazed over from the moment you said "statement/expression/function/assignment/Boolean/variable". All your words do not mean anything to normal people!!!

/end rant.

> "In what possible universe is presenting to a bunch of librarians unix/grep/git/latex/python considered sane?"

I could see a case for teaching them latex, if only so that they were familiar with bibtex citations.

I learned recently that my alma mater combined their CS department and their library science department into some sort of conglomerate department. I can't say I agree with that decision (particularly in that case, I perceive it as a continuation of a negative trend in advertising, presentation, and prioritization at that university... but that is a separate topic) but the notion that librarians need computer skills above and beyond what the standard modern professional needs is not unheard of.

I was actually going to say, i can understand a LaTeX course maybe for librarians :P But i do think it should be a separate course, and you need to be able to explain to them why this is a great thing, and in addition to whatever they're doing at the moment. Plus, it needs to be great enough to overcome any network/lock in effects of "but everyone else does it this way"...(and good luck with that...because that's often the reason we do sub-optimal things in programming culture). You've got to do that and replace what they're doing right now, or helps them solve a problem in and of itself that was previously unsolvable.

Its not that I'm against teaching them such things, its just that it has to be in an environment of suitable context, and at a level expected of not only a beginner, but of a beginner who has never done any programming.

And far be it from me to say so, but maybe...just maybe...there's a reason librarians aren't programmers and are using the tools they have available to them. Maybe its the programmers who are in the wrong. I was shocked when i got into the workforce and discovered that everyone was doing all sorts of IT/admin stuff manually, and thought "if only everyone could program, think of all the efficiency gains!". Now, I'm realizing its a bit more complicated than that...

That's exactly the point of these workshops -- to teach librarians, research assistants, scientists, and other sorts of professionals to become more productive via programming. Real-world tasks for them often involve knowing about and manipulating the filesystem (hence command-line craziness), coordination and typesetting (hence Git / LaTeX), and data analysis and visualization (hence Python/JS/d3/etc.). And these folks were motivated to learn to hopefully help their careers. The teachers also had the best possible attitude and patience that I had seen, and yet still there was this schism, which I wrote about.

I have always been a GUI person since the Amiga 500 days.

Yes the CLI might be good for certain tasks, specially automation, but that can also be achieved with scripts in languages like Python/Ruby.

The programmers that insist in a term/vi/emacs world are trapped in a 1970's world, loosing the progress that happend in between.

An answer that I have given to a friend asking the same question is: Imagine you want to build a big building and you are given as many square boxes as you want, how do you build the building? Easy, you stack a bunch of boxes one on another until you get the shape and size you want. But what if you want to have a triangular roof? You're stuck; theres nothing you can do. Therefore, imagine now, that instead of being given square boxes you are given rectangular boxes. Now in order to build the same house that you built before you need to take a bunch of rectangles and put them together to make squares and then do what you did before. Thats soooo much more work. However, now you can build triangles.

This entire situation is like the programming problem that the author describes: specific tools designed for a specific problem will be easier to use to solve that problem. The moment, however, you want to use that tool to solve a problem that it wasnt meant to, you're stuck.

Serious question: Did that metaphor/analogy/whatever actually help your friend? Because I don't get it at all.

I think if you replace "rectangle" with "right-angle triangles", it would help immensely.

I'm still not sure I get it. Maybe 'triangles are more complex, but allow more complex results, like programming languages are more complex than other input languages humans use (like shortcut/mouse-action languages used in GUI programs like Photoshop), but programming languages allow more complex results'? In other words, triangle building block languages are the building-block equivalent of Turing equivalence?

I think the basic premise is:

Programming languages are the building blocks for all tools. When faced with a broken/useless tool, knowing how to build a new one is useful.

Yea, it did. I guess I should have specified non-square rectangles technically, but thats what people usually think of when they hear rectangle. Basically, the more fundamental the building block the more work it takes to build something, but the wider variety of things you can build.

http://en.wikipedia.org/wiki/Rectangle

So this is like complaining if you do a car maintenance course at your local college you have to GASP use spanners and OMG might get some of that nasty dirty oil stuff on your hands.

interesting analogy, but i think the difference is that we intuitively understand what spanners and nasty dirty oil is, since they're physical objects that we see in daily life. so if i take a car maintenance course, i expect to get dirty. all of this magic inside of the computer is invisible. but you do make a good point, and one that i'll try to address in a future revision!

I don't know what kind of masochist would use find as an example of how the command line works.

Please don't pipe the output of find into xargs. Use the -exec flag instead.

Why?

It is slightly more efficient. It also avoids some potential error cases when/if you have files with unexpected characters (for example spaces) in their names.

This guy didn't even bother to name his computer!

Reply on news.ycombinator.com