Hacker News Reader

Comment by mafribe | Hacker News Reader

I teach computer science at a well-known, large and mediocre university.

I see bimodal grade distributions all the time. The more technical a subject, the more bimodal the grades.

In fluff subjects like software engineering where grading relates to essay writing and group projects, grade distribution tends to be gaussian. OTOH in technical subjects where I grade by automated test suits, basically students fail almost all tests or pass almost all tests.

These grade distributions have been constant, regardless of university, regardless of who teaches the course.

There really is a sharp threshold that separates those who get programming from those who don't. And those who get programming really are a lot more productive than those who don't get it. Moreover, once you get it, learning further parts of CS (e.g. new algorithms, new programming languages, new OSes etc) is much easier then if you don't get it, and learning new things makes you even more powerful. The mastery of doing great things is joyful and makes you want to learn more. The frustration of failure drives you away from the subject.

I find it plausible that grade distributions turn into similar income distributions later in life.

View on HN

I've held this basic theory for a while, and it seems to explain a lot of things about the state of software engineering.

Most visibly, there's a wild disagreement about whether we have too many programmers, or not enough. Big tech companies consistently say that they struggle to find programmers, while contrarians at places like The Atlantic love writing pieces about how we're education way more programmers than we hire each year, and the bubble is going to burst.

The ultra-cynical take is that companies are trying to drive a crash to drop salaries. It fits with the wage-fixing collusion, but doesn't really explain things like paying massive referral bonuses for new hires.

The more interesting take is that it's about this bimodal distribution. "A degree in computer science" is a pretty amorphous thing, and thinkpiece writers who assume that every CS program produces employable CS-job-seekers aren't going to get decent data.

So I think the explanation might be that CS isn't harder than EE or chemical engineering, but rather less prescriptive. There's a huge range of programs producing "CS degrees", and jobs titled "software engineering", and they're not really describing the same things.

Then the point remains. Why are people who can't code getting the CS or EE degrees?

Generally, the degree is supposed to indicate some sort of sufficiency with development. Probably universities are dumbing down requirements for $$$.

Programming is to CS what telescopes are to astronomy.

Programming Telescopes is what CS is to Astronomy.

>Probably universities are dumbing down requirements for $$$.

I 100% believe this is true. When I was in college it was pretty staggering to see my fellow classmates receive passing grades and get shoveled through the programs despite never grasping the basic fundamentals of CS. These were people who, at the end of CS 101, still couldn't tell you the difference between a string and an int, who after CS 202 _still_ couldn't tell you the difference between a string and an int, and so on and so on. Yet happily through the system they continued.

I eventually became part of the lowly drop-out club (I found attending college later in life to be a maddening experience of pointless busy work, rather than a challenging mind-expanding one). However, those people who fumbled around randomly swapping out types until things compile are now CS degree holders.

It seems true even for the higher tier degrees too. It seems even a masters degree isn't a good indicator. In the past year alone I've watched several guys with masters enter and then promptly leave our startup due to having just absolutely no idea how to write software. :(

I'm on the job market (I do a lot of contracting so I'm perpetually so) and I've seen a slow increase in job listings that specify a degree and exclude "or equivalent experience". Decision makers need to double check what their HR people are posting or they may, emphasize may, end up with a degreed (not in Chrome's dictionary), homogeneous group of type swappers.

Perhaps ironically, don't academic types feel they are enlightened by their education? So requiring a degree for doing the same job one has done for several decades, an exclusionary act; seems to me to be at odds with their open, enlightened views.

I was contacted yesterday by a recruiter for a startup. He said, "you have over two decades of experience doing exactly what we need but our founders are graduates of <fancy place 1> and <fancy place 2> and I think they probably will require someone with a degree.".

I thanked him, I couldn't even remember applying there, I guess he just wanted to reach out and let me know how he felt.

It's pretty silly to require a degree. Like, you only get so many job applicants, and you have to filter them down somehow into job offers, and everything that isn't "how good is their code" ends up hurting how good of a programmer you wind up with.

Granted, sometimes you want to make the tradeoff - there are some truly toxic people with zero professionalism and beautiful code, after all. It's just obvious to me that I'd rather have better code than someone with a piece of paper from a university.

I don't think its that universities are dumbing it down for $$$. It's that they are teaching and testing on skills that are not related to 99% of software development.

I went to University of Texas, and managed to do really well on all the tests and projects without learning how to code. But that wasn't because anything was easy. There were a lot of very tough math, and logic classes that some of my class mates who had been working on open source projects since they were 16 did terribly at. It's not easier skills, it's just different skills.

99% of software development challenges are how do you write/maintain large projects without getting totally crushed by the complexity. This is a skill that no one tries to teach, and is also very hard to teach. Similar to being a good writer, it is very subjective, and CS professors are very uncomfortable grading subjectively. It's also harder to create homework for students than just building out toy projects.

I'm of the opinion that it's both problems in many ploaces.

