Fake your way through basic CS courses.

Find your way into group-work heavy projects in later years, possibly doing enough ancillary aspects of the work to be semi-useful. It will be likely that your other group members will find it easier to grin and bear it.

Optionally: do a Masters or PhD. Plagiarize your work, or potentially hire someone to do it for you.

Continue into the work force, focusing on office politics, group projects, putting your name on things that you weren't really a contributor to, etc. Write a lot of reports.

This is why we're not a profession, folks. I'm amazed at the number of people who got on here to theorize about every goddamn thing ('grade inflation!' 'what are marks good for anyway?' 'I use the web all the time to remind me of things I've forgotten!') aside from the content of the article, which is that there are tons of people going through coding classes who are apparently aiming to get through without learning any code and want to cheat.

Every time you get dragged through some pointless, patronizing and degrading interview process that assumes that you don't know your stuff - you can thank the cheaters and fakers, and the fact that our industry doesn't have the will to root them out.

Out of the 100 IT interns every year there are usually about 5 that know more than only the basics. This has been a consistent pattern I've seen over the last 4 years. It does not matter what level education they are having. Many times I even had to explain what functions, conditions etc. are while they somehow still managed to get average grades for classes that require this knowledge.

I really do not understand how so many people manage to fool almost everyone for so long. It usually ends up being the case that I (because I get hired to guide them) or the about 5 good interns that are there do most of the work for them. Of course some of them still manage to setup a Wordpress website or write some simple HTML. Just enough to impress the company owners.

Another consistent pattern (as mentioned before) is that very often their end-goal is to become an IT-manager. These are usually the better talkers.

Of course this is all anecdotal, but I've asked many other people that guide IT interns and they noticed the same thing. Probably something that can be researched.

Now I may seem like the one that thinks very highly of himself (by reading my own text I can understand why it may look like this) and this is exactly what makes this difficult to explain to the company owners when I notified them about this. They just do not believe the 5 to 100 ratio and think I've some difficulty accepting people.

- 1-on-1 copy paste, change the name: Easily caught by looking, no need for anything else. These will fail.

- mostly copy/past, changing names some locations: Easily caught by letting them explain the workings of their code, they will always fail. I've had one lazy student who could easily explain while copying but was just lazy out of hundereds. These can slip through if the course is understaffed or badly designed.

- Hand written assignments: Mostly parallel working when individual required, I'm not agains cooperation but mostly you could see that one student got the exercise right and the other just copied him/her and usually lacks details which are in the other assignment. It is very noticeable if they copied it due to similar layout and textual form. If the assignment is too simple this is harder to detect, but quite easy in algorithmics courses. These are far harder to detect and prevent, though individual checkups (at random) are a good way to test the true knowledge acquired. Needs lots of staff which is never there since 'budget cuts'.

The biggest problems are the group assignments as noted in other posts. They are hell to get rid of people as failing one usually means failing all even when some didn't perform. The usual trick to get it right is to either fail the entire group and give them an individual assignment to filter out the incompetent or to do the same thing on an individual basis. The problem is that you actually have tangible evidence otherwise it is very difficult, though commit logs is a start. The people who should fail and get through are at least some of the 95% you mention.

The 5/100 ratio is not odd/off in my perspective. You describe the top 5-10% (which are good and you want at your company) vs the next 30-40% which are average and simply make things work but lack initiative or knowledge vs the rest which should look for another job since these applications usually contain at least some amount of incompatible applicants.

Consider that if you pay peanuts, you get monkeys so that also might be the problem.

ps: IT-managers without proper IT knowledge (and yes I mean the basics) are the same thing as a CEO who is unable to speak in public: Nice decorations on the office floor but utterly useless in practice.

I really do not understand why so many people want to get into IT if they are not really interested in it. Job security probably? Not for the money I assume as in the Netherlands the average salaries for even a senior programmer are pretty low. +/- EUR 20,81 an hour before taxes (+/- EUR 12 after taxes).

Sources:

https://www.loonwijzer.nl/home/salaris/salarischeck#/ (search for Application Programmer)

Anecdotal evidence of many programmers around me that I've met in the Netherlands.

I did three group assessments, and out of those three failed two students with the help of my teammates, by co-ordinating our peer assessment. This peer assessment does not become public until grades come out, at which point they can be disputed. But 3 vs 1 usually comes out in favour of the group.

This is, inadvertently, fantastic training for sociopathic stack-ranked office politics.

This is something my university has done, but didn't implement quite as well. I think the key here is making it completely anonymous (ideally filled out online individually) because otherwise objectively assessing a group member's performance in front of them is difficult.

With that said, I think I'd still find it hard to outright fail a group member via these means unless they literally put zero effort into the group project - it seems a small thing to threaten their entire degree over.

To me, it's quite simple. Lack of teaching the fundamentals of programming. CS programs want to teach object orientation in first year CS. How can you understand object orientation and complex data structures until you've learned what a pointer or structure is (C code, yeah)? How can you understand a pointer unless you have a basic understanding of the machine, and in particular, how simple variables are stored in memory.

This is the boring stuff for professors and administrators of a CS program, but an absolute if you want to produce quality CS graduates.

Otherwise good students get lost in their first year of CS, which is the real shame here, given the shortage of CS talent. I advocate for better teaching of fundamentals, preceding more complex topics in computer science. Without it, we will continue to see CS grads fall down in the work force.

Speaking as someone who has spent considerable time in front of first-year college CS classes, attended SIGCSE conferences, and applied this in practice: trivially. Your "pointers-first" bias has long, long been debunked. Brown, Stanford, VT, and other CS departments have had fantastic programs teaching via OO-first methods for going on twenty years now. Studies of students taught this way have determined that they learn stronger design skills earlier, and have a greater focus on the problem to be solved rather than the machine being built. (At first: this is emphasis only on which skills are taught first.) Anecdotally, giving students a framework in which to understand why they're doing what they're doing early is hugely important. Then, a few semesters in, they do the deep dive into the minutiae that C, assembly, etc. afford.

This, in turn, is really no different than the era of pre-C++ CS instruction. Prior to C++'s big wave of popularity in the 90's, C was largely considered to have too many sharp edges for first-year CS instruction. Languages like Pascal, Modula-2, and even some Lisps were preferred to get basic algorithmic and data structures concepts across, with C generally relegated to the third semester or so. I'd call the common theme here "algorithmics and abstraction first" pedagogy.

C++'s burgeoning industry appeal eventually became a siren-song for many CS departments, who dropped the "not C first" pedagogical approaches and threw students into C++ right from the start. The result was generally disastrous. C++ is a terrible teaching language, with all of the sharp edges of C, with more in the OO/templates part. For contrast, Brown's program of that era used OO Pascal with a custom-built graphics library designed to be accessible to first-years, yet useful through senior project work.

Design skills can be only learned through experience. Understanding what abstraction to apply is something you would learn after many "failed surgeries". You can only learn this on the job and by reading a lot of code.

Writing efficient software is impossible without understanding machine. Without knowing how things are represented in memory or how compilers/OS works you will never write good software. You will end people that do not understand how event loop in node.js work or write thread safe Java.

Just ask few practical question about Promises, Heap, GC, Threads and you will see blank faces from the same people that just white-boarded DFS.

Anyway, he would get up in front of the staff meetings and say, the school is graduating students who do not know how to code. The school didn't care; they got paid. Every class of any import had team projects because "that's what the real world is like". And every team would have the one person just skating by. The only exceptions in my entire undergrad education was in the graduate level course I took with a friend, which thankfully had two-person teams. And the one elective I took with the aforementioned lecturer, who actively kept tabs on who was doing real work through surveys and looking at the source repositories.

Theory (discrete math, algorithms, formal languages) was 3 courses out of an 18-course program. HN keeps talking like it's the only thing you do in a CS major, which is bizarre.

The most obvious way you apply what you learnt in those classes is by writing programs that implement those ideas (And it's also the easiest way to evaluate whether you actually learnt the concepts). But you can just as easily apply that knowledge by designing systems for somebody else to implement — somebody who presumably lacks the knowledge required to architect the system. Hammering out code is easy, and you don't need a university degree to do it. It's the rest of it that takes some study.

In my case, the topics were similar to the list you give (although there were a significant number of optional classes which I filled with math, skewing it a lot), but the subjects were definitely more theory-focused than practical. Sure, there were practical classes for each subject, weekly projects, semester projects and so on, but they were secondary to the theory in both quantity and difficulty. As an example, you might deep dive into a number of networking protocols, but in the same period only implement a toy TCP/IP during a prac.

Always surprised to hear about this variance, given the general consensus that there aren't differences in quality between schools.

https://en.wikipedia.org/wiki/Goodhart%27s_law

Does that mean there isn't space for a module on software engineering theory (design patterns, development methodologies, OOP principles, testing, version control...)? I really don't see why that has to be the case. Some of the worst code I've seen has been written by academics - undocumented, undescriptive nonstandard single letter variable names everywhere, huge monolithic functions named "compute" that span hundreds of lines and several levels of indentation.

See how it doesn't make sense?

Using git helps a lot!

Fakers, cheaters, bullshiters are everywhere unfortunately, spot them early and avoid them where possible, preempt their attempts to land grab credit

We are. Source: I am a master-level bullshitter. Professional lobbyists and politicians ask me to make introductions, use my network, etc. Here's the weird thing, though: I'm a software developer. A pretty good one. Not the best, but top 20%.

I know tons of Natural Bullshitters like myself, but I've never met another one that was a software engineer. Dabblers, occasionally, but no Naturals.

The thing is, it takes a bullshitter to spot a bullshitter. So being a good bullshitter is the skill that has offered the most utility to the various jobs I've had in tech: calling out frauds, inflating the profiles of the people on my teams doing actual work, undermining lesser bullshitters that try to take credit from them... come to think of it, there's never been a technical team I was on where I was not the most popular member of the team (among my peers, at least).

So if you can find a Daywalker, try adding them to your team...

I wouldn't call myself a professional bullshitter, and I wouldn't still have a business after ten years if I didn't have substantive knowledge of what I do.

However, my cultural and family background is in the humanities. I spent most of my adolescence and teenage years on my programming hobby, like many people here I think, but the route to a tech career was a rather incidental one. My parents are philosophy professors, and I entered university with a political science major (switched to philosophy), before dropping out two and a half years later to pursue what was by then an ascendant tech career.

The discord between my background and the psychology of typical software engineers and business guys has led to amusing, sometimes infuriating cultural clashes over the years.

Nevertheless, I've got the comment more than a handful of times over the years that I really should have been a writer or do something involving lots of speaking. You can probably tell from this comment alone that I'm not a person of few words. As I get older, this has seen me enlisted to assist with marketing copy, résumé polishing, LinkedIn profile formulation, and a variety of other tasks that require putting a spin on things and drawing on one's facility of rhetoric. Some have said I'm a lawyer on the inside, combining the logical, left-brained, procedural qualities of a programmer with a knack for wordsmithing eloquent pleadings.

It's a weird space to dwell in. The real nerds think I'm a bullshitter half the time. The real bullshitters think I'm a nerd who lacks the social jujitsu to really hobnob with Visionaries like themselves. Beats me.

Mostly the latter, though it's us (practitioners) not the industry (employers). We're a visible, highly paid field of work without professional body either settingnquality standards for schools or certifyiing minimum competency of individual practitioners.

What should be regulated that makes sense in both Javascript and C? How should front-ends be treated compared to Assembly code? What best practices go where, and who decides this?

A ton of people have tried to certification programs and they generally fail to get real traction because every project is different from last year's project. I think this is because the field is advancing very quickly. Regulation needs a slower pace to keep up.

One thing with science on the side of truth is that the simplest questions (such as "what's the difference between a boolean and an integer?") can have extremely complicated and deep answers that lead to crazy discussions about formal definitions or implementations on different platforms and etc. And these are the kinds of things you can only learn by actually learning them, and trying to bullshit their way through an answer will quickly paint the faker in a bad place.

Give a very simple programmatic task, a paper (or a blackboard) and a pencil. As you watch the interviewee elaborate his solution, and as you discuss it with them, you'll immediately see if programs are a deeply foreign object to their mind, or something they're fluent with.

The point is not syntax, forgotten semicolons, or even knowledge of libraries. Don't bother with design patterns either, the kind of tasks we're talking about is too simplistic for them to be meaningful: just watch whether translating a task into program snippets comes naturally to them. If they can do that, they can learn, and probably have learnt a great bit already.

What works well is some form of "tell me about a time when ...". The candidate gets to tell a story of their choosing, but the discussion is long enough that they can't keep track of their lies...

Isn't this in every industry? You don't apply for the job you are most qualified for, you shoot for the next level job, the job that pays better, looks better, but stretches your expertise.

  Isn't this in every industry?

Needless to say, this means you can't drop out of university to found an architecture startup! And these organisations often have the side effect of influencing wages (and industry reforms) due to their control on the supply of workers.

People on programmer forums don't seem to like the idea of this sort of thing much. Better for my ego to believe I'm a unique genius due to my own efforts and inherent superiority; than to believe I'm a replaceable cog stamped out by a university production line!

Part of the problem is that programming is far too diverse a field. The only common denominator that could be reasonably certified by a gatekeeper/professional guild would consist of theoretical grounding in software engineering and computing concepts that typically comes with a CS degree. Yet, as all programmers are aware, people who have managed to jump through that hoop do not necessarily programming skills possess and do not necessarily good programmers make, while there are plenty of self-educated types who have managed in lieu of the formalities.

That's not to say that the field might not benefit from some professionalisation, just that there is an argument to be made that it is qualitatively different from civil engineering, medicine, aviation, architecture, accountancy and the like, if for no other reason than that the technology and skill requirements shift at a bewildering clip in rolling releases across 3-5 year time frames. That sort of thing is anathema to the slow, bureaucratic pace of guilding or regulation.

For instance, calculus, linear algebra, differential equations, numerical analysis, and so forth, are only a small part of what makes a good actuary. But they have a formal exam that you need to pass in these areas in order to be an actuary. They don't quiz new candidates with 10+ years experience on integration by parts during a job interview.

Because we lack even a basic exam in software development, we have to do data structures and algorithms over and over in interviews. I'd be more than OK with setting up a basic exam for what we can cover. I'd much rather take these exams with some assurances that it will be graded consistently and fairly, cover the proper material, and will lead to a lasting credential respected in industry. I wouldn't mind this even if it involved substantial effort and studying on my part, because I'd know what I was studying for and why.

Hey, maybe it means my next software job interview won't have to involve weeks of studying followed by 5+ hours solving tree traversal problems at a whiteboard.

I still think there'd be far too much contention over just what is to be included in the corpus of essential knowledge. Everyone seems to agree that data structures, algorithms and systems fundamentals seem appealing, but just which ones depends greatly on whether you're doing embedded PLCs for fuel injectors or whether you're doing React.

I've been programming since I was 9, for most of that time in C. Yet I'd be very hard-pressed to tell you how exactly CPU instructions work, and have never touched anything "closer to the metal" than C. Should this disqualify me from the profession?

After all, law now generally requires a $150k+ degree and three years of your life. Plenty of people, including Obama, believe that it should be at least shortened. But once entrenched, it's very tempting for gatekeepers to install expensive and lengthy credentialing procedures.

So overall, I think there's a good way to do this, and I do think that software development could be a better profession with some credentialing, provided it was done sparingly and properly (a huge "if", I must admit). I'd like to see this happen along the lines of the actuarial field, with exams rather than required degrees, largely because I think people should be free to acquire the knowledge at a pace that suits them. If you want to major in math, or physics, or something else, and "read for" the exams (to quote an old law practice), you should be allowed to. If we had something like this, it might benefit our field immensely. It would be a huge improvement over the capricious, opaque, and arbitrary informal exam taking we do over and over every time we interview.

But... I can't possibly pretend I don't understand your concerns. I personally was a math major and I got a MS in Industrial Engineering. I never did major in CS, I certainly didn't study "Software Engineering." I am also willing to openly question the value of test-driven development. There are plenty of people who think one or the other or both should disqualify me from the profession, and the idea of empowering them with the force of law (ie., the power to fine or imprison me for developing without the background and methodology they've decided is acceptable) is pretty chilling. That would be much worse than what we have right now.

No - it shouldn't. I feel that you should want to know this level and more about the internals (and history) of computers. I'm biased in that has been a driver for me personally...

...but to give you a hint:

A CPU (in the most basic sense) is nothing more than a very fast and very complex player piano, regulated by a clock. At each "tick" of that clock a row of "holes" (bits) representing a variety of information (address, data, instruction) is presented to the CPU. These bits are actually voltage levels. The CPU uses these voltage levels to change the state of logic gates in the system (which are wired for a variety of different tasks - but you only need one particular kind of gate to make any others - a NAND or NOR), which determine what happens, what to do next, etc.

I won't go further - and let me be clear that what I wrote above is nowhere near complete, and only describes the most basic level of an "ideal" CPU (or ALU or whatever) - because in the real world, you have things like voltage transients, timing issues (signals not arriving at the same times - hence things like wait states and such), noise, plus things like triggering on rising or falling edges of clock signals, multiple clocks staggered in time (for multiple triggerings per "cycle"), and a whole host of other things.

Yeah - it's pretty complex. But at the heart of it, it is pretty simple - a player piano, more or less, with a music reel spinning at mind-boggling speeds. If you need or want more information, there are (like everything else) plenty of resources on the internet about how all this stuff works. Check out some of the sites on people who have built computers from relays or logic gates; they typically have a lot of good information about the lower level stuff. Also look into some of the old books on building computers, and how they work (I'm talking the practical computing books from the 1950s and 1960s - difficult to find at times, check on used books online, in stores, plus on google books and archive.org; also, old back issues of Byte Magazine from the 70s and 80s are a good resource).

