11 ms·

Programming isn’t coding (2020)

149 points by luu 4y ago

throwaway118899 4y ago
[flagged]
davidhbolton 4y ago
There are no hard and fast definitions of programming or coding. To me they are the same but coding is more like slang. The formal name for both is software development.
- rascul 4y ago
  I've considered coding to be what some amateur hobbyist like me does. Programming is what people who get paid for it do. Both are software development. I'm not going to die on this hill, though.
- slaymaker1907 4y ago
  I know there at least used to be implications for immigration depending on the terminology for the job description.
Cyphase 4y ago
"Published 2020-08-02"
generalpf 4y ago
Clickbait if I’ve ever seen it.
mdaniel 4y ago
No one asked me, but my taxonomy is * coding = typing or clicking to have computers do stuff * programming = knowing how to type or click to make computers do stuff given knowledge of the SDK, libraries, toolchain, and _ideally_ how to communicate effectively with the IDE * software engineering = knowing when _not_ to program, knowing about components and the implication of their boundaries and contracts with the things outside of that component's boundaries, which in my world includes but is no limited to other methods in that same module, other modules in the same deployment, internal consumers, and most importantly any promises the code (or management) have made to _external_ consumers --- * coding = able to use a hammer * programming = able to assemble an Ikea cabinet, sometimes without the correct tools or complete instructions available * software engineering = able to design an Ikea cabinet for others and striving for a very low RMA rate
- poidos 4y ago
  I forgot the place I read this: Software development ("programming" in your taxonomy) is a solitary activity. Software engineering involves multiple people and the explosion of complexity involved. I do like your point about knowing when not to program. Will keep that in mind next time I think about this.
  - mdaniel 4y ago
    Ah, yes, I forgot about that axis. I'd have to think more carefully about the distinction between "programmers who just happen to be in a google of other programmers" versus "software engineers in a team" A lot of my software engineering mantras are centered around empathy management, both of internal consumers (future you, your colleagues, etc) and 100% unquestionably for external consumers (heh, "future you in 6 months" and folks that are forced to use your software, people who you want to renew). The world sucks bad enough already: don't swallow error messages and voluntarily tell your users the equivalent of "have you tried turning it off and on again?"
  - bcrosby95 4y ago
    I use software development in place of software engineering. To me software engineering involves more measurement and pre-planning than most developers use, even if they're working in large teams.
- drewcoo 4y ago
  I call that first one ("typing or clicking to have computers do stuff") "typing." The taxonomy is missing "designing," "architecting," "crafting," and more things people like to say they do. To feel important. More important than someone(s) else. And I often call myself a "professional typist" because the whole taxonomy is pompous BS. I get paid to solve business problems.
  - rfrey 4y ago
    >I get paid to solve business problems That's far more pretentious than any of the things you listed.
marcus_holmes 4y ago
> Programmers like to think that they spend all their time creating elaborate & complex abstractions Nope. Totally not. I spend all my time creating super-simple code using as few abstractions as possible. If anyone thinks my code is "elaborate" then I done it wrong.
okareaman 4y ago
Learning to use your tools is part of any job. I don't understand the point of this article or why such a low quality entry is on the front page.
EyeSayUntoThee 4y ago
Well, coding != complicated frontend development, which it appears you are teaching your students as an allegedly "easy" programming environment. You could perhaps consider starting them with Racket or some other "batteries included" programming environments specifically designed to avoid tooling bogs?
- mdaniel 4y ago
  I would offer that writing CSS is for sure "coding" in my world because the computers they are so picky about all those goofy characters. Damn, they have to be in the right order and matched up and everything :-D But I would be on-board if someone said that CSS is not "programming" since (AFAIK) there are no iterations, very few conditional statements, no recursion, and "library" means something entirely different
  - eyelidlessness 4y ago
    CSS definitely has iterations. Animations are the most obvious, but you could definitely build a state machine which progressively passes through and even recurses on state with custom properties (“variables”) and various conditional interactions from media/container queries. I’m not inclined to do this, because I have way too long a list of higher priorities, but I could possibly be nerd sniped into showing some proofs of concept if the idea sounds outlandish.
micheles 4y ago
>In my experience teaching programming, we spend very little time helping students actually write code. >Instead, the mentors mainly deal with problems of tooling – “it says ‘EADDRINUSE’ and crashes”; “git is giving an error”; “npm just says segmentation fault”. He is doing things wrong. If he wants the students to use modern tools he first need to give a course on the tools and later another one on programming. Otherwise he must not use modern tools (no git, no react) and use some simplified teaching environment (not ideal, but at least he will not be distracted by the tooling issues). In my experience (I have to work a lot with Ph.D. students in science with very little IT expertise) the tools are always the issue, while the algorithmic thinking is rarely a problem, so probably a course on the tools is more useful than one on programming. He must focus on tools that are not the fashion of the moment, so the terminal is okay, git is okay, React is not okay.
- seanmcdirmid 4y ago
  It depends where in the sciences they come from. Physicists don’t have much problem with abstract thinking, but biologists, maybe not as good (I used to help my biologist PhD student roommate write some Perl to crunch numbers). It reminds me of that xkcd comic https://xkcd.com/435/ https://xkcd.com/435/.