>It seems true even for the higher tier degrees too. It seems even a masters degree isn't a good indicator. In the past year alone I've watched several guys with masters enter and then promptly leave our startup due to having just absolutely no idea how to write software. :(

is this a problem with degrees or the interview process? How did they get the job without ever proving they knew anything about software?

Well, it's a problem with the degree as a signaling device and a problem with the interview process if it repeatedly produces false negatives of a similar type.

Having a degree doesn't necessarily mean you have a clue about the architecture of software, how to separate data from the GUI, or even have a full grasp of a simple language. I do not have a degree but having worked with degree holders who came to the company fresh from University, I can safely say that some of them hadn't a clue about how to write software (this was C++).

The skills required for writing software only truly come about if set your own project at home and work through it and write it fully.

Is this really true? At Berkeley and other UC schools, the programs are often "impacted", meaning they are looking for reasons to kick people out (or, more likely, deny them entry in the first place). A bad early semester with a C in physics and B- in calculus (not at all uncommon at places with less grade inflation) can spell the end of your CS major. People get bounced from this degree all the time.

Just for the record, I don't approve of this. I'm all for standards, glad they exist, but I think some UC schools are pretty callous in how they treat students. I admire those who get through, but there are plenty of people who would have made wonderful contributions if they'd had just a bit more understanding and breathing room. I think Berkeley wastes people because they know there will always be another 10 lined up to take someone's place.

Can't say I love privates in every way, but really, it's a good thing to try to work with someone who is new to college and struggling rather than kicking them straight to the curb.

Cornell was the same way, our first semester weed-out calculus class MATH 1910 was "curved" to a B- median grade.

At the end of freshman year, everyone who wanted to major in CS had to apply to gain entrance into the CS degree program.

If you got a C in weed-out calculus, you were in troubled academic standing, and you would have to retake MATH 1910 until you got the B-, otherwise you wouldn't get accepted into the CS major.

Other majors had similar, and often less-stringent, degree requirements.

"A bad early semester with a C in physics and B- in calculus (not at all uncommon at places with less grade inflation) can spell the end of your CS major." Which is terrible because the amount of physics a software engineer will use is non-existent.

The group projects of 6 people with one person at computer while everyone else watches for an few hours, then it's done. Four people doing nothing, one person coding, and one person searching the internet for help. Typically the four doing nothing are having an existential panic attack because they realize how useless they are being, or maybe they don't. Who cares? They're about to get an 'A'.

One problem seems to be that a lot of schools have a strong emphasis on group work. Usually there's a ton of non dev work to go along with projects - documentation, whatever paperwork the project requires, so someone can make a useful contribution without being able to code.

So a weak coder can get through the program as long as he can pass the exams.

And this, I think, is why good programs tend to have a known "weed-out" course. If there's at least one course with a focus on independent, code-centered assignments, you can't fake your way through. That forces some students out, and others to shape up and actually put in the effort they might have coasted by without. Programming and hard pseudo-code tasks on exams can play a similar role.

Teaching group work for programming is great. Among other things, it gets lots of side benefits like promoting source control practice and distribution of code tasks. There just needs to be something that consists of "sit down alone and code".

> If there's at least one course with a focus on independent, code-centered assignments, you can't fake your way through.

Unfortunately this seems to be increasingly foiled by an active market in solutions. I've even seen people hire freelancers online to do their programming assignments for them.

Many positions now use behavioral based interviews, and group experience is critical to passing those interviews.

Why are people who can't code getting the CS or EE degrees?

The short answer seems to be: because they're allowed to.

The longer answer has to do with the "$$$" part. Fundamentally, universities aren't in the business of educating people; they exist to sell credentials. Which has some thematic overlap with "educating people", but is still a step and a half removed. And with the long-term transmogrification of universities from "institutions" to profit centers, the inevitable rush toward mediocrity (and widening of the gap between perceived value of said credentials, and their actual value) results.

> Why are people who can't code getting the CS or EE degrees?

Because neither CS nor, especially, EE are "coding" degrees.

Now, if you want to code CS (and for certain domains, EE) can help you become a much better coder, but that's not really the central focus of the degree. So they aren't irrelevant as qualifications for coding work. But neither are they, on their own, qualifications for such work.

I think you hit the nail on the head. There isn't really a need for a lot of companies to hire a CS degree.

Wordpress management? You can hire a Jr PHP developer and be fine. They don't teach PHP in school.

Need someone to manage your non e-commerce website? Web Developer. Again, not something they seem to teach CS majors but the title could say Web Developer or Front End Engineer

When I took a glance at the job market, most jobs didn't really need anyone who studied Boolean algebra, discrete math, how digital and analog interfaces work, big O notation etc etc

With the advent of companies like Weebly, Shopify and others you don't need to have an engineer with backend experience(which most CS teach) so you end up hiring a "developer" but the same title exists at Google and they want people who understand computer science.

So we're left with this fractured market where it's not clear from job posting to job posting what is actually wanted.

What I found even worse in the job market is that the job requirements say CS Degree but the job description doesn't match.

I've ended up going to University to get a degree because I was being screened out of job applications before my experience counted for anything.

Mind if I ask where you went and whether you found it valuable (in terms of both knowledge gained and screens passed)?

I'm doing a degree in Supply Chain Management focusing on Computational Logistics.

I really didn't want to sit through a CS degree either learning stuff I know already or stuff I know won't be much use in industry.

So I chose a tangential discipline and am enjoying it thoroughly, being a bridge between Operations and IT provides real value to an organisation.

Blended professionals FTW, (almost) every time.

(not speaking to parent poster, but instead generally) Were you a foolish humanities student when you got your bachelors? Worse, did you take it seriously and actually learn something? Great! Now study a technical discipline and blend away. IT is increasing the depth breadth and profitability of these blends daily.

> Were you a foolish humanities student when you got your bachelors?

Yes :\

> Worse, did you take it seriously and actually learn something?

Yes :(

> Great! Now study a technical discipline and blend away.

This is a much better perspective than my usual one. Thanks!

Make sure you pile on the private software projects: without the CS degree, they're gonna want either experience or some proof you can code.

Ironically, plenty of tech departments hire guys who are skilled first rather than having some intrinsic interest in the area they program for. Believe me, some old school companies will hire a CS grad who couldn't spell supply chain over you in a heart beat.

Maybe it's different outside the bay area, but it almost never comes up in interviews much about my passion/prior work experience for _____ they build. Reminds me of a guy who went to work for Tesla expecting a bunch of people pumped to expand green energy only to find guys who couldn't care less: they were hired on technical acumen first, enthusiasm for environmentalism last.

It's more about model building than out & out coding. Papers are algebra and describe clever heuristics. The main issue seems to be marrying the theory and practice.

I am building direct industry experience rather than filling GitHub.

The backend of sites like weebly or Shopify are kinda limited....and peeps who earn a ton of money on those sites have all sorts of ideas on how they could make more(usually need some extended back end work or at least buying a pricey add-on).

Let's seperate tech companies with an e-commerce side and straight up traditional vendors leveraging the internet to increase sales. Backend engineers are critical in the former and very useful mainly to those who have specific needs in ecommerce(many vendors don't even have a clue where to even start). Usually they just outsource the whole project to a third party web dev/design firm or some I.T. guy in-house.

It's worth noting, many older business folks are truly clueless about ecommerce....I tell every client to start with ebay or amazon or etsy but they insist a pot of gold awaits when their website goes live. THey'll need some type of web related worker(design, developer, etc.).

> .. and they're not really describing the same things

I'd apply this to the other end of your argument too. The reason there's wild disagreement, i.e. "too many programmers, or not enough" is that they're talking about very different things.

There is no linear scale between "can't code" and "great programmer". Anyone smart enough to be a great programmer should understand very well that no system is that simple; especially one involving people.

On the personality side, you have pioneers, early adopters, people who are comfortable being in the wild, out of their depth... and you have town planners, who like to optimise systems they understand already... and in the middle settlers, who are best when taking innovations and promoting them to a wider audience. In a large software organisation you need ALL THREE types, because they all fulfil important functions.

There are similar differences in terms of learning style, ambition, network, experience, confidence, bias, and luck.

Putting people into buckets like this is ill-advised.

I don't think the conclusion follows from the data. It's not implausible that in computer science you need to "get" a whole bunch of things before it clicks and you start being productive, and a bimodal distribution of grades would then be indicative only of people who are further along in the learning process vs. those that have not yet reached that critical point, rather than any huge difference in intrinsic ability. This is just speculation, of course, but so is any other explanation and I prefer giving people the benefit of the doubt.

I agree, I don't think there is much difference in intrinsic ability. I'm absolutely convinced that every healthy person can become a really good programmer.

But becoming a really good programmer requires putting in a lot of time doing programming, and a lot of students don't put in that time.

Well, if you enjoy something, it's much easier to put a lot of time in to figure it out.

For example, I became a software entrepreneur about five years ago making money from my own projects. Dealing with a lot of business related "work", I actually discovered I also really like law, in particular tax law.

A friend of mine was a pretty good lawyer (hung up his hat to do more entrepreneurial stuff) and I occasionally ask him to look over contracts I've drafted. He said some of the contracts I put together are better than what some of his colleagues put together. I've also defended myself in a few tax disputes with legal arguments, and always won. If I knew more about it before, I think I would've genuinely enjoyed being a lawyer.

If you enjoy something, it's not that hard to become really good at something. If you don't, it is extremely hard to become better than the guy who loves what he does.

I think the question of whether anybody can get good at programming is very interesting. I often hear "anybody can do it, but you can only become really good if you enjoy it".

So then the question is: why do you enjoy something? Are we born that way, or is it something we do? (I don't know what the answer is)

Edit: also, it is interesting to replace "programmer" with "math professor". Can anybody become a good math professor if they enjoy doing it? If not, what is the difference (assuming it is true for programmers).

For me I think the determining factor of a good programmer is not enjoyment (although that is necessary), it's curiosity. I work with a guy who I'm pretty sure has a photographic memory and would probably run circles around me in an IQ test and with his GPA, but I'm constantly showing him more efficient ways to write code. The difference is I am forever curious about CS-related stuff. I spend hours a day reading HN and other things like it. I'm orders an of magnitude better prgrammer than he is simply because I'm curious.

I'm not sure but I suspect that viewpoint has a massive effect.

It's similar to the old saw about growth vs fixed mindsets.

I often describe programming as "failing 99 times and succeeding the 100th time, and counting that as success". There are a lot of people who are not wired and acculturated to that sort of "success".

That said, I don't (obviously via the growth mindset) think it's a fixed quality, it's more of a learned and acquired routine.

I think it's a bit of both nurture/nature. In hindsight it was obvious that I would be a programmer even though I didn't have much access to a computer until college. Growing up I gravitated towards math/science, loved any sort of problem solving, and enjoyed things that many would consider tedious (building model WW2 naval ships with my grandfather for example). I did have a Nintendo that was in a constant state of being taken apart, but it did work most of the time :) When I finally had school computer time starting around middle school, they literally had to drag me off of them. Trying commands, tinkering, etc... was just...fun.

None of my friends (or parents for that matter) understood because they were mostly jocks with a few artists types mixed in. But, my friends never cared as long as they could get me out of the house to play whatever sport was in season.

To circle back around, I had a natural inclination with people like my grandfather encouraging it without really knowing.

I think our enjoyment of an activity depends on how we see our progress.

If we keep struggling with it, we will hate it, even if we thought we would like it at first.

We could also begin to enjoy an activity if we see ourselves progressing in it. When you see your improvements, your brain probably releases dopamine (or another one of those addiction chemicals) and that makes us want to do it more (to taste that sweet taste of victory/progress).

Some subjects aren't really fun until your good at it though. I used to hate it until I forced to do it and found it was fun after I got the basics down pat.

When I think of somebody who enjoys programing, they usually have a goal or task to compel them. Just solving random CS questions and math is pretty boring to the majority of folks.

>> Well, if you enjoy something, it's much easier to put a lot of time in to figure it out.

I started programming as a kid because I wanted to make games. It was fun. The problem was that I didn't get the more formal stuff until college, and it made me a much better programmer. But I could also see how boring the data structures class would be to someone with no experience because they really didn't have insight into how applicable some of the concepts could be.

I have always advocated for creating games (and other useful things) to teach programming. Most if not all the major concepts can be applied to games. Why anyone would use the fibonacci sequence to teach recursion is beyond me - it's a stupid solution to a stupid problem. Let's talk about board games and minimax search. Yeah, you have to build a lot of code before that comes into play but you'll learn a hell of a lot more and have way more fun doing it.

Doing simple games like 2D scorched earth really brings home basic vector math and physics. Any 80's arcade game with a thrust button allows you to apply that stuff.

Any kind of 3d graphics goes right along with linear algebra - a topic that is not required by all CS programs even though matrix operations run 24/7 on supercomputers.

Text processing. chat bots anyone?

I used to have an example that used trees but it escapes me right now. Chess doesn't really count because you don't store the tree. We can go back to 3d graphics of course - photon mapping, kd-trees, various BVH structures.

If you start with data structures and algorithms, peoples eyes will glaze over. If you start with simple things that are somewhat interesting you'll get people interested and then you can progress them slowly to more advanced topics by introducing problems they'll want to solve.

I agree with all that, and in my experience, students really react well to courses and coursework based on doing games.

And yet, I will use Fibonacci as introductory example tomorrow when I teach "Intro to computational complexity" this week. The great advantage of Fibonacci over just about anything else is that it is so short, so simple, that everybody can immediately understand it. There is no preparation needed. Just about anybody who can breath, can understand Fibonacci.

Despite this simplicity, Fibonacci is so rich: You can use it to illustrate: Recursion, exponential complexity, going from exponential to linear complexity by memoisation. Relationship between loops and recursion. Tail calls. Stack space used by compilers, the limitations of compilers that do not do proper tail call optimisation,generating functions, recurrences, solving recurrences.

>> And yet, I will use Fibonacci as introductory example tomorrow when I teach "Intro to computational complexity" this week. The great advantage of Fibonacci over just about anything else is that it is so short, so simple, that everybody can immediately understand it. There is no preparation needed. Just about anybody who can breath, can understand Fibonacci.

I agree with all you said too ;-)