Other than your own projection going on in the first part, I'm not sure what you're actually saying. The fact there are not gatekeepers makes us more replaceable - some guy can take a bootcamp, work on some projects, and bam, he's competition. Programmers are acutely aware of this, and are constantly leveling up as a consequence. (And on that note, if there were gatekeepers, we'd probably be a lot more stagnant as an industry).

Also, I mean, common sense, it's constantly changing what tech and abilities companies require, so how is a gatekeeper system even going to work. I've gone from Rails to JS to TensorFlow, professionally, all in the last 3 years.

There are many different job-roles out there and it is hard to find out what these roles even are. It takes time for people, especially freshly graduated students and career changers, to find their niche. At some point almost everyone gets themselves into situations where they're not competent and then realize they need to either make a switch or get focused.

Rather than viewing such career-exploration failures as "fraud", as some are apt to do here, it is better for employers to take a more active role in developing talent and recognize that early career folks are going to be hit-or-miss.

Still... the exams are harder than you'd need to simply weed out the fakers and cheaters. I can do various linked list and tree operations, set permutations, and so forth, and it's not like I've memorized it. I can apply these things. But the questions I've been asked in interviews... solving that, at the whiteboard, in less than an hour, all I can say is the companies are setting a much higher bar than merely ensuring that someone knows his or her stuff. That's fine, but let's make sure we don't pretend this is all about rooting out people who can't do fizz buzz. You can be pretty good at this stuff and still fail pretty badly at these interviews.

