Implementing quicksort in Java is programming. Proving that quicksort is O(N log N) is computer science. Deciding if quicksort is a good choice as part of a large software architecture is software engineering.

There are ways to make these things distinct. Programming is writing code. Software engineering is more than writing code. Computer science is some formal discipline. There are other ways to slice things up I’m sure. But regardless of the division, I don’t see why we would want to do that.

I don’t think these activities form a natural kind. So it doesn’t seem we are trying to get at the truth by making these divisions. Instead we are trying to rank them. We are trying to say some of these are more sophisticated or nobler than the other. “That’s just programming, not true software engineering”.

I especially don’t understand the point of drawing a distinction between programming and software engineering. What do we gain by making this distinction? Is the act of planning how to write a program really not part of the programming activity? If I’m drawing up plans for how I’m going to make a chair, am I really involved in an activity distinctly different from wood working?

By drawing these distinctions we also open the door for the division of labor to occur. This creates the awful concept of “architect”. The perhaps most harmful concept we’ve ever created as a profession.

I'm also interested in what people think coding is. How is it different or similar to the other three? Where does it sit?

I don't really have any strong opinions here, just curious

I’ll just say the only distinction people have given me is that of status. Originally I told people I code. People told me that was lower status than programming. Then I said I program, people told me that was lower status than software developer. Then they told me that was lower status than software engineer. I wish this status stuff just didn’t exist. All code is code.

The fact that many people are trying to assign status doesn’t mean that the distinctions can’t be worthwhile unless that’s your goal.

I’m saying I don’t think there is a real distinction other than the status. How do you draw sharp non-arbitrary distinction between these?

Lu Wilson I liked this definition and history, from Smalltalk: Best Practice Patterns

Jimmy Miller My first approach to technical terms is to figure out how they are used by the majority of people in the field, in order to be able to communicate precisely with them. That doesn't imply agreeing with the utility, or even well-foundedness, of distinctions implicit in these terms.

I agree that programming vs. software engineering has an aspect of status, which I dislike as much as you do. But it also contains an aspect of size or complexity of a software project, and that makes sense. Writing 50 lines of code to reformat my blog entries is programming, but not software engineering.

I don’t think the distinction has to be sharp to be useful. I’d also say the distinction between computer science and the other two is sharper than the distinction between software engineering and programming.

That said, the latter distinction is real. I don’t really think I can give a proper definition, but I think it’s something like: “software engineering is about studying the practice of building software as a repeatable process with codified methods designed to facilitate development and maintenance by groups of people.”

Whereas programming is the catchall term for the activity of writing programs of any sort, and can be done with or without any attention to software engineering.

I think the distinction between coding and programming mostly is just about status, however. Coding sounds like you’re just a machine translating things. Programming sounds more like solving problems. But to me, that’s just the connotations, not a semantic difference.

Compounding difficulties, computer science is not a science, and software engineering is trying to be a science but still faking it. I tend to be suspicious of both terms. They mean about as much as my PhD in CS, particularly since they were all minted in academia under peculiar incentives. CS and SE are buzzwords, not jargon. Excluding a small region of math, it's all one amorphous beast we haven't found the bones for yet, let alone start to cleave at the joints. And yes, this includes what Greg Wilson does and whatever it is that Stephen Wolfram does. I tend to call it programming, since that was good enough for Dijkstra.

(I stand ready to duck.)

I haven't finished the episode yet but I keep thinking that declarative vs imperative is the most fundamental difference between work that's "officially" programming and not. Part of it is that thinking imperatively (i.e. predicting how a computer will do this) is a rare skill we've acquired through huge effort and trauma that's both incredibly powerful, in that it lets us occasionally do low level crazy shit to get close to optimal solutions... And another huge part is that many, many, many extremely valuable regions have no known effective declarative implementation techniques.

Declarative in the small: pure functional programming is the only way to do this that we broadly believe in, and it really sucks for most people

Declarative in the large: still a pipe dream except for query languages and related DAG composition systems, which are both super limiting

Componentware failed mainly because all useful abstractions eventually need to leak

I remain hopeful for declarative breakthroughs but I've been hoping for 35 years and they don't come around too often

I think y’all are doing a fine job of exploring this question. I just want to throw in a meta-level reference: I really enjoyed the classic paper “ Boundary-Work and the Demarcation of Science from Non-Science: Strains and Interests in Professional Ideologies of Scientists ”. It foregrounds the non-stop work people in professions have to do to define what lies inside their domains and what lies outside them. It’s got some really fun & paradoxical examples of these miniature battles. I recommend it!

law.unimelb.edu.au/__data/assets/pdf_file/0009/3623526/2-Gieryn-Boundary-work.pdf

Computer Science is like most science in that it's most (only?) effective when the subjects are atomized into parts that are small and simple enough that they allow rigorous study... but essentially all valuable software is vastly larger than that, and composed out of pieces that don't have simple relationships

put another way: if it's simple enough to be scienced, it's already a commodity

@Justin Blank

software engineering is about studying the practice of building software as a repeatable process with codified methods designed to facilitate development and maintenance by groups of people

So if a single person does something does it cease to be software engineering? Is quickjs not an example of software engineering because it was all done by Fabrice and isn't maintained by a group of people?