- cratermoon 4y ago
  How TF do you get a segfault from npm?
  - eyelidlessness 4y ago
    Well it’s not uncommon to have Node segfault, especially when interfacing with native extensions of one kind or another. NPM is just a Node script. It runs a whole lot of other Node scripts as preconditions by default. Many of them, maybe even most, interface with native extensions of one kind or another.
    - cratermoon 4y ago
      OK, Node I can see. I suppose part of the point of the article is that a student doesn't know npm from node, nor how npm run works. On the flip side, a core tool like node segfault commonly seems like a problem. Or at least a problem with poorly-written native extensions.
userbinator 4y ago
I also hate the "tool fetish" (and general advocacy of hidden but substantial complexity) that the software industry seems to have created... Programmers like to think that they spend all their time creating elaborate & complex abstractions ...and that's the essence of the problem. If you want to create needless complexity, you'll also suffer its consequences. although there absolutely still is a pretty strong contingent of people that advocate for a reversion to a “simpler” way of doing things I'm one of these, and I still avoid additional tools like the plague, unless they offer a very clear cost-benefit tradeoff. The vast majority of what I do needs only a few windows of a plaintext editor and a terminal. In my experience, others I've worked with who are also similarly minimalistic tend to be more competent too; at the other end of the scale, those who seem to love complex tooling are also the ones who need them as a crutch the most. That said, I have a different view of the "coding" vs "programming" distinction than some of the other comments here; to me, the latter implies more mindless work while the former (exemplified by terms like "sizecoding" or "democoding") refers to a more intimate and lower-level knowledge of what's going on, along with increased creativity and a problem-solving perspective.
- asdff 4y ago
  People need to live by the quote of "learn the rules before you break them." Its fine to use abstractions to save you time perhaps, but if you use them without understanding how they work, the considerations or assumptions being made, or what these results mean compared to alternatives, you are trodding off into the dangerous unknown, maybe even moving backwards. Uncertainty should be minimized.
  - akkad33 4y ago
    Can you give a resource on how a non programmer can learn these things? I learned and used Design patterns and functional programming techniques but I think I lack a foundational knowledge and feeling for why these are useful and why one is better than the other
    - asdff 4y ago
      Read the documentation for whatever language or tool you are working with. Read the textbooks assigned in computer science university courses if you want to go further. But specific to abstractions, say you have some tool that promises some way to structure your data or allow you to plot a chart or something like that. It's important to know how to do what this tool does the "old fashioned way" without the tool, so you can even vet whether the tool is actually useful or just more cruft you really don't need if you did your due diligence.
cjohnson318 4y ago
> For most non-Windows developers, a giant amount of time is spent using the terminal. The terminal might seem arcane, but the fact that you can copy/paste commands in there is a huge win. I'd much rather copy/paste some terminal commands into a safe place than try to take notes on what to click on to see what in a Windows system.
- yCombLinks 4y ago
  I mainly use windows, but always have multiple terminal windows open. Do people think that windows means I'm clicking around in folders and double clicking files all the time to do work?
  - rootw0rm 4y ago
    same. also a couple putty terminals connected to tmux sessions.
    - mdaniel 4y ago
      I mean this seriously: then what do you "use Windows" to do? Because it sounds like you have a dumb terminal
      - yCombLinks 4y ago
        I'm shipping windows native software, there's a lot less friction developing in the same environment.
mattigames 4y ago
Reminds me of my recent issue with parcel, one those tools that it's supposed to make frontend development less messy that lets you start with no configuration, I was in for a surprise, it does a lot of weird unexpected things with your code and files: - it changes the names of static files (e.g videos), if you put "type=module" on a script tag it deletes it (after investigating its due some incompatibility with how parcel works and top level awaits) - if you try to use any library that works on both the browser and node like fabricjs it fails at compile time (some parsing goes wrong), if you try to find some way to ignore such files you discover the only way is to host that script online because parcel doesn't touch these - if you use shadow Dom in your app it appends everything inside those twice when hot-reloading modules (tbf that has an easy solution that listens, to listen a parcel event to force a reload, about 3 lines of JS) And some other smaller issues, in conclusion it was a mistake, I converted it to webpack an it works all better now, I should have gone with webpack from the beginning and avoid things I haven't used before just from fake promises of simplicity.
efortis 4y ago
Related, Gerald Jay Sussman explains why they pulled the plug on MIT 6001 (SICP) here: https://www.youtube.com/watch?v=OgRFOjVzvm0 https://www.youtube.com/watch?v=OgRFOjVzvm0 In my words, he says: devs continuously change tech stacks without poking at the layers underneath. So only a few become proficient enough to focus on the abstractions. The same happens with designers, many become technicians of graphic design tools.
meling 4y ago
Reminds me of the MIT course the missing semester: https://missing.csail.mit.edu/ https://missing.csail.mit.edu/ Not sure they still run.
- CodexArcana 4y ago
  I came here to say this. I'm not a programmer by trade, but my sysadmin work dips its toes in many waters, and I shared it with my coworkers recently. I think some of the parts of this course are applicable to anyone who wants to "understand" how their computer functions.
