Hacker News Reader

Comment by ng12 | Hacker News Reader

Teaching is not the problem. Anyone can pick up a free online book (I like to recommend SICP or HTDP) and learn everything they need to be a professional programmer. This isn't medical school where you need 8 years of education and experience before you can begin to practice your profession with a limited chance of killing someone.

Teaching CS is hard but I think the root of it is our ability to teach people how to think. Learning to program is easy compared to the problem of learning how to think algorithmically. Nobody fails CS101 because they can't remember the syntax of function definition, they fail because they can't figure out which functions they need to write to make a ball dance across the screen.

View on HN

> This isn't medical school where you need 8 years of education and experience before you can begin to practice your profession with a limited chance of killing someone.

Completely disagree with this statement. Being a doctor and being a programmer are similar in a lot of ways. In both fields unless you are a specialized expert focusing on the cutting edge of research you really don't need 8 years study/doctoral training. Most doctor jobs are like most programming jobs, the same old simple tasks day in and day out, diagnosing the flue for the 100 trillionth time, or writing a controller/view for the billionth time.

As a society, we've allowed a lot of bureaucracy to build up around the medical profession, which is one of the (many) reasons medical costs are rising and innovation is less that in would be otherwise.

Imagine how slow we would be to innovate and make technological progress, if we forced everyone who wanted to write software to undergo 4 years of bachelor schooling and 8 years on top of that of rigorous study and training before they could begin to write a crud app.

There's obviously a spectrum of expertise that's needed, and its a shame our medical systems don't allow for it. A sysadmin does not need a phd in theoretical computer science to keep his companies server's running at high uptime rates, and a family doctor does not need 12 years of study to diagnose common illnesses and refer people to experts, and a dentist should honestly be a regular trade job learned in an apprenticeship.

>Most doctor jobs are like most programming jobs, the same old simple tasks day in and day out, diagnosing the flue for the 100 trillionth time, or writing a controller/view for the billionth time.

I tend to find that programmers who have repetitive jobs are simply programmers who don't automate their workflow, don't make full use of vast the ecosystem of packages at their fingertips and don't build useful abstractions.

That's as true for CRUD apps as it is for anything else. If your job isn't creative & if your job is repetitive you are doing it wrong.

> if your job is repetitive you are doing it wrong.

If jobs weren't repetitive we wouldn't group together a specific set of tasks under a label and hire people who can accomplish said tasks. We also wouldn't even be able to learn a job in the first place because by definition it would constantly be something new and we could never obtain any competency.

All learning is acquired through lots of repetitions across variances in experiences in a specific set of tasks. Machines learn this way, and all evidence suggests we do as well.

>If jobs weren't repetitive we wouldn't group together a specific set of tasks under a label and hire people who can accomplish said tasks.

I don't see why not. Since excessive repetitiveness of a task required in order to hire people? Exercising creativity and good judgment rarely happens the same way twice, but it still ought to improve over time.

>We also wouldn't even be able to learn a job in the first place because by definition it would constantly be something new and we could never obtain any competency.

A) Learning effectively is not the same thing as doing effectively and B) I'm not arguing that every programming job should be entirely devoid of repetition, just that by its nature it shouldn't be repetitive.

> Learning effectively is not the same thing as doing effectively.

You have to learn in order to do and doing is the means for learning. Its iterative and both reinforce one another. So from my viewpoint, which admittedly is largely from an ML perspective, they are the same thing. Playing basketball effectively is a function of training which is just another word for learning in my mind.

> I'm not arguing that every programming job should be entirely devoid of repetition, just that by its nature it shouldn't be repetitive.

I think we're just using different meanings for "repetitive" and perhaps some other words and that's leading to apparent disagreement which in actuality I doubt we have.

I was speaking generally i.e. not about automating your build/deployment/bootstrapping pipelines or building/using a library to solve problem X, but about the process as a whole and the more general tasks that go into that process. In that sense of repetitive, i.e. a set of tasks like "building the login", "integrate 3rd party API", "deliver mail", "build a chair" etc. I think virtually all jobs are very repetitive. In the sense of repetitiveness I think you are talking about, i.e. programming the exact same function every single time you need that functionality in a new app, I would agree with you.

Anyway, my point was jobs are about performing a specific set of repeating tasks - generally speaking :). Further, we've poorly designed the labor supply side of our medical systems given the set of tasks doctors are required to perform and we could allocate supply/demand better and innovate at a higher rate were we to remove some of those systems engineering errors.

>In that sense of repetitive, i.e. a set of tasks like "building the login", "integrate 3rd party API", "deliver mail", "build a chair" etc. I think virtually all jobs are very repetitive. In the sense of repetitiveness I think you are talking about, i.e. programming the exact same function every single time you need that functionality in a new app, I would agree with you.

