
Why Johnny Can't Code Good [video] - coolsunglasses
https://www.youtube.com/watch?v=2xyZeovFqCA
======
WoodenChair
A lot of hate in this presentation and a lot of generalizations. There are
fantastic programming books. There are colleges doing a fantastic job teaching
computer science. Making broad generalizations without solid statistics to at
least back them up is usually not helpful.

~~~
jszymborski
I'd agree... there is a lot of toxic gray-beardery here.

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.

~~~
ashleyn
I remember BASIC was the subject of regular derision from experts. Nothing
helped me get interested in programming with such a gentle learning curve as
BASIC. Where it lacked in every other area, it excelled in making programming
accessible with immediate results.

~~~
jszymborski
Visual Basic 6 got me hooked in grade school... nothing more rewarding than
being able to write a GUI app and short little games in minutes :P

------
ng12
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.

~~~
jonawesomegreen
> 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.

~~~
stephengillie
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.

~~~
userbinator
_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)...

~~~
stephengillie
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?")

~~~
userbinator
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.

------
stephengillie
Video is 48 minutes, and in a format I find very difficult to follow and stay
engaged. Here are the bullet points from the slide deck:

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.

------
KirinDave
It's really unfortunate that this is what's passing the bar as a non-technical
talk at /\C. Some of the LC talks are given by brilliant people, but talks
like this make me think they've got a very weak review process for management
talks or business talks.

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.

~~~
coolsunglasses
>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.

~~~
KirinDave
Chris, you called my wife stupid because she was pregnant and said the reason
I was supportive of women in the industry is because her stupid pregnancy
hormones splashed on me, because I was being stupid.

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.

~~~
coolsunglasses
Holy shit what? The last memories I had of interacting with you that could be
related to what you're talking about:

\- 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...](https://twitter.com/search?f=tweets&vertical=default&q=kirindave%20bitemyapp&src=typd)

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!

~~~
damncabbage
> 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 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](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.
    
    

That covers a portion of the claim. (I'm trying to stay out of actually
passing judgement on bitemyapp or his ">"-quoted defence or KirinDave's
earlier claim.)

~~~
coolsunglasses
I don't think it needs judgment passed, that was shitty! Thank you for finding
this.

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.

------
asciimo
As comments on the video are disabled, I'll state here that this guy's body
motion was making my dizzy. I had to occlude him with another window to watch
the video.

~~~
revelation
Yeah, they certainly don't teach presentations anymore. Stop moving side to
side!

------
codyb
I completely agree. Whether or not he's gatekeeping a bit by shitting on Go
and JavaScript, and whether or not he's promoting his book about haskell.

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.

------
Alex3917
In my experience, the fundamental reason why most programmers are bad is
because they don't have experience running real companies. The ones who do can
consistently make the correct technical decisions almost every time even they
have zero knowledge or experience with whatever problem they are trying to
solve beforehand.