galaxyLogic 4y ago
There's two challenges: 1. Coming up with an algorithm which really means expressing it in SOME language. That language can be pseudo-code or plain English. 2. Getting the computer to execute that algorithm. That requires that you get the computer to understand what you say is your algorithm. The latter can be called the "tooling" issue. The "tooling issue" is as important as algorithm development. Algorithm is great but you must be able to express it, in a way that somebody else besides you hopefully the computer understands it. It's like a composer would come up with a fantastic song in their head, but then for one reason or another were not able to play it to anybody. Tooling is about communicating with the computer, getting it to understand you, do what you want it to do.
dangus 4y ago
You could summarize this article by saying that students don't know a whole bunch of things yet, which is kind of the point right? They're students! Of course they don't know how to use all the tools in the toolbox. I would agree with the author in the sense that there should be a class or segment of the class that tackles how software engineers leverage their environment and use common tools. But, the way I understand it, that sort of thing is common in formal curriculum, it just doesn't cover everything. I wonder if this concern the author has brought up represents a perspective trap of having a significant level of lived experience. It's probably anxiety-inducing to think of someone leaving your class and not knowing 100% of the things a software engineer needs to succeed. But, really, if we think back to how we all were as students all those years ago, we were probably in the same boat. For example, personally, I didn't know how to use source control until I entered the industry. I learned git on the fly because an employer needed me to. Multiply that same story a few hundred/thousand times that you've got an experienced practitioner.
ARandomerDude 4y ago
> When teaching “programming”, a surprisingly small amount of time is spent actually helping students with logic – and a lot helping them learning & managing programming tools. This is true and fits my experience. > Programmers like to think that they spend all their time creating elaborate & complex abstractions but far more time is consumed dealing with the tools and idioms encrusted with historical baggage. I disagree. Junior developers spend a disproportionate amount of time learning how to use the tools but after about 3 years all the terminal and editor idiosyncrasies should be second nature. If a person is still struggling with tooling for any significant part of most weeks either something is very wrong or you’ve recently changed jobs (and will be up to speed soon). It’s clear that the author spends a huge amount of time with beginners, which probably colors his perception too much.
textninja 4y ago
Programming isn't just coding.
cutler 4y ago
Gradle must die. If learning the build tool is more work than learning the language it supports something is wrong.
- Hackbraten 4y ago
  I’ve struggled with Gradle for years, and remember hating it because of how overly complex and developer-hostile it seemed. Today, I write Gradle plug-ins, mentor others who seem unhappy, and am generally pleased that Gradle exists and how it can significantly improve build times in some projects if wielded correctly. Its learning curve and user-friendliness, however, are truly abysmal imho.
- bartekpacia 4y ago
  Not sure how that’s relevant to the article. But since you’ve started this topic, I gotta say I love Gradle and I think it’s the best build system out there (until you reach a certain (huge) scale - then look at Bazel). I learned it by reading the docs a few times and contributing to OSS projects, improving their build scripts and plugins. Feeling pretty confident with it now. I don’t get why it gets so much hate - as if people didn’t want to spend time to actually learn it. If Gradle gets this much hate, then CMake should get 100x more.
divan 4y ago
The best explanation I've seen is in the book "The Secret Life of Programs" by Jonathan E. Steinhart. I'll quote that paragraph verbatim: --- Computer programming is a two-step process: 1. Understand the universe. 2. Explain it to a three-year-old. What does this mean? Well, you can't write computer programs to do things that you yourself don't understand. For example, you can't write a spellchecker if you don't know the rules for spelling, and you can't write a good action video game if you don't know physics. So, the first step in becoming a good computer programmer is to learn as much as you can about everything else. Solutions to problems often come from unexpected places, so don't ignore something just because it doesn't seem immediately relevant. The second step of the process requires explaining what you know to a machine that has a very rigid view of the world, like young children do. This rigidity in children is really obvious when they're about three years old. Let's say you're trying to get out the door. You ask your child, "Where are your shoes?" The response: "There." She did answer your question. The problem is, she doesn't understand that you're really asking her to put her shoes on so that you both can go somewhere. Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up.
- asadawadia 4y ago
  what a great explanation
- nextaccountic 4y ago
  This is an amazing explanation, but I sense that it will become dated in some years, like, it will describe how computing worked in the old times, when people actually coded by hand. Because, > Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up. LLMs will change all of this. Maybe in some decades we will see programming environments that don't require people to understand the solution in order to create a program. For example, it may be possible for people to create spellcheckers without understanding the rules of spelling. Unfortunately this will create a whole new class of bugs due to AIs hallucinating code, and I'm afraid that the average software quality will take a hit.