I'm talking about both.

IME either you're building a really simple login system in which case you can use an abstraction that makes it really quick to build, or you're building a complex login system with subtle requirements in which case it requires creativity and judgment.

Where software development gets repetitive is when people end up building the same abstractions again and again and again (Java devs seem notoriously prone to this, but they're not the only ones) or (less controversially, which you alluded to and are absolutely right about) when steps in the bootstrap, development, testing & deployment pipeline are manual.

I don't think the fact that I've done hundreds of login systems during my career means that I have a repetitive job. They were all either unique in some way or they were bog standard and I created them with a cookiecutter script in < 30 seconds.

Well, here in Europe better have some university degree, to get through HR.

Yes, quite a few people don't, but chances of getting a job quicly diminishes.

Having studied in a technical school before appplying to university, I really saw a difference between both skill levels in what I was capable of achieving.

Even CRUD applications might need some CS knowledge to properly implement business rules that don't take days to finish execution.

> Nobody fails CS101 because they can't remember the syntax of function definition, they fail because they can't figure out which functions they need to write to make a ball dance across the screen.

In my experience that isn't that case. I TAed CS101 while I was in grad school and there were a lot of folks that had a really hard time with the concept that a missing semicolon or comma would make the program not work. I heard: "why doesn't it just know what I mean" more then I would have thought possible.

I think learning the strictness and structure of programming is actually harder then you think when people have never done it before.

Why do we embrace the strictness and structure of these languages? Why aren't a line break and a semicolon equivalent?

Learning may be easiest in a scripting language like Powershell, where all libraries are loaded by default and semicolons don't matter. Errors like missing commas are often pointed out explicitly in the error message. The JIT nature of the console allows for very agile learning. For any given operation, there are usually at least 2 ways to do something. Variable types are optional and very flexible. Finally, the help system can auto-build a rudimentary help page for any function, even custom functions you've written with no help section, giving a basic idea of inputs and operation.

Why do we embrace the strictness and structure of these languages? Why aren't a line break and a semicolon equivalent?

Because, to put it bluntly, that's just how the machine works. The language uses semicolons to delimit statements so that you can break long statements across multiple lines, or have multiple statements in one line. They are very similar in function to full stops and semicolons in English (which is coincidentally another language where newlines and semicolons are not equivalent.)

"But why can't it just figure it out?", you ask. Look at the "automatic semicolon insertion" rules in JS for an example of how trying to "make it easier" only leads to more complexity and confusion.

The "strictness and structure" is inherent in the way computers function, and I think getting used to and even embracing it earlier rather than later is very important for being a successful programmer.

From personal experience, Powershell syntax is quite frankly ridiculous even for an experienced programmer, nevermind all the "behind your back" things it does that leads to subtle and very confusing bugs (especially around character encoding)...

Both Powershell and Javascript are "curly-bracket" type languages. Yet semicolons are only mandatory in one. Why?

(Powershell can have nightmarish encoding problems. "Why did my file change from UTF-8 to "UTF-16LE BOM"? Is that why Powershell can't read the file?")

PS is meant for interactive use, which is why using the newline to terminate statements makes sense (and then they had to introduce another separator for multiple statements on a line, along with a way to break up a statement across multiple lines.) JS is not.

The amount of PS "semicolon vs newline" discussions and articles (as well as those about JS's ASI) shows the downside of this additional complexity and the confusion it causes --- contrast this with C or C-derived languages like Java, where the only statement terminator is the semicolon (and block statements end with }.)

In general, you can see languages designed with interactive use as a primary goal (bash, cmd, PS, Python, ...) tend to also use a newline as a statement terminator.

Because the rules for parsing it would be more complex. That would be an exercise for the student: How would you describe the rules? Then the teacher would show them all these edge cases they haven't considered, taken from real programs so that they don't complain its a contrived example.

> Because the rules for parsing it would be more complex.

The rules for parsing this are already so complex that many humans don't grok them; only computers do.

This is very interesting. Assuming these students are reasonably capable at problem-solving in general, what would account for this helplessness with regard to programming specifically? Off the top of my head, I can guess at a couple of reasons:

1) Programming languages are superficially like natural language, so the students unconsciously assume they are working with an intelligent agent (and if it is taken to be intelligent, then it seems to be a deliberately difficult one.)

2) Error messages often point to the code following the actual error, which again seems to be deliberately deceptive.

Were those students learning with a homogeneous environment with IDE / modern editor features?

I don't think I completely disagree with your overall point, but:

> Nobody fails CS101 because they can't remember the syntax of function definition

