Why Johnny Can't Code Good [video]
youtube.com
youtube.com
I've been to a few meetups that Chris was present at and I have to say I was always somewhat surprised that he fancied himself a great teacher because I've found him to be impatient, condescending, and completely lacking empathy. I don't mean to say he's impossible to learn from (I am aware of people who site him as a reason they know some topic very well), just that in my experience teaching hundreds of people of varying skill levels he is not someone I would put in front of students.
His argument for why he dislikes Go and Javascript is ostensibly "they are easy to grok"...
I don't think this presentation was made out of ill-will or spite, but I think this presentation leaves little room for the mediocre; and frankly if a field is devoid of mediocre performers, you end up with a handful of gray-beards in a code cloister.
This is where, I think, the programmer mentality and the human empathy understanding are out of balance, and lead to false truths about how humans ought to behave.
I sorta like his point about contributing upstream, but again, I think that he neglects the fact that that isn't a straight-forward process to someone new to a language. He brings up that "the Rust community is welcoming", but (a) that doesn't really apply to most communities and (b) especially when you're just starting and haven't had too much exposure, you probably haven't witnessed (or realise you have witnessed) a bug in the 4 (often mature) standard libraries you regularly use.
I like Chris, and he’s clearly a smart guy, but he’s not a person that pedagogical lessons should be learned from.
The book he wrote is a good example - and I enjoyed the book and recommend it. But it’s full of him using big words because at times he can, almost showing off, not because he should. I liked the book, and am glad he teaches the fundamentals of the lambda calculus, but it is very particular to Chris’s style, and that makes it the best programming book written in his eyes, despite not being the “best” programming book objectively.
I've no idea whether he thinks it's the only good Haskell book (do you have a reference for him claiming that?) but there is a sizeable segment of the Haskell community that considers it the best Haskell book. (I've never read it, personally.)
It would be surprising if it were otherwise given its origins and age.
My beliefs are getting seriously distorted in this thread.
That's not a fair characterization. While it was not elegantly posed, the argument was in essence "these languages optimize for ease of adoption instead of power". It's objectively true that go and javascript deliberately aren't able to do a bunch of things that a language like haskell can. Different choices were made. That doesn't mean that go and javascript have no place in programming, since we definitely need languages that are easy to get started in to on-board new people. However, the question is whether it's right that those languages then end up being people's choice for the rest of their professional career. A programmer is more likely to grow when using tools that enable growth.
On the other hand, while I haven't written haskell, I have written a bunch of scala and C++, and both suffer from an excess of syntax. In both cases skilled practitioners learn to ignore some of the language features, to ensure their own sanity when maintaining those code bases later on. There is something to be said about having a language that doesn't allow wizardry when viewed through the lens of maintainability. From what I understand that is go's design.
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.
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.
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 :-)
> 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 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)
Basically those people miss general basics we learned younger and then it is too much at the same time.
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 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.
> 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).
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.
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.
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)...
(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?")
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.
The rules for parsing this are already so complex that many humans don't grok them; only computers do.
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.
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.
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 seems very normal to me.
But sure. Evidently now working in education is a conflict of interest to education. Right.
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.
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.
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 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.
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.
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.
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.
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.
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.
Who's Johnny? - Can't create something without examples. - Almost never upstream patches to what they use. - Industry's definition of a healthy ecosystem wrapped around "Johnny".
Extreme Time Preference. - Problems in software are not 0-60 times. - Optimized for triviality.
Can't Hire Out Of This Problem. - We don't know how to interview well. - Many interview practices are odious.
"Hire Only The Best." - Complete nonsense. - Nobody can sustain being extremely picky about their hires. - Everybody else "hires only the best". - This isn't a plan, it's a mantra. - There's no competitive advantage here unless you have a lot of money and are willing to churn your hires. - Burn & Churn doesn't select for experienced employees. - Doesn't charm them either.
What We're Unwilling To Admit. - Much of our work is boring and easy. - Some find a niche and are not often obligated to skill up. - Might learn new tools, but don't develop in a lasting and general way.
Coders Don't Know How To Learn. - Never learned how to learn properly. - Can be difficult to get programmers to eat their vegetables. - Knowing is not the same as ability.
Coders Don't Know How To Teach. - Create false narratives around how they learned. - They recommend books, resources intended to project [or increase their own] prestige more than to help the student.
Teaching Is A Skill. - Takes practice. - Almost everyone is bad at it for quite a while. - Without expertise, extremely unlikely to be successful. - Students won't tell you they don't understand forever.
Teaching: Topics. - They teach topics that have prestige associated with them. - Not covered: skill building.
Teaching: Methodology. - Talking isn't very useful. - Dialogues work best as remediation/unsticking.
Teaching: Time - Difficult to parachute in for an hour a day. - Can't do much with that time without foundation of work.
Software Is Bad At Writing. - Very few books go through substantial review. - Fewer act on it in a meaningful way.
Programmers Are Literate But Can't Really Read. - Like not being able to retain a novel in your mind. - Can't incorporate mental model of what they read. - Stunts growth. - Writing checks their knowledge and skills can't cash. - Perpetual rediscovery of idiom.
Employers Aren't Doing Their Part. - Expect highly skilled programmers to drop out of the sky. - Substantive on-the-job education or training is rare.
Training Makes Business Sense! - Training is software moneyball. - [Photo of a person not recognized by transcriber.]
Company Incentives - Programmers (rationally) change jobs. - Companies aren't often keen on investing deeply into training. - Conferences are about it, actually.
Training As A Culture. - Wouldn't you rather work at a company that invests in the training of its people? - How much easier would hiring me [be] if your company had an uncommon reputation for internal training and education?
Anthony Grafton. - [Photo of a person not recognized by transcriber.] - Recently listened to a talk of his about the history of books, reading, and digitzation. - He has concerns about how people read today. - I share his concerns. - I strongly recommend Grafton's "Codex in Crisis" talk at Google.
Programmers Are Illiterate. - It's worse than the situation with books and broader society. - We're an amnesiac culture.
Learning To Read Code - [Photo of Haskell Almanac book.]
Make A Mess, Clean It Up! - [Photo of a person not recognized by transcriber.] - [URL http www folklore org]
[Video from *Defender: 1980 Classic Arcade Game"]
Don't Train How You Play. - Train harder, be more focused and structured.
After watching it and taking some notes, the biggest problem with this talk is that he loads a bunch of untrue and unfair garbage up front to pander to the local culture of dismissive shitbirding on everyone else outside of the room.
Skip to 22m in to skip all the predictable Chris-Allen-makes-fun-of-everyone preamble and get to the meat of his talk, the substance of which I agree with.
For those who can't stomach it even at 3x speed the way I just powered through, I've got a summary:
- Businesses make bad decisions about the longevity or sustainability of their business practice. They're compose of directors and VPs trying to work on a quarterly OKR schedules for wins to justify their outrageous 200k-250k salary options, so it's a vicious and competitive environment.
- Businesses then try and skip the part about building a sustainable tech org by appealing to, "We hire the best." This is expecting great engineers to parachute in from Valhalla to go to war for you. It's unrealistic.
- Between this style of technical evaluation and absurdly fast product cadences (all free of consequence, no liability expressed or implied), organizations don't feel they need to care too hard about building deep skill in anything but their most core business interest because most of the work is "trivial" (and to his credit, Chris includes a lot of his own work in this).
- Businesses could actually improve infrastructure to eliminate this trivial work, but this requires more sophisticated tools, techniques and designs and these are considered risky.
- This is then used as a justification to remove all technical mentorship and tutelage from the system and only hire specialists.
- And then the industry forms a tight orbit around tools and practices that are deleterious to anything but a short-turnover org like the modern Google.
And for the record, Chris is one of those folks in the community who's made a reputation for being dismissive and cantankerous. It's his natural personality to make even good and insightful points like this hard to watch.
It's too bad the lambdaconf folks didn't give him feedback to just cut his talk in half. If he had started at 22m it would have been a HELL of a talk. Instead he needs to erect an effigy and shove it in a wicker man with bees to appease his (and perhaps his audience's, given the laughter?) love of punching down on folks with less formal CS knowledge.
I care more about practices and tools, really. Stuff like being comfortable with patching a library, reading the code you use. I don't have any formal CS knowledge, no credits, no degree. I don't really understand type theory beyond the basics of cardinality and whatever I had to learn for the book.
It's a shame you dislike me so much, we very much agree on things like the value of training and education.
This is not the way to make friends and influence people. Still, I've given you as fair as shake as I can. I'm not the only person who found the first half of your presentation to be off putting. Unlike them, I extracted some of your key points and laid them out in a tl;dr.
> Stuff like being comfortable with patching a library, reading the code you use.
This is where our agreement diverges. Many people will not or cannot engage the open source world. Given how many folks don't use licensing, I'm always skeptical of working for them for free as well.
- You talking to me about potentially working at your company
- Soliciting pictures of your greyhounds
- Congratulating you on either the pregnancy or the birth of your child
I checked out our shared Twitter history, we talked a fair bit in the past but I wasn't able to find _anything_ like this. I used this search: https://twitter.com/search?f=tweets&vertical=default&q=kirin...
I mean this sincerely — are you _sure_ you didn't get me confused with someone else? I was definitely a dick from what I can see from the Twitter history and I apologize. However, I cannot remember and cannot find myself ever saying or implying something as horrendous as what you're describing here.
>This is where our agreement diverges. Many people will not or cannot engage the open source world.
Oh! Don't need to! People use OSS regardless of engagement with the wider community. I'm talking about stuff people do on their work hours like vendoring a library and upstreaming a patch. I'm not talking about off-hours. For people that are uncomfortable with or contractually unable to upstream a patch, knowing how to hack on the libraries you use is still a big improvement. Many don't!
> I mean this sincerely — are you _sure_ you didn't get me confused with someone else? I was definitely a dick from what I can see from the Twitter history and I apologize. However, I cannot remember and cannot find myself ever saying or implying something as horrendous as what you're describing here.
https://twitter.com/bitemyapp/status/477359528510382080
[@bitemyapp] @KirinDave my first workflow video is up to
1,535 views on Youtube so far. Who knows how many people
have used my guide. I'm feeling good.
[@KirinDave] @bitemyapp It is not about your traffic, it is
about their excitement. Get over yourself.
[@bitemyapp] @KirinDave Drinking the haterade tonight. Some
of those pregger hormones transfer over?
Should ramp up theft of Clojure library authors >:)
[@KirinDave] @bitemyapp Yeah I'm hysterical that's real cool.
Dave: I was out of line and there was no point for me to be dick-waving with you like that. I can't say it's possible for me to read everything you did into what I said, but it was a shitty thing to say regardless. I apologize.
> absurdly fast product cadences
Just curious, what do you consider absurdly fast?
I totally agree. It's when I'm lost that I've learned the most.
I've very frequently thought of myself as overpaid, I've come to the conclusion that it is tenacity which makes me as well paid as I am.
The worst parts about being a software engineer are setting up development environments, thats a hurdle a lot of people break on before they cross over.
When it's that single fucking space that breaks your jQuery code and you can't figure out why your code isn't working, but eventually you realize you didn't put that space between the id and class, that's a hurdle people break on before they cross over.
When it's the fact I spent ten hours already this weekend building a god damn gulp file with literally zero visible results to anyone but me, thats a hurdle people break on before they cross over.
So maybe I don't agree actually, maybe I think tenacity is what allows us software engineers to do what we do, or at least to get where we are, I definitely agree that people a lot of engineers I work with are very hard pressed to break out of their defined boundaries.
I've always been that person, and I've never been that person. I always take on projects I know nothing about, but when I'm sitting there looking at a blank file I often find it extremely difficult to figure out what to do.
Reading code is _hard_. It's unbelievably hard. And languages like Go which I've never worked with promise to make it easier through their reduction in the possible pathways one might do something. Compare that to Ruby where there is literally almost always at least two different ways to write the same exact piece of code. Or compare that to C where you're literally allocating and deallocating pieces of memory for your data structures.
He is absolutely right in that A) teaching is very hard B) employers shouldn't expect gods gift to mankind to people to be the only people they'll hire
But in a world where the average retention rate is as low as it is, should employers invest more in us?
He's right that civil engineers go through a lot more than we do to call themselves engineers, but are they dealing with architectures frequently featuring tens of millions of interacting features (lines of code)?
So while I have come to literally no conclusion here, I wonder, is he right that doing things ends up being far more valuable than reading about them? I sort of think so because I just spent ten hours on a gulp file which will show no gains to anyone except myself, but I also read four articles on how JavaScript works at the engine level this morning and plan to apply those principles I learned both to my own code and to code reviews in the future.
At the end of the day we should all discard what is cruft to us, and learn from what is not, and it will be different for all of us.