I would say "Intro to computational complexity" is a more advanced course and the students should already be familiar with recursion from experience prior to learning to analyze time complexity ;-)

IMHO Fibonacci is still a poor example because the most obvious (to me) implementation has always been a loop. Pointing out how a recursive version can be simplified to a loop seems silly, and so does making it more efficient with memoization. But as a first example, sure I suppose. Then you drop the bomb on them and show how it can be done in O(log(n)) by using fast matrix exponentiation.

Thanks for reminding me of the O(log(n)) algorithm. I had forgotten about it. Just added this algorithm to the lecture slides. I <3 the internet.

I start with the recursive algorithm because it follows directly from the definition F(n+2) = F(n) + F(n+1). I also think there's a big schism in programmers: between those that think recursively, and those that are of a more iterative bend. I'm in the former camp, probably owing to the fact that my first programming language was Scheme.

>> and those that are of a more iterative bend

And that would be me ;-)

This is a problem in general in math-based education, and sometimes in science also. The solution is problem-based teaching, where the problem is introduced before the solution. By establishing the need for something first, it makes it much more concrete.

It's not really surprising that good programmers are often also good at legal drafting.

When you're a programmer, you understand that the processor is dumb and has to be guided through absolutely everything. If you don't factor in the corner cases, your program is going to screw up somehow.