Not only that, but it devalues and dilutes your own degree, which is significantly more damaging monetarily.

And then I mentally run away.

This isn't directly in response to your comment, but...

There's an elitist under(over?)-tone within HackerNews that asserts any less-than-engineer technical role is inferior and attracting of undesirable character. There's a particular disdain for project managers, often for good reason. Few things are more aggravating than a poor non-technical PM. But, in many organizations they're essential and valuable members of a team. Skilled people can have an immense degree of technical talent and no interest in programming or engineering culture.

A fake doctor or accountant is a scandal. A fake programmer is business as usual.

On the elitist over/under-tone stuff: I should have been clearer. I think PM roles, documentation roles, testing roles, etc are all extremely important. However, I don't think these are roles where you should stash incompetent and dishonest pseudo-developers; I think the odds are pretty good that someone who fakes their way through being a developer isn't going to be that good at anything else.

I generally agree with your points, but people don't die or go to jail because of bad code. With a few exceptions. And in those exceptions there are additional checks (checklists upon checklists, rigorous testing gauntlets) to prevent buggy code from causing safety issues.

Technically underqualified people typically result in missed deadlines and/or poor project velocity. That can be catastrophic for a business model, but it doesn't directly result in any kids growing up without a parent.

> Bookout and Schwarz v. Toyota emanated from a September 2007 UA event that caused a fatal crash. Jean Bookout and her friend and passenger Barbara Schwarz were exiting Interstate Highway 69 in Oklahoma, when she lost throttle control of her 2005 Camry. When the service brakes would not stop her speeding sedan, she threw the parking brake, leaving a 150-foot skid mark from right rear tire, and a 25-foot skid mark from the left. The Camry, however, continued speeding down the ramp and across the road at the bottom, crashing into an embankment. Schwarz died of her injuries; Bookout spent five months recovering from head and back injuries.

