How to offer code-reviews to a junior colleague who has been in the office longer than I am?

Question

I am a senior software engineer, on an algorithm development team, with the algorithm engineer title (I wanted to stop being a software engineer by title, and move to algorithm development, which I did).
I am quite new at my Startup (some months).

On my team is a junior engineer, who is extremely sharp and enthusiastic, about algorithms. Not about software or team-work. She is a very nice person, but doesn't care much about software methodology, or writing code such that others can benefit, or benefiting from others' code.
This is apparent in many monoliths, a lot of mixing up "what" with "how" (lack of encapsulation), bad naming, (very) slow code, multi-typed variables (python) and a general write-only attitude. I could go on.

I tried to talk about it a few times, and she said frankly, she doesn't really care about software engineering or coding. She wants the algorithm to work for her, and that's all.

This situation makes life very difficult for someone who wants to work with her code, and even more frustrating when she doesn't adhere to existing conventions on existing code. Since she started some of the repos, she is considered their owner, and doesn't go through PRs, which is what I would like to change, in order to at least prevent design catastrophes, if not improve quality overnight. Not to mention her gradually improving, and helping the code base.

The team leader is a very startup-minded person, who is also not a SW major, and though he cares about improving code-collaboration, in practice, he prefers her to write fast, and not learn to code better. He doesn't deal directly with her code. She also works a lot of overtime, for fun, so if her code gives her trouble, that's how she deals with it.

This also prevents me from coding fast using her code, as she is the only one that can read it fast. This forces me either to be slow, or refactor her code in order to become faster overtime.

---

I would like to prevent this in the future, and gradually improve the team's code quality.

I thought a good way would be to do regular code reviews with her, but I'm afraid I am stepping out of my place.

Meanwhile, technical debt increases much faster than is required, and coding is not a tool, but a liability.

How can I approach this?

Answer 1

You cannot. Your team lead is a paper pusher and not a developer. When called to task, he's going to kowtow to his management to deliver fast results. Such a leader will have no concept of engineering software for long term reliability, maintainability, or scalability. The junior developer's values align more with the team lead's than your own, and she has no reason to change because the crappy development style is encouraged by the team lead. You, my friend, are the odd person out.

The junior developer will balk at the idea of code reviews -- claiming that it will slow her down -- and the lead will support her.

You can plead with the team lead but he lacks the experience and vision that you have, and can't relay your concerns to his management in a way that they'll listen and be concerned with any criteria other than "fast".

Unless the management changes, it's not likely to improve. They'll have critical hiccups, and likely stress you out to fix things as they come, but never address the root cause (poor practices) until there's a catastrophic loss of money or credibility from some incident.

I hope you have outside interests in which you can express your good judgment and feel accomplished, because you're just not gonna experience that on this particular job.

Answer 2

I think you will increase the chance of her accepting code-reviews if you present it as "peer-reviewing each other's code". Instead of "me controlling your code" which seems to me is how you want to approach it. When you start doing code-review as peer-review she might even teach you a thing or two or spot some errors in your code.

Answer 3

Two options:

• Easy: ask the junior to review your code instead. They will learn a tonne from it, and might eventually want to try to have their code reviewed too.

• Better: work with the entire team to institute a process where every single line of code that goes into production has been reviewed by someone else.

  That your manager is opposed to this is not an issue. You are the software engineers. You are the experts on how good engineering happens. A surgeon should never be talked out of washing their hands by their manager.