How to be a faster code reviewer

As a less experienced coder reviewing coders with half-decades or more experience on me, I always had a difficult time knowing whether I was looking at something that I just didn&#x27;t understand the purpose of, or if I should question their wisdom.<p>For awhile, this resulted in me effectively checking to be sure it looked &#x27;grammatically correct&#x27;- as in, followed style guides, was linted right, etc. The bullshit stuff.<p>Then a few got through where I had reviewed them, wrote down &quot;What&#x27;s this for?&quot; as a thing to review a month or so later, and they turned out to be <i>huge</i> problems- sometimes performance, sometimes functionality that would break under the right circumstances.<p>Have others gone through this, and if so, how would you recommend &#x27;teaching&#x27; a newer coder how to do quality code reviews of the elder coders around him?

The first point isn&#x27;t something you can do: that&#x27;s something you others have to do for you. Unless you count convincing people to change their workflow, which I&#x27;ve found to be near equivalent to moving mountains.<p>In my experience, it seems to boil down to not being effective with their VCS (or in some cases, the VCS not being an effective tool). But it&#x27;s hard to convince people to go through the trouble of learning something: the short-term cost is just too much, and they seem to be blind to the long term gains. It&#x27;s like convincing someone to use vim (who isn&#x27;t an emacs or equivalently-powerful-editor user).

A related question. I&#x27;m wondering what other people do to ensure quality of outsourced code. I&#x27;m intrigued at Codacy. A lint in the cloud could solve some of my problems, but probably not all.<p>I&#x27;m in the position of occasionally outsourcing non-critical development but not having time myself (I used to be technical; now focused on marketing) or able to distract the dev team to look at code in depth.<p>Do you outsource development? How often do you code review that code? Never, once in a while, on delivery, frequently? Do you do anything else to ensure outsourced code quality?

They missed the most important one, practice. It might sound like I am being snarky or stating the obvious, but like any new task at first you will be slow at code review and it will take up &quot;too much time&quot;. Its a skill, in some situations, its not really too much code to review once you have gotten good at reading code. Everyone can do with being better at reading code too- traditionally people have been better at writing their own new code realtive to their ability to reading and grok their teammates code- and that doesn&#x27;t scale well.

Be sure to add tasks to the sprint for the code review to happen. If it&#x27;s not an actual sprint item, I find it likely won&#x27;t get done effectively. If you have a couple hours, it&#x27;s a great time to train the developers on some of the libraries, code standards, practices, too.

I don&#x27;t understand the argument of keeping your commits small. In my team we do code review after a task is done, not for every commit so the size of the commits won&#x27;t affect the review.

The link to codacy at the bottom doesn&#x27;t work.