It's not just spacecraft that kill people due to crappy code. Even something as mundane as a _Camry_ can be fatal if the software team isn't diligent about their work.

http://www.safetyresearch.net/blog/articles/toyota-unintende...

And I wouldn't call safety critical software that can kill people "mundane". It's a minority of code out there and it tends to be really thoroughly vetted, in my experience. I can't comment on Toyota's quality assurance, though.

In 1999, when the US was engaging in a bombing campaign in Serbia against "military targets" that were staffed by civilians, the US bombed the Chinese Embassy, killing several and injuring dozens of civilians.

The US later "apologizied" by saying "sorry, we programmed the coordinates improperly."

Now, I'm not sure if that means some CIA intern college kid task monkey supplied the wrong coordinates to the bomb programmer, or if the bomb programmer typed the (correct) coordinates improperly.

But, software absolutely does kill people when wielded by lazy, incompetent, and often, diploma-holding programmers.

https://en.m.wikipedia.org/wiki/United_States_bombing_of_the...

The pilots themselves can't even enter the coordinates. These planes were programmed by the CIA.

Especially in 1999 and especially with legacy systems, the word "programming" means "providing computers with coded instructions for the automatic performance of a task".

This is similar to how a television network would "program" a list of shows to occur in order automatically.

I suppose my overriding point here is that there are credentialed people with smart sounding degrees whose maximum extent of interacting with computers is typing in instructions.

