I've observed many toy/homework questions

Question

It appears that many review requests are for toy or homework examples (e.g. FizzBuzz).

Is this observation correct or am I mistaken? If observed correctly, I have the following questions:

1. Is it good that many questions are toy examples? and/or would having more real world problems be better?
2. What causes people to ask for reviews of toy example questions and not of real world code?
3. What can be done to change this?

Answer 1

Code Review is not like other Stack Exchange sites. Other sites create a 'corpus' of reference questions and answers to problems experienced by people in those specific subject areas. This difference is most clearly seen in the handling of Duplicates. On other sites, questions that are the same, or similar to other questions are closed as duplicates.

Code Review is different because it is about improving people, not just their code. Taking a person's code and showing them how to incrementally improve their abilities to 'the next level'. Showing them something 'new', or making them think about the problem in a different/better way.

It is my personal hope that the questions and answers on Code Review will build up to a point where people can search for problems that are similar to theirs, and are by people with a similar skill level to them, and then answers to those questions will help multiple people.

It is true that many of the questions consist of toy problems. This is because many people with concerns about their code, are learning to program, and working through toy examples.

It is my belief that these toy questions serve a number of important purposes:

1. It gives people a comparative base to assess their own skill levels.
2. It gives beginners the confidence to ask questions they may otherwise feel are too trivial. It creates an atmosphere where people can make themselves vulnerable by asking for criticism on code they may not be proud of. It is essential on Code Review that people will not feel 'intimidated', or need to be better than they already are.
3. It is a stepping-stone for leading on to more advanced questions.
4. it is a stepping-stone for leading on to people who review code too (it gives questions where you do not need to be an expert/professional in order to do a review).

So, with that background, let's consider your questions:

• Is it good that many questions are toy examples? and/or would having more real world problems be better?

  • Yes, it's good. Many people are learning by doing toy examples, and this is where they are most 'primed' to learn.
  • Yes, more real-world questions would also be good, though, too, but not at the expense of the toys.

• What causes people to ask for reviews of toy example questions and not of real world code?

  • for many askers, these questions *are real world examples. It is the problems they are facing and need to solve for real world results.
  • As for 'professional' or 'production' code questions... there are legal, psychological, and logistical reasons why more code is not presented for review. For example, I work for a company that would require a lot of 'red tape' to be processed before I could 'publish' the code here. More red tape than is practical. As it happens, I work with people who can review my code too, so that helps (me).

• What can be done to change this?

  • I am not certain we want to change this (reducing the toy questions).
  • I am not sure we can make it easier for 'professionals' to post code either, but I am open to suggestions.

You have a few between-the-lines questions as well....

What about the abuse of toy questions (are they being overdone)? Yes, there is a bit of that, and people are creating 'reputation-bait' questions (hey, I am guilty of that too). Still there are very few examples I can find where there was not an underlying question in which the actual task (fizzbuzz, for example) was not just a tool to expose another system for review.

Using myself as an example, I "needed" a hat for WinterBash, and I cannot post 'real world' code to Code Review. I personally know I need to learn some of the more user-facing web-based systems, and that I don't know JavaScript, CSS, or HTML5. I used a FizzBuzz question to present my CSS/JavaScript/HTML skills for review. DO I need to learn FizzBuzz? No, but it gave me a mechanism to expose what I do need help with, in a way that makes everyone happy. Oh, I got the hat, and a lot of people got reputation, and there's now a different way of expressing FizzBuzz for the next person to extend themselves in a different direction. Most people win in this situation.

Finally, having toy questions is better than not having them at all. It is easy for people who are not interested in these questions to ignore them, but it is impossible to have them if they are never posted at all.

Answer 2

You're not the only one to complain about the recent FizzBuzz epidemic. Unfortunately, they appear to be popular reputation-earning clickbait.

In some cases, FizzBuzz does serve a useful role: it's a simple formulaic problem to allow a complete beginner to get feedback on their first attempt at writing something in a new language, particularly uncommon ones such as Brainfuck, AppleScript, or Forth. The problem has the advantage of being universally recognized, well defined, and simple, but more interesting than "Hello, World!".

In other cases, there is nothing interesting about the question at all, as it has been done many times before.

I hesitate to suppress FizzBuzz questions in general, since they can serve a useful purpose. You can always choose to add fizzbuzz to your list of tags to ignore.

Answer 3

Some causes for asking review of toy examples versus real world code, that I can think of:

• For real world code there are colleagues and/or project members who can do the review.
• Real world code has a defined process and tool support other than codereview.stackexchange.com for reviewing (e.g. github commit reviews).
• Reviewing real world code might require the reviewer to know much context of the project's architecture and design.
• Real world code might be hindered by licences and secrecy policies.

Toy examples, on the other hand, are:

• self contained,
• do not have review infrastructure,
• and are known to the reviewers.

And might therefore be easier and more necessary to ask.