Can we revisit "Did I write that code myself"?

Question

• Did I write that code myself?

This is one of the six questions the help center recommends users should be able to answer "Yes" to before posting their question.

I'm not sure I quite understand it though.

Two possible reasons for this requirement were suggested in chat this morning when I was thinking out loud about the question.

1. Assures the asker is invested in the question.
2. Licensing, etc.

I think point one isn't a good reason at all. Why would someone post a question to which they're not interested in the answer? Moreover, other Stack Exchange sites don't seem to think the situation being asked about has to apply directly to the person asking or come from a personal experience of the asker. Several SO questions are asked about code snippets from programming books or websites. Questions on other Stack Exchange sites might be about something one saw on TV, heard a rumor about, etc. And ultimately, I think we should be more concerned with the question's value to the community at large than the question's value to the asker.

As for point two... there's plenty of code that I've not written myself, but I might own at least a part of a license too--any code I've written as part of a group, etc. Moreover, there's plenty of code that is protected by a license that would make it perfectly legal for posting on CodeReview--for example: anything already posted on StackOverflow or CodeReview as a question or answer. Though if it's a StackOverflow question it's probably off-topic as non-working, and if it's a CodeReview question, it's probably a duplicate--but answers should still be fair game.

---

So, for reiteration:

• Rather than worrying about a question's value to the asker, we should be more concerned with questions & answers that provide value to the community at large.
• We can & should worry about licensing and rights in the same way StackOverflow does. If someone posts code they didn't have the rights to, it is the responsibility of the party that owns the rights to get in touch with CodeReview/StackExchange to request the code be removed.

Is there any thing I'm missing in these two points? Are there any other reasons why we should keep the "Did I write that code myself?" rule that I've missed?

---

As an example of where this rule seems a little silly to me, there's this question which was bumped this morning with a new answer then closed since the asker clearly is not the original writer of the code--he linked back to the SO question he copied it from.

Answer 1

To add to the discussion and to clarify my point...

I'm not saying we should only eliminate this rule. It's highly likely that we need different, more specific rules in place of this rule.

The problem with this rule is that there are questions that could easily be on-topic if it were for this rule alone. Yet this rule seems to exist to discourage certain other types of behavior that we seem to think will exist simply by allowing user's to post code they did not write.

In fact, the description in the actual close message and the description in the help center are a little different.

The actual close reason:

Questions must involve real code that you own or maintain. Questions seeking an explanation of someone else's code are off-topic. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example.

As a matter of fact, I'm actually pretty okay with the close reason as written in the close reasons list.

• Code explanation requests are off-topic. This is Code Review, not Code Explain.
• Pseudocode, hypothetical code, and stub code are off-topic.
• The code must be real code that own or maintain.

Code that I own or maintain is very different from code that I wrote.

Suppose I've got an Open Source project. I'm the owner and primary maintainer of the open source project. A user has submitted a change to part of my open source project. The project is open source, and the user has submitted his code to the project, so there's no legal/licensing issue in posting the code. I am the owner and maintainer of the project, so this is (at least potentially) code that I maintain. I want this code reviewed by a fresh set of eyes before I incorporate it into the project. Where is the problem in posting this code assuming it is otherwise on-topic?

Perhaps I might make a decision on whether or not to incorporate the code in the project based on the reviews I get here. This is certainly less vicious than firing (or not hiring) someone based on a review... but ultimately, how does what I personally do with the review even relevant to whether or not the question itself is on-topic?

How about code that I hired out? I'm working on a project, and I needed help getting a specific part of it working, so I contracted out a chunk of the project. It's already done and paid for, there's no decision about anyone being hired/fired, but I think the code needs a second look, and if it's something I hired out to do, then it's probably something I either don't have the time or ability to review myself. But from now on, it is code that I will be maintaining... so I'm still heavily invested in making this code as good as possible. Assuming everything else about the question is on-topic, is it right for this question to be off-topic just because I didn't personally write the code (and make the mistake of admitting that in my question)?

I think these sorts of question is more than fine.

