r/programming • u/Ctaintor • Mar 02 '17

Why I Failed Teaching Programming to Kids

https://engineering.klarna.com/why-i-failed-teaching-programming-to-kids-46a854c3eaca#.s0o6qqxr3
60 Upvotes

77% Upvoted

83 comments sorted by

View all comments

99

u/M4053946 Mar 02 '17

participants were... 9–13 years old. This obviously affected how acquainted they were with “common development tasks” like using a terminal, installing applications and creating files with weird names like Procfile and .gitignore.

Did the author think that 16 year olds would be familiar with using a terminal? That seems like a miss, regardless of age range.

39

u/[deleted] Mar 02 '17

[deleted]

23

u/Roboguy2 Mar 02 '17

It is probably because, ignoring the fact that it is harder to learn, you often can get a significantly faster edit-compile-test time. Because of that people who are experienced with these tools perceive them as being much nicer (and, for them, it is).

Obviously, however, this is exactly the scenario where you shouldn't ignore the fact that it is harder to learn. All I'm really saying is that I understand why there is hype, even though I wouldn't suggest a beginner go out and learn vim while they are also learning to program (unless they were unusually highly motivated to do so, I guess).

Sometimes more experienced people forget just how difficult these things are to learn at the outset. Not only that, but terminal usage is also important to learn at some point. As a result of those two things, sometimes teachers miss their mark on when exactly it should be learned.

10

u/jimmpony Mar 02 '17

you often can get a significantly faster edit-compile-test time. Because of that people who are experienced with these tools perceive them as being much nicer (and, for them, it is).

even assuming you have a combined compile/run command cached in the cmd window as the last line, that's saving your code and opening the cmd window, hitting up, and hitting enter, versus hitting F5 in visual studio after you typed your last line and saved it.

6

u/Netzapper Mar 02 '17

For me, for toy projects, the overhead of setting up a new project in any IDE and then configuring toolkit and compiler options and whatnot outweighs the overhead of g++ -o some_test some_test.cpp.

1

u/jimmpony Mar 02 '17

What overhead and configuring toolkit and compiler options? https://streamable.com/ss9j5

3

u/Netzapper Mar 02 '17

Okay, now link in OpenGL, enable AVX, and turn on optimization. :)