And therefore, we should be extremely wary when we use credentialing as the litmus test for "should they enter bomb coordinates that will be flying over civilian heads"

Meh. Hiring is expecting other people to train your employees for you.

It's important to hire smart, driven, forthright people, but if you really want them to, say, write readable code, assign them to read Clean Code, make code clarity part of the regular performance review, add it to the code review checklist, etc.

In my opinion, bigger than hiring practices is a lack of communication up and down the chain of command about the importance of good code, who is writing it, and what are the carrots and sticks involved in making sure good code happens. Most people able to hand out raises and job titles work off secondhand and hand-wavy information about technical prowess at best:

"Yeah, he's really good. Fixes lots of bugs and get asked for help a lot."

Of course, that could be because the code's a big mess and he wrote himself some excellent job security. A non-technical PM would know little about this very common issue.

The next company I worked at was very serious about quality. When I started working there, I was told that I was allowed one bug in my code. If there were a second one, I would be fired. I'm not sure if that was true as my code didn't have any (found) bugs. It was thoroughly inspected by two senior engineers before I could even run it on the test bench. We were some months behind schedule but there was not one word about reducing the quality to catch up.

The first company made communications equipment, the second one an air traffic control system.

I've had lines of code go through walk-throughs, inspections, paired programming, the works, and still end up failing somewhere down the line in integration testing.