Some have voiced concerns about a user posting code he does not own would not be able to provide necessary context or details about the code. Fact of the matter is, this happens even with the current rule with users claiming (and we'll give them the benefit of the doubt) the code was written by them. They sometimes just completely ignore comments asking for clarity.

But if this is a problem, there's already an existing close reason for that:

unclear what you're asking

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.

This close reason applies regardless of whether or not the question author and the code author are the same person.

We could even change the help center to make it clear that we don't want questions for which to determine someone's career, whether or not to hire/fire someone, etc., and if necessary, create a close reason just for this sort of question.

---

Ultimately though, the actual close reason itself is okay. The problem is with the clarity the help center gives on the close reason.

I am recommended that the help center's on topic page change the following question:

Did I write that code myself?

and replace it with this question:

Am I an owner or maintainer of this code?

Answer 2

This issue has been discussed a few times.

Licensing is the one reason cited most often, and it's and easy one to use as a clear-cut thing. If you don't own the code you can't publish it and change the licensing on it. You are right though that there's a lot of code that may not be 'yours', and is still licensed to allow posting here, like other code on Stack Overflow. In other words, licensing reasons are actually not a great reason to say 'it must be your code', because there's a lot of code that does not have licensing problems, and even if it did, it's not Stack Exchanges problem that some contributor broke some licensing terms. The question can be removed if there's a conflict.

The second reason cited often, is based on an actual question that was asked which went on the lines: The person who wrote this code works for me, if you think this code has problems, I'll fire them. It is clear that no-one wants Code Review to be a place that determines the future of employees and their careers.

Asker's investment is not something I have heard discussed much as a reason for the own-code-only. I can understand the sentiment though. Reviewers spend a lot of time on each question, you want the asker to actually pay attention to the reviews so that you actually are adding value with your review. How does this affect the own-code issue? It does not really affect it at all.

---

So, what are the real reasons for the own-code requirement?

1. Licensing plays a part, but a small one
2. Reason for the review plays another: If the purpose is to improve the code, then fine, but if the purpose of the review is to determine someone-s career, then no, not fine.

But, the biggest reasons I (personally) think the own-code requirement is valuable is:

• Code is a personal thing, it's an expression of creativity, and the product of hard labour. People are emotionally 'invested' in their code.
• Code often requires in-depth explanations for the reasons certain choices were made
• Good code reviews are also often very critical of the code, because, often, code has problems.
• Criticism is felt most 'keenly' by the creator of the code, because the criticism is also criticizing the programmer's creative abilities, dedication, and effectiveness.
• Constructive criticism is a personal attack, and has to be delivered in a way that results in a positive outcome.

Regardless of who posts the question on Code Review, any review given is delivering criticism (or praise) to the the author, not the asker.

Additionally, if the reviewer has questions, the best person to answer them is the code's author.

So, on the receiving side, three things:

1. regardless of who posts the question, you are criticising the author.
2. criticism needs to be delivered tactfully
3. unwanted criticism is seldom welcome, and mostly hurtful.

On the reviewer's side, two things:

1. If I am dishing out criticism, I want to be giving it to the person who is being criticised.
2. If I am investing my time in the review, I want to be able to ask for more details on why choices were made, and other constraints imposed, and I want the answers from the most reliable source. My time is not worth it, otherwise.

Without the own-code requirement, code review would be no better than bash.org, or codecrap.com, where people go to laugh at, and ridicule others' mistakes.

Answer 3

I disagree that code should be self-written.

There's something flawed about the notion that...

But, the biggest reasons I (personally) think the own-code requirement is valuable is:

• Code is a personal thing, it's an expression of creativity, and the product of hard labour. People are emotionally 'invested' in their code.
• Code often requires in-depth explanations for the reasons certain choices were made
• Good code reviews are also often very critical of the code, because, often, code has problems.
• Criticism is felt most 'keenly' by the creator of the code, because the criticism is also criticizing the programmer's creative abilities, dedication, and effectiveness.
• Constructive criticism is a personal attack, and has to be delivered in a way that results in a positive outcome.

Namely... if this is true, then what can others learn from a review of the code? Nothing? Doesn't this go against the idea that others can learn from the answer of a question? You know, the main point of SE Q&A sites?

If a person were to post a question on CR, and he were to die the next day, would you close the question? What if he didn't die, but just never came back? No, because such a thing would be ridiculous. Others are supposed to be able to learn from a code review, even when it's not their own code. So I posit that that exact point is irrelevant.

1. regardless of who posts the question, you are criticising the author.
2. criticism needs to be delivered tactfully
3. unwanted criticism is seldom welcome, and mostly hurtful.

1. If the code is part of a project that I'm working on, but I didn't write it myself, I don't care how the original author feels about me tearing their code a new one. Get rid of those feelings; if you feel you OWN the code that you've written and can't let anyone comment on it or change it, then you are a threat to all projects that you work on. Because you haven't learned how to share the sand in the sandbox.
2. This statement is true, but the reason behind it is wrong. Criticism should be delivered tactfully at all times. However, you can't be seriously telling me you can grasp how an asker will react to statements based on 1 page or less of text. How do you know whether you're being too harsh? The only time your code is WRONG is when it doesn't perform as advertised. In all other cases, it could have been better, but it's not wrong. People who can't take such criticism shouldn't be writing code in the first place.
3. The criticism is not intended for the author! It is intended for the code! To take an "attack" on your code personally is to be unprofessional. In the event that a new maintainer posts the code up for review, he wants to know how to improve the code. He doesn't want to rub it the original author's face. In the event that the original author finds the question and reads the review, he should realize that when he gave up the license to his code, this is one of the things that can happen with it. It can get changed!

---

Personally, I feel that

• The license requirement must stay.
• The asker should want the presented code to be good code. That is, THEY should wish to know the answer.
• The asker should be able to clarify and explain their code. Questions that are unclear can be closed as "unclear what you're asking." (That's what it's for!)
• The asker should take ownership of the code. That is, by posting the question, they are responsible for the code. They have to provide the reasons why the code is written the way it is. If they can't answer then the question is closed - code without context can't be reviewed!

For the posted question, I'd close it because:

• The asker has a license to the code. Leave open.
• The asker has stated an interest in knowing the answer. Leave open.
• The asker didn't need to clarify their code (nobody has asked and the code seems simple enough). Leave open.
• The asker hasn't given any context in which the code will be used. (Close.)

That last reason is the valid reason. Requirements are hard. By presenting only the code, you present flawed restrictions. Reviewing the solution to a problem is part of the code review and due to the way the code is posted, such a review can't be made.

If they had said "I'm making a similar game and wondering whether this is a good way to determine block strength in my Block class?" then BAM you'd have context. And we could have gone "No, this is not future-proof. What if you want to make pictures out of blocks later, but still have a balanced level?"

Without the own-code requirement, code review would be no better than bash.org, or codecrap.com, where people go to laugh at, and ridicule others' mistakes.

Downvote all answers that take on a derogatory attitude. You want to review someone's code? Sure. You write your answer whilst describing in detail how stupid they are for doing things like this? Guess what happens on Stack Overflow if you do that? You get downvoted for being an asshole. And so should the answers here. If you're going to point and laugh, eat downvotes. If you're still gonna point and laugh, eat a ban. Pointing and laughing at code is not the way to improve code. Pointing and laughing at askers is not the way towards a healthy community. This is a StackExchange website, and that's different from the rest of the internet.

---

Feel free to comment with more questions like this and I'll be happy to apply my new list of reasons to them to show you why I'd have them be open or closed.

Answer 4

I think the primary purpose of CR is to improve the quality of your code. And not just the code you post, but also your future code. And the way to do that is to post your code, so that we can point out the mistakes you're making.

Answer 5

If it were not for this rule, I would have submitted a number of questions about code I have found on GitHub.

I find that this rule keeps the flow of questions more manageable, which is a good thing at this point.