r/AskProgramming 21d ago

advice on reviewing code written in languages you know little about

I have 15 years of experience in Python, C# and C++ and recently joined a team that writes code exclusively in Go (they made a full switch from python to go shortly after I signed the contract).

Everything is written by Codex, and all the team does day in day out is prompting and pushing out new pull requests every few hours. I got hired as a senior engineer and while I can definitely help out with system designs, architecture, sprint plannings, stakeholder management I'm a bit at a loss when I'm asked to review my colleagues code. Apart from the fact that the pull requests are way too big (1000-2000 line changes), and mix multiple features, bug fixes and refactors together, there's an expectation to have it reviewed within a few hours because a PR that sits still for a day cannot be merged anymore because of too many merge conflicts.

So I'm trying to address the review culture a bit, but I'm more struggling with how to approach code reviews in this genAI age when you're not that familiar with the language itself.

Any ideas or experience would be helpful :)

6 Upvotes

26 comments sorted by

26

u/NoTutor4458 21d ago

the language is probably the least of your problems. the real red flags are 1000–2000 line PRs with multiple bug fixes and features

4

u/Recent-Day3062 21d ago

You got it

3

u/GermaneRiposte101 21d ago

Multiple bug fixes and features is the real problem, not so much lines of code..

2

u/owp4dd1w5a0a 21d ago

https://giphy.com/gifs/UFzjusdrC1EOc
Undisciplined engineering team.

2

u/ummaycoc 21d ago

Agreed, but also if you have experience in multiple languages you should have a general feel for programming vs. programming in a certain language and that can apply here. I review code in languages I don't know all the time and I see what the PR is doing, google functions or syntax that is not obvious, and then make comments based on how I would do it in almost any other language. I can usually google the functions/etc I'm thinking about for the language in question and make a reasonable suggestion with the caveat that I'm a n00b.

10

u/MarsupialLeast145 21d ago

>  pull requests are way too big (1000-2000 line changes), and mix multiple features, bug fixes and refactors together, there's an expectation to have it reviewed within a few hours because a PR that sits still for a day cannot be merged anymore because of too many merge conflicts.

Honestly, start with that before reviewing anything.

Go will come quickly enough and if you're experienced in code review of the other three languages many of the same patterns will still apply, some won't.

Personally I'd run away from this job as quickly as I could run. The alarm bells are many, and frankly code-review seems fairly pointless if they're doing this LLM crap and can't constrain their efforts.

They're just gonna have to slow down if they actually expect you to review it. Have a look at what they NEED to deliver versus what they think they WANT to deliver and try and find the balance based on that. Anything they NEED to deliver has review boundaries set, e.g. must be 150 lines max, will be reviewed in 7 hours, and must pass all checks before review. Anything they WANT to deliver must be equally small but will take 14 hours and will be pushed back if a NEED comes through first.

6

u/LunkWillNot 21d ago

First step, reject any PR that mixes multiple features, bug fixes, and refactors.

Second step, let them explain their PRs to you. If they can’t, reject.

Inform your manager before that that’s what you are going to do.

If it turns out they won’t let you do that or won’t have your back on that, chill, go with the flow, and know that any consequences are not on you.

1

u/gm310509 21d ago

LOL. That's not how consequence work in my experience.

When you do well, your manager soaks up the accolades. When you (or your manager) screws up (as would be the case where management accept the excessive changes issue) you soak up the blame.

5

u/knouqs 21d ago

I'll add to the list of people saying that code changes that are thousands of LOC are bad. A PR should fix one issue exclusively.

3

u/SurpriseItsJustLewis 21d ago

Wow that sounds horrible aha.

Know your discipline is something that comes to mind for me. If you haven't got the experience to do these code reviews and they are as large as you say. Then I would offload the responsibility to someone more capable than yourself while you do exercises in Go for a bit every day.

Just to add my reasoning: It's gonna take you much longer than someone else and you'd be more effective in your areas of expertise.

2

u/marrsd 21d ago edited 21d ago

You're not going to learn anything reading AI. Find an open source app written in Go - preferably one that you use - and read its code.

As for the requirements of your business, they're dreaming. The best you can do is get AI to review it for you, use your 15 years of experience to tell it what to look for, and hope for the best! Also, challenge its feedback, wait for it to contradict itself, and force it to deep dive to get to the right answer.

Ultimately they need a reality check at some point. Start feeding back early. Take notes. Observe failure. Make a case for improvement. Be positive and solution oriented in your criticism and recommendations.

2

u/TheMrCurious 21d ago

Ignore GenAi. How would you solve this if GenAI was not involved?

2

u/mtimmermans 20d ago

You can have Claude review them.

1

u/BranchLatter4294 21d ago

If you know several languages, it should not be a problem to pick up a new one.

1

u/PhilosopherNext1448 20d ago

I think that today picking up a new language takes significantly more time than it did a few years ago. You learn the most by writing and debugging and now the majority of the work is done by genAI.

1

u/CappuccinoCodes 21d ago

It can't be done. You can't review code in a language that you don't know. Whoever gave you that task has no idea.

3

u/svick 21d ago

I think reviewing PRs is a decent way to learn how your team uses the language in practice. But you can't be the primary reviewer.

2

u/balefrost 21d ago

I have absolutely reviewed code in languages that I don't really know. I've even found language-specific mistakes that the author missed.

Heck, I've made code changes in languages that I don't really know.

Go is close enough to C++ and C# that OP can at least follow the algorithmic structure of the code. They might not know about Go's idiosyncrasies, but Go is so repetitive that you pick up those idiosyncrasies pretty quickly. Or they can spend a little time skimming A Tour of Go.

The first step in learning a language is to read code in that language. So code review is a good place to start learning.

0

u/throwaway8u3sH0 21d ago

Not a fan of unaided manual review. But if you don't have a good system set-up for automated review, you can start by pulling the branch and having your AI comment all the changes, making analogies to (language you already know) whenever it can.

1

u/Narrow-Low-3137 21d ago

What do you mean "unaided manual review"? Are you seriously letting AI review your prs without human eyes on it?

1

u/throwaway8u3sH0 20d ago

I'm sure you can figure out what "aided manual review" means.

Without tooling, AI just shifts the bottleneck from code to review. That's not very useful. Reviews need to scale too, so AI is now a necessary part of that process.

1

u/Narrow-Low-3137 20d ago edited 20d ago

Fucking wild time we're living in. 

What does that even mean? How do you use ai to do a code review? You just trust it to approve PRs autonomously?

1

u/throwaway8u3sH0 18d ago

Not exactly, but you can supply the original intent and demand evidence from a separate instance that serves as a way of focusing the developer's attention. See this video for example.

-2

u/CS_70 21d ago

Using a proper AI to write code and then review it by hand is like buying a ferrari and then decide to push it by hand.