I knew a couple people who cited essentially this reason as why they dropped their CS major: they found it really difficult to write anything that even compiled and couldn't deal with syntax errors like missing semicolons and whatnot.

I've seen this too. I think some people are allergic to caring about details the way programmers must. Few other endeavors punish a wayward keystroke like this one.

Maybe that's a reasonable weed-out technique. How is somebody who's frustrated by an errant semicolon going to feel when they have to debug an ancient service mishandling UTF-8 characters? Until we teach machines to program for us attention to detail is just part of the job.

Interesting, I suppose I was fairly insulated from that experience as a TA for a class taught in Scheme. Perhaps that's part of the reason why it's such a good pedagogical language -- it's easy to resolve syntax errors and easy to debug obvious logical errors (e.g. invocation of a non-function) via powerful stepper tools.

Yeah. On pain of being a Smug Lisp Weenie: syntax sucks and shouldn't get in the way of logic. If your only syntax is parens and it directly maps the underlying logic (especially in pure-ish functional programming) then syntax errors just drop away.

I write Clojure and Python mostly. And while the former is overall more difficult than the latter, I never get anything like a syntax error in the former and often do in the latter (eg silly stuff like forgetting print is just a function in 3)

The root problem is that CS is owerwhelming if you don't have already some toy programming under belt.

Basically those people miss general basics we learned younger and then it is too much at the same time.

Teaching CS is hard but I think the root of it is our ability to teach people how to think. Learning to program is easy compared to the problem of learning how to think algorithmically.

IMHO this is because a lot of CS courses start at a very high level with very abstract concepts, which might also be because they can't afford to start with the very basics of "how does a computer work" due to the limited time available.

On the other hand, I think CS should always start with a book like this one, which truly does start at the basics:

https://www.amazon.com/Code-Language-Computer-Hardware-Softw...

A large part of why beginners fail is because they expect too much of, and don't comprehend, how the machine works. I believe that once they see how this complexity is actually the result of a large number of very, very simple operations, they will have a better understanding of what it means to instruct the machine.

> Teaching is not the problem. Anyone can pick up a free online book (I like to recommend SICP or HTDP) and learn everything they need to be a professional programmer.

That is true, and it is a very good thing indeed.

However IMHO there is an important thing missing: Feedback for your mistakes. This is something that every good education should have: an examination of your results, and feedback on what to do better. Especially in CS, it is very easy to produce something that technically works, but is error prone, fragile, inefficient, broken, hard to understand or maintain, etc... These are all things you do not learn without human feedback.

Technically you can give that human feedback to yourself, by reading the stuff you wrote 6 months earlier. That takes at least 6 months for every iteration though :-)

> they fail because they can't figure out which functions they need to write to make a ball dance across the screen.

It's not like the community agrees on those functions, either. Problem division methodology varies across paradigms, communities, and individuals.

Teaching CS is hard because you have to pretend, for a while, that there's one way to do it, and get to alternative representations later. Like in dynamics how they always start off teaching the Newtonian formulation, and only add Lagrangian and Hamiltonian later. Related to this is the possibly substantial tooling problem a student can get into left to her own choices: a teacher's other big contribution is synthetically (but usefully) limiting your options.

