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.

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.

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.

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.

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

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!

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.

I am building direct industry experience rather than filling GitHub.

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

Generally, the degree is supposed to indicate some sort of sufficiency with development. 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 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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

(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]

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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 that would be me ;-)

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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 :)

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

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

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

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

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

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.

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

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

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