zol 4y ago
Teaching programming via the technologies in fashion and practical for getting a job today is flawed. Teach the fundamentals - math, logic, algorithms. But, most importantly, teach how to learn and problem solve. If your students can’t figure out how to quit their editor they’re doomed in this career. Forget about React and hooks, those will be out of date by the time they’re entering the workforce.
- namaria 4y ago
  I agree in essence but I disagree it's fundamentally flawed to teach current tooling first. A lot of (aspiring) programmers and companies don't really care about actual technical competence. They just need to do something gainful for the day and get paid. The fact that I go about it differently doesn't mean they are wrong of flawed.
- spc476 4y ago
  Nice in theory. I recall a few years after leaving university talking to a few friends who worked there in the Computer Science department. They would regale me with tales of students who would constantly complain to the dean that the assignments were too hard, why where they being forced to learn stuff not currently used in the industry, and bemoan the fact that they couldn't turn in their source code as a Microsoft Word document (seriously). They were, by God, paying all this money! By the way, this was in the mid-90s. I can only imaging it being worse today.
patrulek 4y ago
Programming is creating a program. Coding is writing a code. These two often overlaps but they doesnt have to.
eimrine 4y ago
> students need to know that Ctrl-C will interrupt most things, Ctrl-D will stop some other things This is so true.
- spc476 4y ago
  But ... but ... but ... my keyboard has this "escape" key! Why doesn't that let me escape the current program? Oh, there's this "break" key! That doesn't seem to work. And why do I have to use Ctrl-D when I have this "pause" key as well? Can you see why students might be confused?
  - eviks 4y ago
    If only educators cared enough about students to make a few key rebinds to make this confusion go away...
emme 4y ago
This ITiCSE working group tried to clarify why we should be interested in programming (not coding) in education: What We Talk About When We Talk About Programs https://dl.acm.org/doi/10.1145/3571785.3574125 https://dl.acm.org/doi/10.1145/3571785.3574125 (open access)
nuc1e0n 4y ago
This blog post is referring to the same accidental complexity that Fred Brooks did in his classic 'No Silver Bullet' essay. Overly complex tooling remains a problem today.
kazinator 4y ago
> Unfortunately, doing anything in the terminal is, if not a struggle, something very new to most beginning programmers. Ah, but the terminal is also the territory where the low-dependency, instant-gratification, just-get-coding tools live.
abeyer 4y ago
Wait, "react week"? In what way is trying to cram learning react into one week a good idea? Especially if someone is already unfamiliar or struggling with classes and functions and using the tools. I've seen experienced programmers not really grasp react in a week. This feels like a "if we skip all the fundamentals to train 'marketable' programmers as fast as possible then they struggle with fundamentals" problem.
ChrisMarshallNY 4y ago
This has always been an issue with me. I first learned coding/programming in the days of "big iron," and embedded (machine and ASM) coding. These require a "Measure Twice, Cut Once" approach. In fact, the "coding" part is really just data entry. These days, with integrated symbolic debuggers and IDEs, I can start coding right away, and writing a prototype is often MUCH faster than planning it out. I'll usually spend very little time, planning, and start coding, very quickly[0]. In the "days of yore," this would have me excommunicated. But I have found that it results in extremely well-written, well-designed, and fast end results. I also tend to work very quickly. Being experienced helps. In fact, it may be a requirement, as I can map out a design in my head that follows the desire path to a good result. I have very manageable failures, and seldom need to throw everything out, and start from scratch. But even then, I'm not throwing out a whole boatload of invested time and effort. It's easy to toss a bad design, and that's critical, for me. [0] https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...
1bent 4y ago
I think this is more of a complaint that GUIs have prevented non-programmers from learning to do novel things with a computer; that's been the focus of GUIs since the Apple Lisa. I was working in a university comp center, and got to see a Lisa at an Apple event shortly after it was announced. Everyone who went with me agreed, it's better than an etch-a-sketch, you don't have to turn it upside down and shake to clear the screen. But at that moment computers bifurcated: real computers for programmers, and appliances for the rest of them.
lisp-pornstar 4y ago
Commenting on: X is not Y (510 BC)
phforms 4y ago
I believe there is great value in introducing learners to tools that are so simple and easy to use that they can just get started and focus on programming without having to wrestle with tools and incidental complexity. This is a design challenge: crafting tools that are laser-focussed on their actual purpose and trying to make it as straightforward as possible for users to do what they intent to do. It takes empathy and clear, simple and pragmatic thinking, which can be surprisingly hard for many people and I believe it becomes harder the more we become entrenched in our profession and its way of doing things. In my own experience, if I had not discovered Processing I am not sure if I would have actually gone down this path and become a developer. Before that, I had so many frustrating experiences with tools and especially the command line. Everything was just so opaque to me, since I had no one with programming experience to guide me through and when I tried looking something up, I felt like I was going down a neverending rabbit hole. Now I really enjoy digging into the most obscure tools and programming languages, use Vim and Emacs daily (yes, you can like both) and actually enjoy writing shell scripts. I think if beginners actually get to experience what it is like to program something that is meaningful to them, that they care about or just enjoy, they will become motivated to learn all the hard and annoying things as well. But they should not be stopped by hundreds of landmines and roadblocks before they even get there.
eviks 4y ago
> I think the students would be better served if they learned to use git using GUI tools, at least initially, but that would be an anathema to the dev culture But why do you care about the backward culture more than the real students?