(Which gives me an idea for a programming environment which only lets you use features you've demonstrated you understand. You demonstrate understanding by writing tests that reach 100% of some characteristic code, as measured by a code-coverage tool...)

I know Racket (the Scheme dialect of HTDP) provides n-number of sub-languages which have various features disabled. If I recall correctly the lowest level has no loops at all, the second only has recursion, etc.

So true - a lot of people seem to really struggle with the connection between the code that goes in and the behavior that comes out.

I have a theory about this - it happens because we haven't found a way to teach kids about the connection between human effort and software created as a result of work. A huge amount of a child's education at all ages is learning how things are made. As they grow up, kids are naturally exposed to information about how the interesting things that surround them in the physical world are manifested. Buildings are erected with construction equipment, which are made in factories by machines and workers with tools. Food is made by growing and processing ingredients, which come from farms. Roads are created by construction workers with plans and maps and big machines. Society works because people do things and make things and organize things. Look in any kids book with lots of pictures and you'll see what I mean.

But software is different. Construction of software is not physical or visceral and so we can't really show kids how it's made, and most software that people actually use is so vastly complicated and visually oriented that we can't make a connection between it and simple logical concepts that kids can understand (following directions, "if" statements, "while" loops, etc.) The result is not only magical thinking, but a belief that most/all software just magically springs from the void. I've had many conversations with people who never stopped to consider that all the stuff they use on their computer was actually created by people who thought it up and then made it happen - that it's a result of human effort.

By the time people reach the age where they can learn this stuff, the empty area between "effort" and "working software" is so baked-in that they can't even comprehend that they can make computers do new things by thinking and working.

Generally agree, and I see the 'empty area' you're talking about. I see it because I didn't experience it, and have taken years to really grok that there's a small handful of folks who start early. As much as I get pushback on it, learning programming is, imo, similar to learning another language, in that the earlier you start, the more natural it may seem. I started programming at age 9. It was really hardly 'programming' - mostly typing in code from books and magazines to start, but within a couple years I was writing my own stuff. I'm sure it was mostly crap, but I've been able to think about loops, variables, arrays, stacks, subroutines/functions and other concepts for... more than 30 years at this point. If someone 'starts' around age 17-18, then has a few years in school (while doing multiple other classes), it's little wonder they may not have as strong a grasp on the basics (missing semicolons, etc) as others with more experience.

> The result is not only magical thinking, but a belief that most/all software just magically springs from the void. I've had many conversations with people who never stopped to consider that all the stuff they use on their computer was actually created by people who thought it up and then made it happen - that it's a result of human effort.

I have to stop and remind myself that about cars sometimes too. There are thousands of parts on cars that all interact together, and people - thousands of people - all studied different areas to learn how to be the best at XYZ to build ABC which fits with 20 other parts to make everything work together when I press a button or turn a key. And... hundreds of others designed the machines that lets those other people build the parts they need. It's sort of crazy when you think about it! (shoulders of giants, etc).

Regardless of the extensive science behind computer programming, I still consider programming a "creative" field. Yes, you do need sound engineering and be able to at least have a working understand some of the computer-science, but there is more to it than that. It also requires the creative ability, just like painting a picture or writing a novel. You need to be able to conjure ideas and take them from theoretical manifestations to concrete implementations. You need to be able to look at a problem and see the way to the solution, like a sculptor can look at a chunk of rock and see a statue.

I think you have a point. The idea that the programming language and its standard library are lego bricks, and you have to find ways to assemble them into something resembling your problem can be hard to communicate.

I've certainly seen people - smart people who'd previously written very complex things in Excel - just go completely blank at the stage when it comes to turn a task into a computer program. You really have to drill the breaking the problem down into smaller and smaller parts stage.

But I'm only partly convinced.

People really do struggle with syntax early on. Not remembering it, but spotting mistakes. Seeing some opaque error message and not having any idea that is connects to a missing ;})] really frustrates people. Especially since your brain is automatically editing away the syntax for you as you read.

Also sometimes it's really hard to convince people that formatting their code sensibly will help them with syntax.

Hi. I work at one of those teaching startups that's growing like gangbusters providing technical training and career assistance.

You're dead wrong: teaching IS the problem. We take teaching really seriously. If you actually start treating it as a measurable discipline with outcomes defined by students getting jobs and succeeding, a lot of things that are fuzzy come into focus.

What exactly are you disagreeing with?

The idea you can just 'pick up a book' is absurd. Most folks don't have the resources to devote hours to study every day to acquire new skills. Of those that do, only a subset also has the will.

Unless your startup is teaching programming via brain implants I'm not sure what your contention is. Yes, you need free time to develop new skills. They couldn't rightly be called skills otherwise.

> Teaching is not the problem. Anyone can pick up a free online book (I like to recommend SICP or HTDP) and learn everything they need to be a professional programmer.

This is very obviously false when you look into the data. It's as false as saying, "Anyone can get a gym membership and stay in good health." It's just not accurate or true, it glosses over a lot of things that should not be glossed over.

That sounds like something somebody trying to sell me a $200/month Equinox membership would say. Sure, maybe some people learn better with mentorship or structured classes -- but those generally cost money and/or more time. The important thing is the resources are out there: it's an amazing thing that you can become a talented engineer entirely through self-study. How many fields can you say that about?

Is it really amazing that if you spend 10x the time you need to you can become as good as someone e with a good guided study program?

That seems very normal to me.

But sure. Evidently now working in education is a conflict of interest to education. Right.

10x seems like a clear exaggeration -- but that would depend on whatever the "good guided study program" costs. Especially since I know many bootcamps that cost thousands of dollars to churn out unemployable developers.

If I look at what I did without a boot camp it's more like 50x.

I've been at this since I was 6 and I'm nearly 40. For something like web app development I'm not sure I really have a 50x advantage over someone who went to a specialist vocational camp.

Agreed. I'm learning math right now and similarly the hard part for me isn't memorizing the rules/properties but trying to build an intuition on how to combine these truths to infer other truths in order to solve harder problems.

Reply on news.ycombinator.com