Legal drafting is the same thing, just replace the processor with a judge and the programming language with English. If, while writing a contract, you precisely define everything and cover all the ins and outs of what can and cannot happen and what should and should not happen in the event that any or all of the above likely or unlikely events shall happen during the lifetime of the contract. Then if you ever need to get the contract enforced by the judge, you can clearly point out exactly how the opposing party already agreed to resolve the situation in some way.

The real reason why you need to hire lawyers has more to do with making sure that the contract you draft is enforceable (considering current law and legal precedent), or else risk having the entire contract thrown out later by the judge. AKA legal system faulting.

A lot of less technical management doesn't understand how important being able to find corner caeses is. This is what separates a good and solid application from one that is routinely failing.

It's really not about time, it's being able to think flexibly. I have seen several freshman who never coded before where 1/3 of them get it in a few weeks and have an easy 4 years, where the second set either drops out or spends a lot of time trying to keep up.

An assembler class where the high end spent 2-3 hours and come in with 3-5 pages of code vs. the low end that spent 50x as long had 100+ pages of code that did not quite work. At first glance the difference was if you looked up how the math coprocessor worked, but more generally how much you tried to brute force the problem vs. look for a cleaner solution.

I don't think he was refering to time spent on a given program; rather, for people who don't intuit CS concepts time spent staring at the page can make the difference between a person who never gets it and one who eventually does. At that point, there isn't much functional difference that person and a person who got it from the start.

