Newbie question about voting

Question

Voting while participating

• As it's a contest it doesn't make sense to vote for other answers - does it?
• Should I vote for the puzzle? Isn't the participation already a vote?

Voting while not participating

• Beside the code-length, what are other usual motives to vote?
• Considering that i have not a glimpse of understanding of most of the used programming languages, how can I vote objectively?

Answer 1

Voting while participating

• As it's a contest it doesn't make sense to vote for other answers - does it?
  • It is a contest, but I like to think of it as a challenge. And everyone participates individually on their own level. You'll see that many users help others golf their submissions in the comments. There's even a Sportsmanship badge rewarded to people that vote on other answers.
• Should I vote for the puzzle? Isn't the participation already a vote?
  • You should upvote the puzzle if you think it's an interesting and well specified challenge, and downvote if it's uninteresting or badly specified. Note that it's perfectly fine to not leave a vote, if you think the challenge is just mediocre, or you don't have the required background to understand if it's a good one or not.

Voting while not participating

• Beside the code-length, what are other usual motives to vote?
  • Don't vote for code-length alone, but rather the approaches they use or how well golfed they are. As you say, you don't understand most of the languages used here (neither do I). I would recommend you read the explanations (if provided), and judge if you think it's a good answer based on that. I often upvote well explained answers, even if they are not the shortest, because it shows that a lot of effort was put into it.
• Considering that i have not a glimpse of understanding of most of the used programming languages, how can I vote objectively?
  • I suggest you vote based on the explanations in this case. If none is provided, or you don't understand it, then don't vote.

Answer 2

Do not vote for code length!

Code length is not a good way to determine what to vote for, because it isn't a good indicator of quality. A golflang submission can be thoroughly uninteresting and still beat out the most clever and well-golfed Python or Haskell submission out there.

Of course, golfing languages can have clever tricks as well (abusing the built-ins well is no easy task), and you should vote on them if they do, but don't do it merely because it's short.

By voting, you help to indicate that a submission is high quality. Quality is, of course, subjective—if it wasn't, Stack Exchange wouldn't need humans to vote. But many of the following things, to me, can make an answer good:

• An impressively high-scoring solution, especially when a lot of work went into creating such a solution, such as brute-forcing for an optimal program or doing lots of math.
• An impressively thorough explanation, such as many of Martin Ender's esolang answers.
• A valid answer to an impressively difficult challenge, such as the Quest for Tetris Project.
• An answer to a nontrivial challenge in a language that is very hard to use, such as Hexagony, Brain-Flak, or Malbolge.

You can only be a good judge of the quality of a submission if you understand it.

Of course, what you vote for is up to you (short of voting fraud). Try not to let the existing votes on an answer influence your own.