My reviews feel like a broken record [duplicate]

Question

I don't know how bad it is for other languages, but for CSS reviews, I feel like I keep pointing out the same mistakes every time:

• Lack of shorthand
• Failure to use more semantic HTML5 elements when they're appropriate (eg. section vs div)
• Unsemantic class names

Some of these things I would expect a linter to catch, but it doesn't seem like anyone is using them. Is that just the nature of the beast or is there anything that can really be done to reduce the number of rookie mistakes that seem to be repeated in every single review?

Answer 1

Personal hat on, not mod hat

Burn-out?

It is real, and I recommend you be more selective about what questions you answer.

Code Review (this site) should be fun for you. If you are not enjoying the process, then something is wrong, and we should try to fix it. Without people willing to answer the questions, then our site will languish, but, you can't feel obliged to answer everything.

One 'revelation' I had is that I can be selective in what I answer, when I answer, and how I answer. I only choose to answer those questions that appeal to me, when I have time, and in ways that make me satisfied. perhaps it is because the Java tag, and other tags I frequent, are "busy" tags, that I can feel confident that if there are questions I skip, or partially answer, that someone else will find the gaps, and fill them in.

This works the other way around too, in that often I will get satisfaction supplementing answers that other people have given too.

So, my suggestion is as follows:

1. control the burn-out, and prevent it before we lose you to the site for good. We want to encourage sustained "contributions", if we can. Fewer answers for longer is better than a massive glut and then nothing.
2. trust the community to answer questions. It does not have to be you.
3. find those things that entertain you, and that you can learn from too, and use Code Review as a 'reward' as well.

Things I find myself doing regularly now, are:

1. deep analysis on specific problems that let me explore areas of programming I am new to - new language semantics, specific performance problems, interesting challenges to me too.
2. ignore the questions that don't have "curb appeal".
3. find out what people are talking about - follow the chat room, if something comes up that's interesting, often it will be worth answering too.
4. looking at zombies (unanswered questions that are older) and seeking out more complicated, in-depth opportunities to learn something that nobody else apparently is up for reviewing.
5. seek out meta-challenges - by this, I mean things like: get a tag-badge in something tangential to your core skills - for example, "hunt" a programming-challenge bronze badge, regardless of the language, or hit the review queues, or find a different way to explore what's possible on this site.
6. Ask questions in languages, areas where you are not an expert.

Regardless, whatever you decide, you should find a way to make it enjoyable, and remember that it is about the fun... really.

Note, about that 'fun' part... it's easy for me to suggest it's not about the reputation.... when, obviously it is, at least a bit. On the other hand, I have gained the most satisfaction from some of my low-scoring, or even "broken" answers. Those answers where I learned the most, or invested the most.

Also, without being too "humble" about it, there are people who are new to the languages you are interested in too... and they are looking for opportunities to contribute as well. Even novices can review the simpler, lint-like issues you find in "those" questions... leaving those questions for others is, perhaps, helping Code Review develop other experts too.

Answer 2

Note: This is just an idea. A thought. I do like rolfl's answer

First of all, is there anything essentially wrong with pointing out the same mistakes every time? Except the fact that it can get boring and is tedious to write enough text to explain the issue?

I think that for as long as C++ compilers accept using namespace std;, people are going to continue making that mistake. There will always be newbies. Accept this.

What if it would be easier to post answers?

Would it then be less tedious to point out the same mistakes?

Just like Frequently Posted Comments, what if there also was Frequently Posted Answers?

It shouldn't be too hard to build a tool to make reviewing code easier.

A while ago I created a JS userscript that simplified a bit of the process for me when posting answers, I could select lines of code that I wanted to comment on, and I could copy them to my answer. Then I went through the code copied to my answer, from top to bottom, and added my comments about those lines of code.

Likewise, in theory it should be possible to make a userscript so that you can select a piece of code and a popup shows up asking you "What is wrong with this piece of code?" and you can select something, and you get a couple of alternative ways to write the same thing to choose from, and that is then added to your answer (I have not started to make anything like this, this is just an idea).

Would it then be more fun to say the same things over and over?

Note however, that the strength of Code Review is the human element which is why you should read rolfl's answer once more.