I don't think it's really about the CS concepts as it is being able to link them together flexibly. Suppose you want the median value in an array. Well sorting makes it easy, but you don't need to fully sort the array. A modified quick sort seems like a good compromise, then again using a built in sort is probably fast enough and much less code.

That's the kind of thinking that really works. Because you can look up well known probelms, but you need to start thinking in terms of trade offs instead of going with the first idea.

I would argue that in order to link them together one must first understand the CS concepts and their uses. Once a person has that understanding, it becomes trivial to know when a naive solution is no longer the right approach. Once a normal person has the ability to see problem solving like that, they've pretty much got it.

That's not to say there's not a difference between all possible solutions and the people trying to find them. Some will be able to zip together the objectively most efficient solution right from the start. These are the true "superstars." People for whom doing something once is as good as doing it a million times (ie, they don't forget things). These folks are exceedingly rare and the rest of us will have to settle with kowing enough to know when we need a better way.

I get where your coming from, but many people can get all the individual concepts and still not make the connection.

If they want to double X, they are happy to use X + X, 2 * X, or X << 2 and map them all to the same place. So, if they suddenly can't use * because the CPU does not support it they are happy to use the other 2. And somehow this is the same skill where someone hmm database is to slow, let's do X.

It's probably a learnable skill, but it's just not directly part of CS classes. Someone can learn X XOR 1 is the same as X MOD 2, it's another to use XOR when they can't recall the MOD symbol.

Maybe I'm missing something but in your two examples, what you refer to as skill is just recall. I would argue that in the context of alternative solutions, the skill would be knowing when a better alternative is needed when it isn't immediately obvious. If I knew mod wasn't available yet I neded an analogous operation finding an alternative is trivial even if I don't recall it. I wouldn't call that a skill.

It might seem obvious if A and B do the same thing then you can use A or B to move on to the next step, but many people don't think this way.

For a non programming example, you can use the handle of a shovel as a long stick. This should be more or less obvious when looking at a shovel, but I have seen people ignore shovels when looking for a stick to do something.

Cognitive ability isn't equally distributed.

It's not fair to call people that find programming difficult lazy. You can work harder and longer, but it only pays off up to a certain point.

There are some tasks which require more intelligence, and some which are easier for more people to do. And thankfully. there's more that can be done to make the former more like the latter.

I've been programming for nearly 40 years. Based on my interactions with others, programming is an intrinsic ability. People that don't have that intrinsic ability can cut'n'paste their way through simple programs, but really struggle to understand what they are doing and why their program works (or not).

Anecdata: My high school got access to a computer (dialup modem). I essentially taught myself programming and then took the official class to teach me programming. Aced it, obviously. My younger sister saw how much I enjoyed programming so she took the class and struggled tremendously. I tutored her... I recall a problem where she had to do an operation repeatedly, an obvious (to me) application of a "for" loop. She struggled with why one problem pattern required a "for" loop and one pattern required an "if" statement.

My sister is very smart and was a straight "A" student in things that she could memorize, graduated from college summa cum laude (IIRC). She became a very good elementary school teacher. Myself, I was very much not an "A" student, especially in things that required me to memorize facts, but I "got" programming instantly.

More anecdata: I am now mentoring FIRST Robotics teams. I continue to see a dichotomy in aptitude for programming... two years ago I walked a student through a program for controlling a robot. She got pretty excited and interrupted my explanations and said "wait, let me think this through"... and she (verbally) worked out the logic of a complex "if" statement. She took over programming that year, is now in college pursuing a Computer Science major, and loving every minute of it.

Still more anecdata: Last year and this year I have a student that loves computers and intends to pursue it as a carrier, but he isn't a "natural." I spent a huge amount of time last year coaching him, but he still struggles to understand what pattern he is looking at and why e.g. he needs a "for" loop to solve the problem.

I could give a lot more anecdata, but I've worked with Robotics students that can program e.g. move sequences once I coached them through the details and I've worked with Robotics students that took off and created complex programs with nothing more than a simple introduction to constants, variables, loops, and conditional statements.

This is surprising. I used to be like your second student according to my father. He taught me most everything I know, and my brother used to be like your first student.

I found what personally helped me to overcome the insight bridge/gap was I had to read several different books to find the right analogy that helped achieve the "insight".

There are certain things I definitely did not get in the beginning. But after working very hard I got them.

I am curious what percentage can make the jump as I did. Clearly there are certain "epiphanies" to be had. I almost immediately understood "for" loops, but took several years to get pointers and polymorphism each. I know of people who get some or all of these concepts instantly.

There is clearly the appearance of bimodality here, even in just my experience with just how I learned things.

I haven't been programming nearly as long but I've seen this pattern many times as well, and within my own family too!

Isn't intrinsic ability just g in the end?

That's an interesting question. Programming is definitely a skill so study and practice certainly matter. But it's possible the limiting value is the same as g or at least something that includes a set of abilities highly correlated with g (e.g. working memory).

My problem with these theories is that people like me just don't fit into them at all.

I've always been slow. Never did all that well in classes. When I was on a FIRST Robotics team I was phased out by the genius programmer that was already there and barely saw any code. I never really had a problem with for loops or if statements. But never really instantly got the more complex programming concepts, either. My father was a programmer so I was exposed to a lot of the things earlier, maybe that's why I missed the not getting for loops stage. I shouldn't be a programmer if many posts in this thread are to be believed. My father shouldn't be, either.

Worst of all, my programming understanding has went through several key developments in a very jagged fashion. For loops and if statements just didn't give enough to push me over the edge. And it wasn't just programming, but the general theme was that sometimes I would just not get some concept, or miss a simple concept, and after that, I would get stuck, and I could not get unstuck without some unusual event like getting the right help from the right source at the right time. One of my most important degrees of understanding did not develop until I took a certain class in the second-to-last semester of college.

After a while, it seems that enough things clicked all at once, and the problem went away. I don't get stuck anymore, I always know where to go. But that was supposed to happen earlier, so much earlier, but it just didn't.

While this was all happening I was definitely the kid who doesn't get it in the eyes of others. Maybe there's some teacher or mentor out there right now writing a blog post or a comment somewhere else about how they tried, they really tried, but I didn't get it.

And, yet, leaving for another industry would have easily been the worst decision of my life.

It also requires the right kinds of insights.

I know plenty of people who somehow manage to make it all the way through an undergrad degree without ever really getting programming. They then managed to get a low-skill job at a low-caliber employer, where they produce bad code, poorly. But because even bad employers need code these days, they manage to maintain a job in programming despite never really understanding it on a fundamental level. Unfortunately, in such an environment it can be hard to ever improve since you rarely have competent coworkers (and the ones you do have quickly leave).

It might just be a matter of time, but only if you frame it that some people get it really quickly and others take forever. Ultimately, I think programming performance correlates very highly with IQ. Otherwise I really don't see any coherent explanation for why I should be able to out-program someone who started programming before I was born.

I work at a large corp that has recently insourced all its IT. To support this they have been vacuuming up as much mediocre IT talent as they possibly could. Every once in a while they hire a person who is curious about the field and competent. For the most part, though, the majority MIS/CIS folks who couldn't hack CS or were business until a professor told them they could make a lot more money in MIS or "experienced hires" who just want a paycheck and health insurance. Its depressing to be surrounded by such people.

What I find in in-house IT is that CS curiosity and ability to develop good software aren't the critical traits. In those environments, a "developer" spends the majority of his/her time integrating vendor solutions and writing connector code. Often they are task switching rapidly between projects, operations, and support. The critical skills belong to executive function: time planning, task switching, communications, etc. The stronger your executive function, the better work experience you have in those environments.

Of course, some companies see IT in a more strategic light so software development is robust and they do look for talented developers. A mid-sized financial company, I was employed at 12 years ago, wanted custom finance packages. At one time, Fidelity had a separate business unit that was IT R&D: I'm not sure if it still exists. Nowadays I believe they are the minority.

Your accessment is spot on.

Thank you for writing this. This feels like this vindicates a lot of the things I like and dislike about my current job (my first developer position, in an IT department of a very large company).

Currently I'm enrolled in a grad CS program after 25 years in the field. Most students in my classes have never been in the field before. My caution to them is to understand their own likes and dislikes. If a person loves writing software and delving into a problem for many hours without interruption, then the person needs to be careful with in-house IT.

(I also caution them that some likes and dislikes won't be known until they've been in the field a few years.)

I spent too many years being frustrated by this lack of understanding and outright denial. After all, we're in IT, don't we all want to produce really great software to help people?

Recently I had to admit to myself that the answer to the above question is "No". Often a timely good solution beats out a future great solution in the minds of people who thrive in in-house IT. They accept good enough and have no qualms about a vendor providing it.

[EDIT: spelling correction]

That vendor-integration (and vendor-relationship-management), rapid task-switching, ops / support description sounds exceptionally familiar. It's what I view as more a dev/ops role, though it's also somewhat the old-school Unix-class sysadmin model. Someone who's familiar with compiler and scripting tools, and writes a fair bit of glue, but who is mostly building systems out of component parts, rather than coding them up from scratch.

It's the task-switching and firefighting elements of that position which tend to dominate, and which I've found increasingly untenable (at least to my own personality) with time. I need the long, clear timeblocks in which I can actually think.

> ... (and the ones you do have quickly leave)

"The problem with this place? Everyone with get-up-and-go has already got up and gone."

Reminds me of "Benny's Rules", regarding the complicated (and incorrect) math rules a child inferred through trial and error.

http://blog.mathed.net/2011/07/rysk-erlwangers-bennys-concep...

You provided neither evidence nor argumentation for your claims, though...?

There's a paper from the University of Toronto called "Evidence That Computer Science Grades Are Not Bimodal": http://www.cs.toronto.edu/~sme/papers/2016/icer_2016_bimodal...

I had the same experience for the 3 years I was teaching assistant. Some people "clicked" very early and some didn't, but it's not set in stone. I've seen people succeed with only hard work and motivation. Once you've unlocked yourself there is not much differences between you and the ones who have unlocked themselves earlier.

Actually doesn't your experience hint at the opposite trend in the working sector?

If everyone (roughly) either fails programming, or aces it, then the working professionals are the ones who passed AND excelled.

Oh if only that were true.

I've worked with people in the past who know just enough to hack together a front end on top of a simple database, but who would completely fall apart when presented with anything more complex than that. These are the sort of people who when asked to build an internationalised website "solve" the problem by copying an entire PHP application into directories called "english" and "german" and then proceed to change the text in the German version.

There's that XKCD about asking how novice users solve computer problems. "I save the video to iCloud, then copy the url into this video downloader, then put the download into this transcription site, then upload that to..."

I think this is a big chunk of explaining how bad programming goes, too. It's not "too incompetent to build a thing", it's "incompetent enough that everything runs on voodoo and evil".

In my experience, there is enough fluff and non-programming, abstract theory classes in a CS major that people who cannot program their way out of a wet paper bag can complete the degree, and even get high marks. These people can get jobs, and coast along for years at sub-mediocre levels of production, in most cases.

I'm going to be a bit more charitable and say that those people find non-programming jobs in the field.

One person I interviewed stood out in my mind for having completed a Master's in CS, was able to classify the problem I posed her as belonging to a certain type and told me how it should be approached. She still couldn't even begin to write the (simple) code to solve it, however.

This person was obviously smart, and also quite obviously had no programming skill.

This is an interesting suggestion.

However, it is very easy to cheat your way through college and obtain good grades. My assessed coursework regularly shows up on rentacoder.com and similar. There is an industry out there for writing dissertations. Group work is another mechanism that weak programmers use to avoid getting better: they let the good programmers do all the programming and then do documentation, or UI design, or nothing. In addition, there is a pronounced grade inflation, so even weak students look great on paper.

Not every organisation has the know-how to filter out weak students that look great on paper.

My degree program must have been unusual, then, because my senior project class was the only one where less than 80% of my grade came from in-class tests. Many professors didn't even give a crap whether you actually did the homework or not, because you'd bomb the test anyway if you didn't.

I believe your comment is missing a /s tag.

I imagine you've never been the one hiring or interviewing developers, have you?

There is an amazing bit though: there are the ones that you classify as "surely worthless", but then you see they can indeed get some jobs done, so a non-technical manager or HR-person can easily confuse one of those that "can sometimes program computers to do useful stuff or keep things running" vs someone who can do "software engineering".

Oh, and then there's the infuriating third category of those extreeemly smart (IQ through the roof + wealth of knowledge) but extreeeemly unproductive (like even manifesting "negative productivity" and dragging a team down or an entire project into the ground, the "-10x programmer").

People are... complex :)