During the work day, you'd join is in Slack for 8 hours. You'd need to ask probing questions to mock-up our infrastructure and pitch a feature based on "how we work".

One could try to cheat on the first part, but there is no chance one could have bamboozled us during the work day.

For our technical writing positions we had some instances of outright plagiarism, but no instances of anyone trying to cheat the coding sample.

That's amazing! For everybody else that shares my amazement, I found https://www.compose.com/articles/how-compose-uses-interviewe... that touches on said hiring practice, but I'd love to hear more.

"Why did you do this part this way? Would you do it differently if requirement X were different?"

It's immediately obvious if they cheated. Better yet, that's a much better, more relevant discussion than most whiteboard problems.

Somebody who can't do Fizzbuzz in an interview has literally done zero preparation for that interview.

Even so, I usually ask something that is barely more difficult, like traverse a tree, or reverse a sentence.

There is no point at all in asking the hardcore, Google interview questions, as a simple question tells you just as much, which is "do you have a pulse".

Anyway, dominators make sense for arbitrary directed graphs (with a notion of root).

So many degrees are as valuable as toilet paper.

I can't remember the exact change they made for the testing though, it was in the news a couple of years ago.

Our universities also have a high proportion of international students. Predominantly from China, Korea and elsewhere in SE Asia. These students pay much higher fees than Australian citizens. They're used to subsidise the local education market. Classes are conducted in English, but allowances are often made for assessments.

Wait a minute, are you saying all I have to do to be promoted to Project Management is to code really badly?

Hmm. I wonder if C# has GOTOs...

Please don't do this.

Don't hate the player, hate the game.

Why yes, yes it does.