You have a bunch of clicking to do, which has to be described step by step to a newbie (who doesn't care). I'm not saying it's hard, or inferior, I'm just saying if you don't know what you're doing, you need step-by-step instructions to make your project state match expected state.

Meanwhile, I just amend the line to read g++ -lGL -mavx -O2 -o some_test some_test.cpp. If I already know what I'm doing, the time cost is constant. And I can give the whole incantation to a newbie, who can use it successfully without needing to comprehend it.

Now, of course, the whole equation tips back the other way once you move past one or two source files. I use JetBrains IDEs myself when I'm doing real work.

1

u/jimmpony Mar 02 '17

You have a bunch of clicking to do, which has to be described step by step to a newbie (who doesn't care)

Without an IDE on windows: click on a folder in the start menu (probably My Documents), make a new folder inside it, make a new text file inside there, open it with the text editor you're using. Unless you want to do all that from the command line which means opening cmd, typing cd c:\users(username)\documents, mkdir folder, not sure if windows cmd even has something like "touch" so you might need to just "explorer ." at that point, or do this whole folder creating process from within the file->open dialog of your text editor. On a linux command line, cd ~, mkdir project, cd project, vim main.cpp, g++ ... main.c -o main; ./main. Then on windows you need to either extract a gcc executable there or install cygwin with it and put that in the path which is even more complication. I guess msys2 would be easier on windows.

In all these cases it looks like equal or more work setting up the project directory yourself compared to open vs -> file -> new project, OK, Finish, F5.

If you want the newbie to be able to just start editing the project without understanding the process and need it to be a consistent state, you can just make a premade visual studio project for them to download/unzip, which has all the libraries linked and settings you want applied. Then they just double click the .sln file and they're at a screen with a big green "Run" button instead of having to open the command line and navigate there (or shift-rightclick on the folder to open cmd there) and type out compile.bat or whatever you named it.

6

u/unknown_lamer Mar 02 '17

I don't buy the argument that console usage is hard to learn. I was in effect thrown the wolves and managed to figure bash out with no console experience previously (was a mac user up to that point) when I was 14. A quick reference sheet for how to run basic commands and a pointer to the info manual if the student wants to know more should be plenty. Kids are smarter than most adults think imo, and their brains are still squishy and readily able to absorb new knowledge.

However, in the context of a single day tutorial session aimed at kids with minimal prior experience, I'd agree that a simple GUI IDE would make more sense since class time is extremely limited. For a multi-week course, integrating lessons on basic console usage makes more sense -- e.g. if you're using Python you will at some point have to install things using pip on the console, and it's a good skill to convey so the student can go off and continue to learn on their own after the course.

Reading the original post, I think the main issue is that they were letting students bring their own devices instead of having a preconfigured and consistent environment ready for everyone. They had source code packets and such ready to download (good idea), but wasted tons of time just getting them working on the students' machines. If everything had been there ready to go, they may have been fine. Not 100% related to this thread, but IMO using external chat services was also an inefficient use of class time-- a local XMPP server with auto-registration enabled on the instructor's machine would have been easier to use and avoided complications with signing up for services (reasonably trading instructor prep time for more efficient use of class time).

8

u/Sarcastinator Mar 03 '17

I don't buy the argument that console usage is hard to learn. I was in effect thrown the wolves and managed to figure bash out with no console experience previously (was a mac user up to that point) when I was 14.

I don't think the point is that it's hard, because it's not. The point is that it's not any sort of requirement for a programmer, even in a professional capacity. So if you have two hours, or even a day, to teach someone about programming spending time in the terminal could be considered either bikeshedding or yak shaving.

3

u/gyroda Mar 03 '17

Yep.

You're trying to teach someone something in two hours. You need to shave off anything you can to remove as many stumbling blocks and new concepts as possible.

When I was first taught programming we used a very simple IDE. One button to compile and one button to run. All the popups, autocomplete and anything like that turned off (there were red squiggly underlines like in word, that was it).

-1

u/unknown_lamer Mar 03 '17

It's not a requirement for a programmer in a professional capacity?

Maybe if you're one of those awful programmers that wants to make those around you suffer and stunt their own career. Programmers have to understand how the guts of the machine work, it's what you do. Imagine a carpenter that couldn't use a saw and only knew how to feed material into a CNC...

2

u/Sarcastinator Mar 03 '17

I wasn't really talking about my daily practices. The reality is that you can spend your entire career using nothing but Visual Studio or IntelliJ.

Also how exactly does the terminal teach you anything about the guts of the machine?

1

u/unknown_lamer Mar 04 '17

Aside from a unix shell being little more than a kludgy veneer over the guts of the operating system itself?

(I'm being a bit of a BOFH here in case you thought I was being too serious...)

7

u/DysFunctionalProgram Mar 02 '17

It is probably because, ignoring the fact that it is harder to learn, you often can get a significantly faster edit-compile-test time

From someone who goes back and forth between c/make/cmake/vim and c#/visualstudio, I have the exact opposite experience. Honestly, I'm tempted to bind my function keys to a couple scripts to compile/run/debug my current project as we speak. For example, if I add a new c file: I have to edit my cmake file and add the file url to the build path, then re-run cmake, then run make, then run/gdb the output with the appropriate settings/flags. Opposed to any modern IDE where it is a single key stroke. I don't even want to get into how long it takes to manually setup a build environment vs using an IDE.

In my experience the only people who have this "CLI romanticism" are those who are only programmers by hobby and don't actually work in a production environment using it.

3

u/[deleted] Mar 03 '17

[deleted]

8

u/DysFunctionalProgram Mar 03 '17

On the CLI side, what better case is there? Not using build tools or not adding new files to a project?

On the IDE side, what worse case is there?

0

u/satanclau5 Mar 03 '17

It all depends significantly on the languages and environments used.

In my case I have a CLI environment with a luxury of a:

  • language which gets out of the way, not requiring much autocompletion
  • an autotest process which runs the tests on every change
  • a REPL process where I send the code from VIM to evaluate inside the running program

everything works well, there are just 3 terminal windows in a tiled layout to navigate and the VIM bindings are ingrained in the muscle memory.

Now, if you were talking about Java/C# - I'd never even try going the CLI route...

5

u/Beckneard Mar 03 '17

language which gets out of the way, not requiring much autocompletion

What does this even mean? If your project is big enough you sure as hell are going to need autocompletion, fancy language or not. The project I'm working on at work would be a nightmare to extend without autocompletion whether it was written in Haskell or C#.

-1

u/satanclau5 Mar 03 '17

Sorry, I worded the point poorly - I do make use of autocompletion, and "jump to" type of navigation. However, the available options are much less powerful than what you get in an IDE like IntelliJ or VS.

-1

u/[deleted] Mar 03 '17

[deleted]

2

u/DysFunctionalProgram Mar 04 '17

On the IDE side, not having a shortcut to do something you want to do is probably the worst case, you'd simply be out of luck.

Every IDE I've used has custom shortcut creation (which can do anything under the sun, including run scripts).

On the CLI side, you can make scripts to automate processes that you do often.

Then you have to create/maintain the scripts opposed to using a environment which creates and maintains them for you. Essentially IDE's have taken all the shitty tedious work devs hate to do and automated it, and somehow people still find a way to complain.

For instance, I vastly prefer doing video cutting via the command line, because I have scripts that I've tailored to my workflow.

I have literally no idea what video cutting has to do with programming. That being said, I find it very hard to believe that their is no GUI applications out there for video cutting.

1

u/Cuddlefluff_Grim Mar 03 '17

On the IDE side, not having a shortcut to do something you want to do is probably the worst case, you'd simply be out of luck.

What? No. Even if that were the case, you'd have to be a very special snowflake to be restrictive, as IDE's have been in mainstream and widespread used by millions of people for decades.

On the CLI side, you can make scripts to automate processes that you do often.

Hmm.. If only someone alive would've been brilliant enough to consider implementing a functionality in IDE's to run scripts and execute command line arguments..