Lol at the third category - they're at the wrong jobs(for them), perhaps they need to do something on their own, figuring things out themselves!

How did your category-three people drag the project down?

I think there are some infamous examples from the old days of Microsoft. Think of the programmer who insists on using an obscure dialect of Lisp because of all the "clever" things they can do in it. Even if they work, and are genuinely clever, it can be a huge pain for the less brilliant/obsessed people to interact with.

In general, this seems to be a problem that arises when smart, capable people (who are short on common sense and teamwork) become so valuable that they get to call shots no one else can accommodate.

Imagine Mel being on a team of 15 people: http://www.catb.org/jargon/html/story-of-mel.html

Well; what these people have not learned is that the whole purpose of a "programming language" is NOT to tell the computer what to do. It's to tell your team mates what you've told the computer to do.

People who don't get this are really the worst to work with.

Often, smart people seek challenges and complexity. This can be dangerous in software engineering, if left unchecked.

A sub-category I find is the "scientist" programmer vs the "engineer" programmer. With the scientist programmer being these category-three people. An engineer will use existing frameworks, technology, standards, etc. to solve a problem. And a scientist wants to develop new frameworks, technology, standards, etc. to solve a problem.

On larger teams, you want some commonality with your code. You want to be able to look at code written by others and at least have common style, strategy, and idioms. Engineering style devs tend to follow this nicely and it all works fairly well in a team dynamic. Whereas, scientist developers are often looking for new ways to do everything. When they see things done in a common and consistent way, they tend to look for unique solutions and tend to do more of "research" style development.