149 points by luu 4y ago

[flagged]

There are no hard and fast definitions of programming or coding. To me they are the same but coding is more like slang. The formal name for both is software development.

rascul 4y ago
I've considered coding to be what some amateur hobbyist like me does. Programming is what people who get paid for it do. Both are software development. I'm not going to die on this hill, though.
slaymaker1907 4y ago
I know there at least used to be implications for immigration depending on the terminology for the job description.

Cyphase 4y ago

"Published 2020-08-02"

generalpf 4y ago

Clickbait if I’ve ever seen it.

mdaniel 4y ago

No one asked me, but my taxonomy is * coding = typing or clicking to have computers do stuff * programming = knowing how to type or click to make computers do stuff given knowledge of the SDK, libraries, toolchain, and _ideally_ how to communicate effectively with the IDE * software engineering = knowing when _not_ to program, knowing about components and the implication of their boundaries and contracts with the things outside of that component's boundaries, which in my world includes but is no limited to other methods in that same module, other modules in the same deployment, internal consumers, and most importantly any promises the code (or management) have made to _external_ consumers --- * coding = able to use a hammer * programming = able to assemble an Ikea cabinet, sometimes without the correct tools or complete instructions available * software engineering = able to design an Ikea cabinet for others and striving for a very low RMA rate

poidos 4y ago
I forgot the place I read this: Software development ("programming" in your taxonomy) is a solitary activity. Software engineering involves multiple people and the explosion of complexity involved. I do like your point about knowing when not to program. Will keep that in mind next time I think about this.
- mdaniel 4y ago
  Ah, yes, I forgot about that axis. I'd have to think more carefully about the distinction between "programmers who just happen to be in a google of other programmers" versus "software engineers in a team" A lot of my software engineering mantras are centered around empathy management, both of internal consumers (future you, your colleagues, etc) and 100% unquestionably for external consumers (heh, "future you in 6 months" and folks that are forced to use your software, people who you want to renew). The world sucks bad enough already: don't swallow error messages and voluntarily tell your users the equivalent of "have you tried turning it off and on again?"
- bcrosby95 4y ago
  I use software development in place of software engineering. To me software engineering involves more measurement and pre-planning than most developers use, even if they're working in large teams.
drewcoo 4y ago
I call that first one ("typing or clicking to have computers do stuff") "typing." The taxonomy is missing "designing," "architecting," "crafting," and more things people like to say they do. To feel important. More important than someone(s) else. And I often call myself a "professional typist" because the whole taxonomy is pompous BS. I get paid to solve business problems.
- rfrey 4y ago
  >I get paid to solve business problems That's far more pretentious than any of the things you listed.

marcus_holmes 4y ago

> Programmers like to think that they spend all their time creating elaborate & complex abstractions Nope. Totally not. I spend all my time creating super-simple code using as few abstractions as possible. If anyone thinks my code is "elaborate" then I done it wrong.

okareaman 4y ago

Learning to use your tools is part of any job. I don't understand the point of this article or why such a low quality entry is on the front page.

EyeSayUntoThee 4y ago

Well, coding != complicated frontend development, which it appears you are teaching your students as an allegedly "easy" programming environment. You could perhaps consider starting them with Racket or some other "batteries included" programming environments specifically designed to avoid tooling bogs?

mdaniel 4y ago
I would offer that writing CSS is for sure "coding" in my world because the computers they are so picky about all those goofy characters. Damn, they have to be in the right order and matched up and everything :-D But I would be on-board if someone said that CSS is not "programming" since (AFAIK) there are no iterations, very few conditional statements, no recursion, and "library" means something entirely different
- eyelidlessness 4y ago
  CSS definitely has iterations. Animations are the most obvious, but you could definitely build a state machine which progressively passes through and even recurses on state with custom properties (“variables”) and various conditional interactions from media/container queries. I’m not inclined to do this, because I have way too long a list of higher priorities, but I could possibly be nerd sniped into showing some proofs of concept if the idea sounds outlandish.

micheles 4y ago

>In my experience teaching programming, we spend very little time helping students actually write code. >Instead, the mentors mainly deal with problems of tooling – “it says ‘EADDRINUSE’ and crashes”; “git is giving an error”; “npm just says segmentation fault”. He is doing things wrong. If he wants the students to use modern tools he first need to give a course on the tools and later another one on programming. Otherwise he must not use modern tools (no git, no react) and use some simplified teaching environment (not ideal, but at least he will not be distracted by the tooling issues). In my experience (I have to work a lot with Ph.D. students in science with very little IT expertise) the tools are always the issue, while the algorithmic thinking is rarely a problem, so probably a course on the tools is more useful than one on programming. He must focus on tools that are not the fashion of the moment, so the terminal is okay, git is okay, React is not okay.