You can also alphabetically sort a list of 30 things by adding those things to a list line-by-line, sorting them in alphabetical order yourself.

I see you've worked in enterprise too!

We should be hiring English and Sociology majors to be PMs and marketing people.

Even if they don't follow the Dilbert Principle path, it's not like there's a universal catalog of how skilled any given employee is; someone who can bullshit their way into a job and can last there for six months is still employable after they're let go when it's discovered that they don't know what a for loop is. Not everyone checks references.

Cheating was rampant. The submittal box for assignments had a big enough slot that smaller arms/hands could reach inside. I saw people do that: grab someone else's assignment, copy it and put both back in the box. The school didn't seem to care.

In Poland where I made my CS degree, girls studying CS are very few. As a result, girl students get a lot more (sexually motivated) attention than on other, less technical subjects. Long story short guys were falling over themselves to help girls pass their programming assignment, do their homeworks for them etc. (Some) girls were very happy to take advantage of it. I wouldn't be surprised if they had guys helping them cheat on exams.

Supply and demand, plus sexual attraction are a part of the problem.

I'm a professor at Carnegie Mellon. In the most recent semester, I taught a large undergraduate intro to programming course (CMU 15-112 is similar in audience to CS50 at Harvard. Our cheating ratio - about 10% - was similar this year, and was also higher than normal). The course is taken by almost all first-year students at Carnegie Mellon - it has about a 50/50 gender ratio. Out of curiosity, I examined the stats for our cheating cases - briefly, so I may have made some errors. But males accounted for about 2/3rds of the cheating cases. It's not clear that that is statistically significant, or if it boils down to "about the same."

Unlike your hypothesis, this is based upon the actual cheating statistics from a class of about 450 people. :-)

Some time over drinks, remind me to tell you the story of the guy who asked his g/f to go get him a snack from the vending machine, stuck a USB drive in her computer, and stole her homework to hand in as his own.

Cheating happens across genders and nationalities. We look hard to identify trends, because we try hard to find ways to intervene before the cheating happens. Most cheating comes from poorly-managed stress. A smaller, regrettable subset comes from people who actively seek to cheat their way through something -- but most of it is simply a bad decision under time pressure.

The NYT article's hypothesis that people are putting more hopes on CS classes for their future careers rings true to me. We see a lot of people who are (a) not doing very well in the class; and (b) (probably mistakenly) believe they need an A or a B in the class in order to succeed in <thing they want to do>. This creates a stressful situation for them, and some respond in a way that bites them in the long run: they cheat. And, because this is CS and we have MOSS and other tools, they get caught.

It could be that those girls just had a cheaty nature and would cheat one way or another. On the other hand, there's a saying "Opportunity makes a thief". It's why during a war looters and marauders become a problem. In other words, some people cheat because an opportunity presents itself. Some horny guys essentially offer to cheat for you, and you have to actively resist.

And I'm not even saying "my anecdotal idea is wrong", because it is not. I've seen it happen that way, it doesn't matter if scale is smaller or larger.

I just highlighted another motivation / mechanic of cheating. And it happens the other way too, with men manipulating women. In my first job (not programming) there was a handsome guy pretty adept at this. He would say things like "(Stretching) It would be so nice if someone opened the window." --- 3 girls rush to open the window before they realize they're being manipulated. I wanted to add to the full picture of why people cheat.

But I'll show you how my original post in this thread can be generalized:

Some people cheat not because of peer pressure, time constraints, inability to understand, "because everyone does", collaborative ethos among computer programmers... but because other people spoil them, and offer to "help" them in exchange for perceived favors. It doesn't even have to be a sexual attraction thing, it can be "helping this guy because his father owns half the town". If you learn you have some perk that really makes other want do favors for you, you're tempted to abuse it more. Sometimes being good at flattery is enough!

Another explanation of this phenomenon is: people are more likely to cheat if opportunities are very easily available. But that facet is already mentioned in the article.

Good for them, not necessarily good for other people and the company in general. And in my experience romantic or erotic relationships in a workplace is a very bad idea. It's probably this reason that a woman on a ship used to be associated with bad luck - in an all-male crew people are likely to fight for her favor, instead of cooperating. Note I'm not saying women shouldn't perform traditionally male jobs, I'm point out that an unhealthy proportion of men to women can encourage extra cheating.

This is called management, and it's well paid.