Don't get me wrong, both styles have their benefits. But on a typical largish development team, the scientist are often a more negatively-impacting developer to the overall productivity of the team.

The really scary thing happens when these scientist type developers become architects. And then you end up with what is often called an "architecture astronaut".

John X is assigned to project Y with team A but find it very boring for him. So he overengineers in a way so that it only works by solving a very complicated engineering problem that he wants to solve instead (think "developing your own distributed no-sql db" class overengineering).

John X leaves for a more interesting project, team A can't make modifications to the current over-engineered system so they need do a rewrite of a few key components that incurs a huge delay.

And yes, it was not John X's fault. It was the manager's who assigned it to the wrong team and project, and the team leader's that they didn't have working code review process to be able to give JX feedback early to "write code easier to maintain by a less experienced team even if it's maybe less efficient and takes him a bit longer".

So you're right in insinuating that category-three people don't really drag projects down: it happens when they are assigned to the wrong place and when you have teams with broken processes, so objectively speaking, bad management is actually what's dragging things down in this case. But isn't "bad management" close to a pleonasm anyway?

I have a theory where the bimodal distributions comes from two sets of people: one set focused only passing the course/assignment/test, the other set focused on actually knowing the content. Appearance and substance.

Interesting theory.

I have a different one, derived from teaching 1000s of students over 2 decades. the bimodal distributions comes from two sets of people: one set working hard and putting the hours in until the master the subject, the other set being lazy, cheating, and don't put the hours in, so they never achieve mastery. Appearance and substance.