seanmcdirmid 4y ago
It depends where in the sciences they come from. Physicists don’t have much problem with abstract thinking, but biologists, maybe not as good (I used to help my biologist PhD student roommate write some Perl to crunch numbers). It reminds me of that xkcd comic https://xkcd.com/435/ https://xkcd.com/435/.
cratermoon 4y ago
How TF do you get a segfault from npm?
- eyelidlessness 4y ago
  Well it’s not uncommon to have Node segfault, especially when interfacing with native extensions of one kind or another. NPM is just a Node script. It runs a whole lot of other Node scripts as preconditions by default. Many of them, maybe even most, interface with native extensions of one kind or another.
  - cratermoon 4y ago
    OK, Node I can see. I suppose part of the point of the article is that a student doesn't know npm from node, nor how npm run works. On the flip side, a core tool like node segfault commonly seems like a problem. Or at least a problem with poorly-written native extensions.

userbinator 4y ago

I also hate the "tool fetish" (and general advocacy of hidden but substantial complexity) that the software industry seems to have created... Programmers like to think that they spend all their time creating elaborate & complex abstractions ...and that's the essence of the problem. If you want to create needless complexity, you'll also suffer its consequences. although there absolutely still is a pretty strong contingent of people that advocate for a reversion to a “simpler” way of doing things I'm one of these, and I still avoid additional tools like the plague, unless they offer a very clear cost-benefit tradeoff. The vast majority of what I do needs only a few windows of a plaintext editor and a terminal. In my experience, others I've worked with who are also similarly minimalistic tend to be more competent too; at the other end of the scale, those who seem to love complex tooling are also the ones who need them as a crutch the most. That said, I have a different view of the "coding" vs "programming" distinction than some of the other comments here; to me, the latter implies more mindless work while the former (exemplified by terms like "sizecoding" or "democoding") refers to a more intimate and lower-level knowledge of what's going on, along with increased creativity and a problem-solving perspective.

asdff 4y ago
People need to live by the quote of "learn the rules before you break them." Its fine to use abstractions to save you time perhaps, but if you use them without understanding how they work, the considerations or assumptions being made, or what these results mean compared to alternatives, you are trodding off into the dangerous unknown, maybe even moving backwards. Uncertainty should be minimized.
- akkad33 4y ago
  Can you give a resource on how a non programmer can learn these things? I learned and used Design patterns and functional programming techniques but I think I lack a foundational knowledge and feeling for why these are useful and why one is better than the other
  - asdff 4y ago
    Read the documentation for whatever language or tool you are working with. Read the textbooks assigned in computer science university courses if you want to go further. But specific to abstractions, say you have some tool that promises some way to structure your data or allow you to plot a chart or something like that. It's important to know how to do what this tool does the "old fashioned way" without the tool, so you can even vet whether the tool is actually useful or just more cruft you really don't need if you did your due diligence.

cjohnson318 4y ago

> For most non-Windows developers, a giant amount of time is spent using the terminal. The terminal might seem arcane, but the fact that you can copy/paste commands in there is a huge win. I'd much rather copy/paste some terminal commands into a safe place than try to take notes on what to click on to see what in a Windows system.

yCombLinks 4y ago
I mainly use windows, but always have multiple terminal windows open. Do people think that windows means I'm clicking around in folders and double clicking files all the time to do work?
- rootw0rm 4y ago
  same. also a couple putty terminals connected to tmux sessions.
  - mdaniel 4y ago
    I mean this seriously: then what do you "use Windows" to do? Because it sounds like you have a dumb terminal
    - yCombLinks 4y ago
      I'm shipping windows native software, there's a lot less friction developing in the same environment.

mattigames 4y ago

Reminds me of my recent issue with parcel, one those tools that it's supposed to make frontend development less messy that lets you start with no configuration, I was in for a surprise, it does a lot of weird unexpected things with your code and files: - it changes the names of static files (e.g videos), if you put "type=module" on a script tag it deletes it (after investigating its due some incompatibility with how parcel works and top level awaits) - if you try to use any library that works on both the browser and node like fabricjs it fails at compile time (some parsing goes wrong), if you try to find some way to ignore such files you discover the only way is to host that script online because parcel doesn't touch these - if you use shadow Dom in your app it appends everything inside those twice when hot-reloading modules (tbf that has an easy solution that listens, to listen a parcel event to force a reload, about 3 lines of JS) And some other smaller issues, in conclusion it was a mistake, I converted it to webpack an it works all better now, I should have gone with webpack from the beginning and avoid things I haven't used before just from fake promises of simplicity.

efortis 4y ago

Related, Gerald Jay Sussman explains why they pulled the plug on MIT 6001 (SICP) here: https://www.youtube.com/watch?v=OgRFOjVzvm0 https://www.youtube.com/watch?v=OgRFOjVzvm0 In my words, he says: devs continuously change tech stacks without poking at the layers underneath. So only a few become proficient enough to focus on the abstractions. The same happens with designers, many become technicians of graphic design tools.

meling 4y ago

Reminds me of the MIT course the missing semester: https://missing.csail.mit.edu/ https://missing.csail.mit.edu/ Not sure they still run.

CodexArcana 4y ago
I came here to say this. I'm not a programmer by trade, but my sysadmin work dips its toes in many waters, and I shared it with my coworkers recently. I think some of the parts of this course are applicable to anyone who wants to "understand" how their computer functions.