By the same token, does the maintenance of a spreadsheet by a group of people with codified practices count more as software engineering than the development of quickjs because multiple people were involved?

I don't mean this to be pointed, I sincerely don't understand what the distinction is supposed to be. Is it about groups? Is it about rigor? Is it subject matter, difficulty?

I don't consider anything I've done in my career to meet the criteria you gave. I don't think any of the processes I've done are repeatable, except the act of programming itself, which are trying to make as a distinction here.

Konrad Hinsen

But it also contains an aspect of size or complexity of a software project, and that makes sense. Writing 50 lines of code to reformat my blog entries is programming, but not software engineering.

Yeah, I just don't buy that though. A lot of what falls under the banner of software engineering is no more complex than writing 50 lines of code to reformat blog entries. The way in which I think about doing these activities is the same. The kinds of decisions you have to make to do them is the same. I am spending hours and hours of my time right now at work resolving merge conflicts from a fork that stopped tracking upstream. It is all to support things at a massive industrial scale. But my activity is writing a little clojure script that shells out to help me manage git patches. Is this software engineering? Does it change it if the resolutions here are for a compiler?

I'm getting an idea for a new video

Software that truly solves valuable problems for non-expert users and has the declarative mojo does exist, but it's 1) always specialized to particular verticals/use cases, and B) that's how billion-dollar software businesses happen. So, good news/bad news 😉

I don’t think the right distinction is “is this person writing code doing programming or software engineering.” Obviously, they are programming. I specifically said software engineering is the study of practices. There’s a parasitic sense in which you can say “someone who applies that study is doing software engineering, not just programming”, but imo, that’s less useful. Hence as a title, software engineer isn’t usefully different from programmer.

Basically, the distinction is not really between two activities, but between an academic discipline and an activity. The question you’re asking (or saying doesn’t make sense to ask) is a bit like asking “are you a writer or a historian?” It’s not an either or. But a writer isn’t the same thing as a historian in spite of that.

A potentially useful framing that’s a little different from what I have seen mooted above, but maps a bit to the adjacent fields of non-software engineering: a software engineer is someone who may be applying computer science in the act of programming with a particular degree of responsibility taken for the outcomes of the work done.

This is more, I think, aspirational than practical, certainly in terms of the titles people have at most jobs! There, the “prestige” dynamic reigns supreme. But this is the model I would like to be the case for software engineers, and when I distinguish in practice between “programming” and “software engineering” as gerunds, this is the kind of thing I have in mind, and is closely related to the point named by Konrad Hinsen in very pithy fashion at the outset!

In mooting that definition I am not making a value judgment about whether someone who acts as a software engineer while programming is better (or worse !) than someone who does not. It is not an ordering, partial or otherwise. 😂 Rather, I am saying that if we adopted this way of thinking, it would come with a set of expectations and norms that would be profitable for the field (profitable in the “generally good” sense; it might be less profitable in the “literal money-making” sense!).

So while this is absolutely true today modulo prestige considerations—

as a title, software engineer isn’t usefully different from programmer.

—I would very much like for it to be different. I would like it to be the case that we who want to claim the mantle of “engineers” take responsibility for (and are held accountable for!) the work we do in a particular way. And while yes, that would then become aspirational, it would be because we are expecting more from a subset of the field of software practitioners, and thereby perhaps elevating the field as a whole a bit.

@Justin Blank Interesting. So you consider software engineering to be studying how people (ought to/should/do/etc) create software, not actually the creation itself? So software engineers aren’t doing software engineering? (Except in that less useful sense you mentioned) That’s an interesting take for sure. I could definitely see a distinction if that is what is meant. Not sure that’s the common understanding though.

Also, shouldn’t we just call that meta-programming ;)

Kartik Agaram

computer science is not a science,

Are you referring to the old debate about what Herbert Simon nicely called "sciences of the artificial", which some do and others don't consider science? Or is it about CS not being serious/mature/whatever enough to be called science?

Personally, I am happy to include the sciences of the artificial under the "science" label, and I am happy with accepting immature fields as well, as long as they are working towards improvement of their own standards. So CS is a science for me. It's just not about computers, but that's only a problem with the English-language label.

and software engineering is trying to be a science but still faking it.

In the old science-vs.-engineering debate, I have taken the taoist stance and declared them a yin-yang pair. Science is about learning how the world works, and engineering is about changing the world based on scientific understanding. The problem with SE is that is hasn't much of a "science" partner yet. People are too busy making software and then making it obsolete that they have no time to reflect on their practices. So yes, "faking it" is a good description.

No, the artificiality isn't the problem. It's that vast swathes of CS academia aren't good at nailing down the context for their conclusions. They're often not reproducible, and even if you can reproduce them you can't reason about whether they apply to a slight change in context (this improves things for these benchmarks; does it help for this other benchmark?) You have to rerun the whole experiment all over again.

Ah, I see. Sounds familiar. But more an issue with 21-st century academia than with CS specifically. It's not different in other disciplines. The replication crisis is only one symptom of an increasing mismatch between the complexity of the questions being studied and the economic and political pressure for quick and simple answers, in the absence of any accountability.

Mary Shaw herself has described software engineering as "applying known solutions to new problems". Using this definition, I think of computer science as the field of identifying or discovering fundamentally new solutions.