I've been enjoying this discussion, too--thank you, everyone! I will add just a few more refs... I've found Mary Shaw's work on software engineering as *aspirationally* engineering really fascinating. As she and many others point out, there's always been a lament that we don't have software down as a discipline; it's not like chemical engineering and the knowledge isn't transferring the same way. Will it ever? This was as much a live question in the 1960s as it is now. I saw her give a talk at SPLASH in 2015 where she put up a graph of software engineering consequences of failure on y-axis and degree of oversight on x-axis. It went from nuclear power plant shut down to finding a restaurant. Something like baseball stats have lots of oversight but low consequence; power plants have high oversight and high consequences; restaurant-finding apps have low oversight and also low consequences. I find this balance helpful to think about when we talk about what it means for a tinkerer to learn about computer programming. The vast majority of programming that goes on is low oversight, but also low consequence. End user programming, etc. It is, of course, extremely important for a software engineer tasked with nuclear safety to be cognizant of potential failures of the system. I think the tinkerer-->extreme civilization consequences argument is mostly a straw man one. Except in the case of some high profile tinkerers who, through *other *validation systems, are messing with our civilization: e.g., Elon Musk, Mark Zuckerberg. But I wouldn't lay that at the foot of software engineering, or coding, etc. One of the major differences between computational work and chemical/civil/etc engineering is access to materials. We don't regulate computers much. At an entry level at least, people with some positional and financial means can get them and mess around with them pretty easily. We could perhaps imagine a system where access to hardware or networks were more locked down, but that's not what we've got. This easy-access is just one of the reasons patents for software are more controversial than those for other forms of engineering; it's a lot easier to incidentally violate a software patent. This oversight/consequences balance and the easy access to materials is one of the reasons I (and many others) have likened programming to writing. Writing can be hugely consequential and have huge oversight. But people also use it to make grocery lists. The humble grocery list and classified government reports have writing in common, but it doesn't make sense to treat them the same. I deliberating chose the unpretentious "coding" term for my book *Coding Literacy *(MIT 2017) because I wanted to talk about the low-oversight, low-consequence programming--the grocery lists of writing, which is done by a lot of people who don't have "software" in their job title. This kind of programming is closer to what's sometimes called "basic literacy," and could be the basis of a more accessible, *mass* literacy with computation. It's really different from software engineering and the training, professional societies, and consequences associated with it. To me, the choice is a political one: if we ascribe the values and constraints of software engineering on all of the tinkerers and grocery list writers, their opportunities and interest in programming is eclipsed. And then they don't write grocery lists--which are super useful!--nor do they eventually become software engineers. We know a lot about this dynamic from Margolis and Fisher and Misa and so many others who study why women (for example) leave computing. Abbate and Ensmenger (as they've contributed here on this list!) also have really helpful things to say about all of this, and I've relied on their work for my own. -Annette On Tue, May 5, 2020 at 10:27 PM McMillan, William W < william.mcmillan@cuaa.edu> wrote:
Thanks again for the many rich references, all!
Tom and Paul, I never thought of the use of "coder" as being "aggressively unpretentious." Fascinating. So the title-salad you all have elucidated led younger developers to just sluff off all the pomp and circumstance.
One might call that being pretentiously unpretentious!
Bill
________________________________ From: Members [members-bounces@lists.sigcis.org] on behalf of Ceruzzi, Paul [CeruzziP@si.edu] Sent: Tuesday, May 05, 2020 5:43 PM To: members@lists.sigcis.org Subject: [SIGCIS-Members] Coding vs programing (starting a new thread)
To those excellent suggestions I would also add the notes of Edsger Dijkstra. Some of his writings also come across as a "rant," but given the current muddy state of programming / coding, I conclude that he was spot on. Bill: sometimes it is OK to rant!
His "EWD" notes have been archived and are available on-line at the University of Texas. Some of them were gathered a few years ago and published by Springer.
http://www.cs.utexas.edu/users/EWD/
Paul Ceruzzi
-----------------
Message: 6 Date: Tue, 5 May 2020 19:50:48 +0000 From: "McMillan, William W" <william.mcmillan@cuaa.edu> To: "members@sigcis.org" <members@sigcis.org> Subject: Re: [SIGCIS-Members] Programmer vs. coder vs. sofware developer vs. software engineer Message-ID: <BCD19775A5154645AD4E79C257C1E37A02812E64F6@CUAA-EX02.cuaa.cuw.edu
Content-Type: text/plain; charset="us-ascii"
Thanks to those who sent suggestions for background info on this topic!
My own interest in the history of computing is really more about understanding the present, and my concern about the use and misuse of professional titles, though informed by history, leads to questions such as:
- Why do we call programmers and software developers coders nowadays, when that term has long been used to label those with quite limited intellectual involvement in software development, and even considered to be carrying out a clerical task (as explained well in Nathan's book)?
- Why do we apply the term software engineer to those who can program, but who really know very little about software engineering in the broader sense?
To me this suggests that our society, and the enterprises that create the software we use, have extremely limited understanding of software development and what it entails. This is a failure of those of us who teach computing and software engineering and maybe of professional societies.
The risks to society are immense. Imagine if a machinist or even a self-taught tinkerer could adopt the title mechanical engineer at will and be tasked with designing the critical devices of our civilization. Or if anyone with some knowledge of biochemistry could serve as a pharmacist?
Maybe SIGCIS members don't believe that this topic belongs on this list, but I feel that historians might be better positioned to address it than many in the technical and commercial communities who are consumed by immediate demands, and who have very limited understanding of their profession's past.
OK, end of rant!
Thanks, Bill
_______________________________________________ This email is relayed from members at sigcis.org, the email discussion list of SHOT SIGCIS. Opinions expressed here are those of the member posting and are not reviewed, edited, or endorsed by SIGCIS. The list archives are at http://lists.sigcis.org/pipermail/members-sigcis.org/ and you can change your subscription options at http://lists.sigcis.org/listinfo.cgi/members-sigcis.org