galaxyLogic 4y ago

There's two challenges: 1. Coming up with an algorithm which really means expressing it in SOME language. That language can be pseudo-code or plain English. 2. Getting the computer to execute that algorithm. That requires that you get the computer to understand what you say is your algorithm. The latter can be called the "tooling" issue. The "tooling issue" is as important as algorithm development. Algorithm is great but you must be able to express it, in a way that somebody else besides you hopefully the computer understands it. It's like a composer would come up with a fantastic song in their head, but then for one reason or another were not able to play it to anybody. Tooling is about communicating with the computer, getting it to understand you, do what you want it to do.

dangus 4y ago

You could summarize this article by saying that students don't know a whole bunch of things yet, which is kind of the point right? They're students! Of course they don't know how to use all the tools in the toolbox. I would agree with the author in the sense that there should be a class or segment of the class that tackles how software engineers leverage their environment and use common tools. But, the way I understand it, that sort of thing is common in formal curriculum, it just doesn't cover everything. I wonder if this concern the author has brought up represents a perspective trap of having a significant level of lived experience. It's probably anxiety-inducing to think of someone leaving your class and not knowing 100% of the things a software engineer needs to succeed. But, really, if we think back to how we all were as students all those years ago, we were probably in the same boat. For example, personally, I didn't know how to use source control until I entered the industry. I learned git on the fly because an employer needed me to. Multiply that same story a few hundred/thousand times that you've got an experienced practitioner.

ARandomerDude 4y ago

> When teaching “programming”, a surprisingly small amount of time is spent actually helping students with logic – and a lot helping them learning & managing programming tools. This is true and fits my experience. > Programmers like to think that they spend all their time creating elaborate & complex abstractions but far more time is consumed dealing with the tools and idioms encrusted with historical baggage. I disagree. Junior developers spend a disproportionate amount of time learning how to use the tools but after about 3 years all the terminal and editor idiosyncrasies should be second nature. If a person is still struggling with tooling for any significant part of most weeks either something is very wrong or you’ve recently changed jobs (and will be up to speed soon). It’s clear that the author spends a huge amount of time with beginners, which probably colors his perception too much.

textninja 4y ago

Programming isn't just coding.

cutler 4y ago

Gradle must die. If learning the build tool is more work than learning the language it supports something is wrong.

Hackbraten 4y ago
I’ve struggled with Gradle for years, and remember hating it because of how overly complex and developer-hostile it seemed. Today, I write Gradle plug-ins, mentor others who seem unhappy, and am generally pleased that Gradle exists and how it can significantly improve build times in some projects if wielded correctly. Its learning curve and user-friendliness, however, are truly abysmal imho.
bartekpacia 4y ago
Not sure how that’s relevant to the article. But since you’ve started this topic, I gotta say I love Gradle and I think it’s the best build system out there (until you reach a certain (huge) scale - then look at Bazel). I learned it by reading the docs a few times and contributing to OSS projects, improving their build scripts and plugins. Feeling pretty confident with it now. I don’t get why it gets so much hate - as if people didn’t want to spend time to actually learn it. If Gradle gets this much hate, then CMake should get 100x more.

divan 4y ago

The best explanation I've seen is in the book "The Secret Life of Programs" by Jonathan E. Steinhart. I'll quote that paragraph verbatim: --- Computer programming is a two-step process: 1. Understand the universe. 2. Explain it to a three-year-old. What does this mean? Well, you can't write computer programs to do things that you yourself don't understand. For example, you can't write a spellchecker if you don't know the rules for spelling, and you can't write a good action video game if you don't know physics. So, the first step in becoming a good computer programmer is to learn as much as you can about everything else. Solutions to problems often come from unexpected places, so don't ignore something just because it doesn't seem immediately relevant. The second step of the process requires explaining what you know to a machine that has a very rigid view of the world, like young children do. This rigidity in children is really obvious when they're about three years old. Let's say you're trying to get out the door. You ask your child, "Where are your shoes?" The response: "There." She did answer your question. The problem is, she doesn't understand that you're really asking her to put her shoes on so that you both can go somewhere. Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up.

asadawadia 4y ago
what a great explanation
nextaccountic 4y ago
This is an amazing explanation, but I sense that it will become dated in some years, like, it will describe how computing worked in the old times, when people actually coded by hand. Because, > Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up. LLMs will change all of this. Maybe in some decades we will see programming environments that don't require people to understand the solution in order to create a program. For example, it may be possible for people to create spellcheckers without understanding the rules of spelling. Unfortunately this will create a whole new class of bugs due to AIs hallucinating code, and I'm afraid that the average software quality will take a hit.

zol 4y ago

Teaching programming via the technologies in fashion and practical for getting a job today is flawed. Teach the fundamentals - math, logic, algorithms. But, most importantly, teach how to learn and problem solve. If your students can’t figure out how to quit their editor they’re doomed in this career. Forget about React and hooks, those will be out of date by the time they’re entering the workforce.

