
User Culture Versus Programmer Culture - slyall
http://pgbovine.net/two-cultures-of-computing.htm?dsffs
======
calhoun137
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.

~~~
michaelt
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.

------
chubot
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.

------
ef4
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_.

~~~
pgbovine
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.

------
billyjobob
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.

~~~
trustfundbaby
> 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

~~~
griffordson
>> 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?

------
xradionut
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.

------
angersock
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. :)

------
jbrooksuk
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.

~~~
pgbovine
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 :)

~~~
jbrooksuk
> have you seen the output of make?

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

------
ericgj
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](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

------
craigvn
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.

------
Chromozon
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.

~~~
asveikau
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.

~~~
Crito
You could publish a book without the use of bold, italics, underlining,
indentation... hell, even spaces
([http://en.wikipedia.org/wiki/Scriptio_continua](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](https://news.ycombinator.com/item?id=6750761)

~~~
asveikau
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.

~~~
Crito
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...

~~~
stan_rogers
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).

------
golergka
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.

~~~
pgbovine
_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.

------
ACow_Adonis
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.

~~~
Crito
> _" 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.

~~~
ACow_Adonis
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...

------
pjmlp
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.

------
chacham15
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.

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

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

~~~
Crito
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?

~~~
freudien
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.

------
walshemj
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.

~~~
pgbovine
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!

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

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

~~~
beothorn
Why?

~~~
delian66
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.

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

