How do you stay awake when doing code review?

Why are you reviewing React if you don't "get it"? What is the goal of the review?

I have reviewed code in Go that I don't fully master, having the developer do a "pairing" kind of session, where they walk you through their PR does help a lot!

I might be alone in feeling this way, but when I see "team lead" and "a big part of my job is doing code reviews", it raises a red flag for me.

Is feels like "the boss" who is "approving" code before it gets merged in.

In any team I've been a part of, I want the tech lead contributing by writing code, doing design, etc. and I want everyone reviewing code, not everything piling onto one person.

If you actually mean stay awake, I highly recommend getting more sleep. Losing interest or zoning out is one thing, actually falling asleep is not a problem with the language or being remote.

Why not do the code review with the other person and get them to explain what they are doing and why. You can cover any non-functional issues like styling, performance security as you go. Surely this is the point of working in a team?

If you don't really get/like React maybe you should do a small project in it?

> In contrast, I don't get React

What's the point of reviewing something you don't understand? I'm a tech lead as well within a remote team and I don't review such PRs.

How big are the changes? Most reviews I do are smaller bits of code so I can see what it does quickly and highlight any issues

If u don't get react and are expected to review it then u need to learn it

I used to have trouble staying awake whole reading books. Then someone told me it was because I was reading it passively. I treated books like a conversation with the author and started asking questions.

Instead of looking for errors, you should look to understand the code. Why does it do this? What is it doing? How would I do it? Search up certain terms that you don't understand.

I normally am not very fluent in the code I review, but code reviews have been a great way to learn proficiency.

It sounds like you’re just reading code with zero context and no further information about the design, all the mistakes along the way and the code that didn’t make it. My first recommendation for large changes would be pair programming (there’s plenty of screen sharing tools out there) or at the very least having the developer take you through the code.

This might be stupid but print it out and read it while walking or maybe on an ipad or something?

We keep it short. If something requires a lot of changes, we split up the merge requests.

Go to bed earlier. You’ll be surprised what can hold your attention after a few days.

amphetamines =/ I don't recommend them but they do make it easier to program

A walking desk.

I have a similar problem. I find react to be needlessly verbose; half way through a moderately-sized PR and I realise I have no idea what I'm looking at, because I wasn't paying enough attention to the context.

Different companies have different things they focus on in PRs. If you're looking at the shape of the code, then that will probably jump out at you (is this file massive? Does there appear to be lots of heavy nesting? Are the functions short and snappy?) In that case, you'll probably find that despite being disengaged from the code, anything terrible is going to jump out at you.

In others, you're expected to be a wetware parsing machine, finding bugs or unintended functionality. In that case, if you don't "get" the flow then you're never going to be as thorough as with python. In that case, you're essentially doing someone else's job, and at some point you have to decide to either make it your job (i.e. devote yourself to only writing react components for a month, become fluent so that you can grok it effectively) or pass it on to someone better equipped for the job. That is in no way cheating or shirking - that's effective management and delegation. Use the strengths of your team. If that's not a possibility, e.g. your team is too small, then the first option is your only choice.

Another thing to point out is that the architectural patterns you are used to very much influence the way you view the code. React's architectural patterns are far more messy than python's, in that you need to keep several threads in your mind at once (where does this state come from? Props? Params? Redux? Events? Events stored in redux?) and can be a bit mind bending given the very limited window you see from a PR.

So that's my general advice. I'd say, cut yourself some slack. If you need help focussing, from tiredness or fatigue, keep a notepad handy and write down each filename, and count the number of methods and if statements in the file. That will force you to at least look at every line twice - once potentially without paying enough attention, second to do your counting.

Now for the specific advice: If you are outsourcing your work to a team of developers who you can't trust to PR between themselves and are experienced in the tech stack that is not one you get, then either:

a) You shouldn't be using that tech stack. There is nothing that can be achieved in React that can't be done in more traditional JS frameworks. New technology should only be introduced by teams that you trust implicity to get it right between themselves. React is the problem here.

b) You shouldn't be using those developers. I know, they're cheaper, but are they? Really? In the long run? They are the problem here.

c) You need support within your organisation. Doesn't need to be another lead developer, could be a competent middleweight who knows your standards and can apply them consistently. Your isolation is the problem here.

There are probably more advices I could give, though maybe that's more advice than you wanted. Good luck!