namaria 4y ago
I agree in essence but I disagree it's fundamentally flawed to teach current tooling first. A lot of (aspiring) programmers and companies don't really care about actual technical competence. They just need to do something gainful for the day and get paid. The fact that I go about it differently doesn't mean they are wrong of flawed.
spc476 4y ago
Nice in theory. I recall a few years after leaving university talking to a few friends who worked there in the Computer Science department. They would regale me with tales of students who would constantly complain to the dean that the assignments were too hard, why where they being forced to learn stuff not currently used in the industry, and bemoan the fact that they couldn't turn in their source code as a Microsoft Word document (seriously). They were, by God, paying all this money! By the way, this was in the mid-90s. I can only imaging it being worse today.

patrulek 4y ago

Programming is creating a program. Coding is writing a code. These two often overlaps but they doesnt have to.

eimrine 4y ago

> students need to know that Ctrl-C will interrupt most things, Ctrl-D will stop some other things This is so true.

spc476 4y ago
But ... but ... but ... my keyboard has this "escape" key! Why doesn't that let me escape the current program? Oh, there's this "break" key! That doesn't seem to work. And why do I have to use Ctrl-D when I have this "pause" key as well? Can you see why students might be confused?
- eviks 4y ago
  If only educators cared enough about students to make a few key rebinds to make this confusion go away...

emme 4y ago

This ITiCSE working group tried to clarify why we should be interested in programming (not coding) in education: What We Talk About When We Talk About Programs https://dl.acm.org/doi/10.1145/3571785.3574125 https://dl.acm.org/doi/10.1145/3571785.3574125 (open access)

nuc1e0n 4y ago

This blog post is referring to the same accidental complexity that Fred Brooks did in his classic 'No Silver Bullet' essay. Overly complex tooling remains a problem today.

kazinator 4y ago

> Unfortunately, doing anything in the terminal is, if not a struggle, something very new to most beginning programmers. Ah, but the terminal is also the territory where the low-dependency, instant-gratification, just-get-coding tools live.

abeyer 4y ago

Wait, "react week"? In what way is trying to cram learning react into one week a good idea? Especially if someone is already unfamiliar or struggling with classes and functions and using the tools. I've seen experienced programmers not really grasp react in a week. This feels like a "if we skip all the fundamentals to train 'marketable' programmers as fast as possible then they struggle with fundamentals" problem.

ChrisMarshallNY 4y ago

This has always been an issue with me. I first learned coding/programming in the days of "big iron," and embedded (machine and ASM) coding. These require a "Measure Twice, Cut Once" approach. In fact, the "coding" part is really just data entry. These days, with integrated symbolic debuggers and IDEs, I can start coding right away, and writing a prototype is often MUCH faster than planning it out. I'll usually spend very little time, planning, and start coding, very quickly[0]. In the "days of yore," this would have me excommunicated. But I have found that it results in extremely well-written, well-designed, and fast end results. I also tend to work very quickly. Being experienced helps. In fact, it may be a requirement, as I can map out a design in my head that follows the desire path to a good result. I have very manageable failures, and seldom need to throw everything out, and start from scratch. But even then, I'm not throwing out a whole boatload of invested time and effort. It's easy to toss a bad design, and that's critical, for me. [0] https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...

1bent 4y ago

I think this is more of a complaint that GUIs have prevented non-programmers from learning to do novel things with a computer; that's been the focus of GUIs since the Apple Lisa. I was working in a university comp center, and got to see a Lisa at an Apple event shortly after it was announced. Everyone who went with me agreed, it's better than an etch-a-sketch, you don't have to turn it upside down and shake to clear the screen. But at that moment computers bifurcated: real computers for programmers, and appliances for the rest of them.

lisp-pornstar 4y ago

Commenting on: X is not Y (510 BC)

phforms 4y ago

I believe there is great value in introducing learners to tools that are so simple and easy to use that they can just get started and focus on programming without having to wrestle with tools and incidental complexity. This is a design challenge: crafting tools that are laser-focussed on their actual purpose and trying to make it as straightforward as possible for users to do what they intent to do. It takes empathy and clear, simple and pragmatic thinking, which can be surprisingly hard for many people and I believe it becomes harder the more we become entrenched in our profession and its way of doing things. In my own experience, if I had not discovered Processing I am not sure if I would have actually gone down this path and become a developer. Before that, I had so many frustrating experiences with tools and especially the command line. Everything was just so opaque to me, since I had no one with programming experience to guide me through and when I tried looking something up, I felt like I was going down a neverending rabbit hole. Now I really enjoy digging into the most obscure tools and programming languages, use Vim and Emacs daily (yes, you can like both) and actually enjoy writing shell scripts. I think if beginners actually get to experience what it is like to program something that is meaningful to them, that they care about or just enjoy, they will become motivated to learn all the hard and annoying things as well. But they should not be stopped by hundreds of landmines and roadblocks before they even get there.

eviks 4y ago

> I think the students would be better served if they learned to use git using GUI tools, at least initially, but that would be an anathema to the dev culture But why do you care about the backward culture more than the real students?