13 ms·

Why Johnny Can't Code Good [video]

WoodenChair 9y ago
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.
- throwaway999111 9y ago
  This is par for the course with Chris. Super strong opinions about things with little room for those of anyone else. 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.
  - stephengillie 9y ago
    Has this feedback reached Chris? How did he react?
    - rowtype 9y ago
      He knows. And he reacts with rage. If not aimed at you, then at someone. Saw him take it out on Julie a number of times while they were working together.
  - dustingetz 9y ago
    I learned quite a bit from Chris, particularly his comments on HN and reddit, which he poured tons of time into over a couple year period. Very few people devote that level of time to answering questions in depth.
    - deleted 9y ago
      [deleted]
  - alexeyzab 9y ago
    I've known Chris for a few years now. During this time I've asked him many questions, worked with him on projects (open source and otherwise) and I have never seen him act the way you describe it here. Moreover, I've also seen him talk to and teach people at conferences. He has always been very patient and helpful, encouraged people and nudged them in the right direction when they were stuck. Of all the teachers I've interacted with throughout my life, Chris definitely fits in the category I want to learn from. Like someone else has mentioned before, I encourage you to provide constructive feedback to him directly, he cares about teaching and does want to improve.
- jszymborski 9y ago
  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.
  - qyv 9y ago
    His dismissiveness of other languages is startling given the topic of this talk. The first step in learning is realizing that you don't know everything. To me the COBOL example is the most telling, he literally says there is nothing to learn from COBOL.
    - throwawaaayy 9y ago
      He’s a Haskell purist and (for lack of a better word) religious about it. He’s written what he thinks is the only good book in what he thinks is the only good language, so that tells you a lot about how he thinks. He views the world with a very rigorous set of particulars around what is “good” and what is “bad,” and because others don’t agree with those very specific particulars he considers everything else “bad” or “lazy.” 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.
- qudat 9y ago
  Agreed. The general vibe I got from his presentation was most people that call themselves professional programmers are living in a fantasy land. It reeks of the trope that "my programming language is better than yours."
ng12 9y ago
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.
- jfaucett 9y ago
  > 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.
  - crdoconnor 9y ago
    >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.
stephengillie 9y ago
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.
asciimo 9y ago
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 9y ago
  Yeah, they certainly don't teach presentations anymore. Stop moving side to side!
Alex3917 9y ago
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.
KirinDave 9y ago
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 9y ago
codyb 9y ago
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.

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.

throwaway999111 9y ago
This is par for the course with Chris. Super strong opinions about things with little room for those of anyone else. 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.
- stephengillie 9y ago
  Has this feedback reached Chris? How did he react?
  - rowtype 9y ago
    He knows. And he reacts with rage. If not aimed at you, then at someone. Saw him take it out on Julie a number of times while they were working together.
- dustingetz 9y ago
  I learned quite a bit from Chris, particularly his comments on HN and reddit, which he poured tons of time into over a couple year period. Very few people devote that level of time to answering questions in depth.
  - deleted 9y ago
    [deleted]
- alexeyzab 9y ago
  I've known Chris for a few years now. During this time I've asked him many questions, worked with him on projects (open source and otherwise) and I have never seen him act the way you describe it here. Moreover, I've also seen him talk to and teach people at conferences. He has always been very patient and helpful, encouraged people and nudged them in the right direction when they were stuck. Of all the teachers I've interacted with throughout my life, Chris definitely fits in the category I want to learn from. Like someone else has mentioned before, I encourage you to provide constructive feedback to him directly, he cares about teaching and does want to improve.
jszymborski 9y ago
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.
- qyv 9y ago
  His dismissiveness of other languages is startling given the topic of this talk. The first step in learning is realizing that you don't know everything. To me the COBOL example is the most telling, he literally says there is nothing to learn from COBOL.
  - throwawaaayy 9y ago
    He’s a Haskell purist and (for lack of a better word) religious about it. He’s written what he thinks is the only good book in what he thinks is the only good language, so that tells you a lot about how he thinks. He views the world with a very rigorous set of particulars around what is “good” and what is “bad,” and because others don’t agree with those very specific particulars he considers everything else “bad” or “lazy.” 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.
qudat 9y ago
Agreed. The general vibe I got from his presentation was most people that call themselves professional programmers are living in a fantasy land. It reeks of the trope that "my programming language is better than yours."

ng12 9y ago

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.

jfaucett 9y ago
> 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.
- crdoconnor 9y ago
  >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.

stephengillie 9y ago

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.

asciimo 9y ago

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 9y ago
Yeah, they certainly don't teach presentations anymore. Stop moving side to side!

Alex3917 9y ago

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.

KirinDave 9y ago

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 9y ago

codyb 9y ago

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.