How is it different?

"The ten-thousand thing-kinds are ultimately alike and ultimately different. This is called the great similarity-difference." - Zhuangzi

In meric's model, the student who get good grades aren't the same ones achieving mastery. In mafribe's, they are.

I must insist although "achieving mastery" is clearer than "knowing the content", I meant the same. It would probably help if I wrap "knowing" in asterisks like "knowing the content".

FYI, you have an untested hypothesis, not a theory. Unless you have done some research somewhere. Sorry for the pedantics!

Poster was using the dictionary definition[1], the the scientific one.

1. http://www.merriam-webster.com/dictionary/theory

That's my experience too. There are those who want to get a degree with the least amount of work and don't really find the topic interesting. And then there are those who will discuss it and debate it before/after class, etc.

Good test to tell them apart: if the lecturer mistakenly starts to talk about stuff that he already said in the last lecture (i.e. mistakenly doing the last one again), the first group will be happy and silent because there will be less stuff to learn for the test. The second group will tell the lecturer because they want to learn. This is then often mistaken by the first kind of people as trying to please the professor or "siding" with the prof instead of the fellow students. Because they think in a school-mindset.

I suspect that some do cs because they are interested and some because its a hot field or because of family/social pressures

I did a batchelors in Molecular Biology years ago, and I noticed that some of my friends seemed to just learn the material, whereas I tended to understand the material.

> I find it plausible that grade distributions turn into similar income distributions later in life.

Given that the people earning the most money aren't necessarily the ones with the most technical ability, why would this be the case?

> In fluff subjects like software engineering where grading relates to essay writing and group projects

How is SE a "fluff subject?" Why are they writing essays? When I took SE we had individual programming projects and a group project to write a compiler. Not fluff at all.

SE is often relegated to a "fluff" subject in schools simply because it's, well, not very challenging. Classes based around the topic of SE are often topics like "Formal Software Development Methods" where you learn about verification of concurrent programs, formal symbolic testing, contracts, explicit model checking, etc. These are all "soft skills" and hard to directly generalize into a programming assignment, so students often times write essays formalizing their logic.

Frankly, I'm surprised that your SE class did compilers at all, many schools in CS have their own "operating systems programming"/"low level programming"/"compiler design" sort of class, where the topic is fully fleshed out, rather than just a tiny project.

Wow, things have changed since I took my SE electives (17-18 years ago). We had to write code and there were final projects that required the development of a non-trivial application. One that compiled and at least nominally worked. Granted I only took a course of about three electives at the sophomore and junior level, so maybe I missed the "fluff" in other levels.

Yeah the first "formal" sophomore SE elective I took was literally "hey isn't OO the best? Don't you love drawing UML diagrams? What word is P-O-L-Y-M-O-R-P-H-I-S-M, and can you write a 1 page essay on it?"

Once you get up to the actual SE electives, they're all about the formalization of software and how it can be represented. These classes are usually avoided by students as well, since students opt for fun (from the student's pov) classes like robotics programming, compiler design, web development, crypto, etc, which only makes the SE classes seem like more "fluff".

At my school we wrote a part of a model checker (in C, with pthreads) for concurrency, the rest of the assignments were (as I recall) a mix of questions and math proofs, so you either got it, or got to redo the questions.

In general I only recall writing one simple essay and it was, indeed, for our completely fluff project planning class, which was almost entirely about the instructors homegrown, mostly bullshit agile-like system.

I think this must vary a lot between schools.

In my school, SE ended up weeding out quite a few people who couldn't actually program. They were fine at math and "theory," but when it came down to actually programming, they produced garbage which only eventually worked through trial and error.

For most other classes, grading was based entirely on test cases so they could still pass with their frankenstein programs. SE was the only course which required the development of a large application and where grading was substantially based on actually looking at the code.

For the record, there were 0 essays in my SE class and lots of large, in-depth projects.

I think it depends where you study. In my university, SE was basically "Write essays about why OO is great and draw lots of UML".

Perhaps things have changed since I was in school about 15 years ago but I always called it "academics teaching you their warped view of what life as an industry programmer is like". I quickly learned that nothing which was covered in those classes were things I did in my jobs once I graduated.

Be fair. Some of it is just learning what code is, and how to think about it. They provide some practice with various dogmas. The idea is, once you are working you'll learn more/different ones and have some facility doing so.

"Nothing I learned as a toddler is anything I do now that I'm an adult"

Or these tests were designed from the first moment to exhibit this distribution of grades since they favor only geniuses and insiders alike.

I am not really buying that this is some kind of a reflection of a natural or deterministic phenomenon.

Please show data to support claim.

Check out this paper, which inspired Jeff Atwood's "two humps" model of programming education: https://web.archive.org/web/20090401003425/http://www.cs.mdx...

It's been retracted, but it's the only case I've ever seen where I found the retraction unconvincing. The retraction effectively says "After this paper came out, I made a lot of wild claims about it that the data didn't support. Therefore ignore the paper, even though the results replicated successfully."

Reply on news.ycombinator.com