Can I refuse to review the work of the team tech lead if I have a lower grade than they?

Question

Long story short, I work as a data scientist in a small team. The working environment is quite unusual. Key facts:

• The lead data scientist's technical expertise wasn't checked during the interview (it turned out they didn't know how to use Linux, git, Python, never heard about concepts such as pull requests, never worked with a server before, etc.)
• Their managers don't know much about data science (admitted by themselves), so the lead data scientist has survived so far.

I am responsible for a specific project, related to a niche area where I am truly a SME. The project is in production and works fine.

The lead data scientist decided to replicate my project, they made some changes, and they were successful in selling a fair amount of hot air to the senior managers about the need to improve and revamp my models.

Now, the senior managers want me to review their code and improvement claims, and check if there is anything of value that could be merged into the project I am responsible for.

I don't see the benefit of reviewing thousands of lines of code, written without unit tests, and scrolling through functions 2,800+ lines long (According to the senior managers bad code is fine as long as it works).

In my view, it is not my duty as a junior coworker (who is at least one grade lower than the Lead data scientist) to review the code and modelling of the technical lead.

1. Should I directly refuse to analyse and review the twin project of the tech lead?

2. I feel annoyed about the existence of this twin project. Would I be right to complain about it, or is it normal in the industry to duplicate projects and step into other coworkers' shoes?

3. The compensation is competitive but I am concerned that I am not learning much in this team and a lack of technical development could come to haunt me later and might hinder my career. Should I leave even taking a pay cut, or even without a next job lined up?

Thank you.

=======

Edit: Thank you for all your kind answers. They've brought clarity to my mind. I've gathered that:

1. It is my job duty and the professional thing to do to review models and code, no matter who has written it, or how poorly written it is.
2. Ultimately, the senior managers above the Lead are the ones who bought the Lead's hot air and authorized a cloned project (with or without being tricked into it, which is irrelevant), so they are responsible for the awkward situation, even more than the Lead.
3. I should choose my next company more carefully, not everything that shines is gold.
4. I should resign ASAP.

Answer 1

Should I directly refuse to analyse and review the twin project of the tech lead?

Directly refusing an assignment typically has significant consequences anywhere from a stern talking to to dismissal. You took the King's shilling and the King expects reasonable work in return

I feel annoyed about the existence of this twin project. Would I be right to complain about it, or is it normal in the industry to duplicate projects and step into other coworkers' shoes?

Your feelings on the matter are completely irrelevant. Control your emotions and start to think like a professional. What are your goals and what actions will help you achieve them? Complaining is almost never useful. Making practical, actionable and constructive suggestions often is.

I am concerned that I am not learning much in this team and a lack of technical development could come to haunt me later and might hinder my career.

that's a valid concern, especially if "According to the senior managers bad code is fine as long as it works)."

Should I leave even taking a pay cut, or even without a next job lined up?

No. Figure out your personal priorities, what you really want and then create a plan to actually get there. If this plan doesn't include your employer, than it's time to start looking. Before you do, make sure that you fully understand WHAT you are looking for and how to evaluate companies against your requirements during the job search. Once you have a job lined up that you are confident about (based on objective criteria, not gut-feel), you can resign.

Answer 2

To be fair, as a junior coworker, I would have thought that your job is to do whatever you are asked to do, as long as it in the field you were hired for. So, to me, it looks like you need to do it. The fact that they are asking you to review it means that they have some trust/faith in you.

Not every company works the way it should. I have worked in such a company too, where duplicate projects were going on all the time. You can't reason with anyone. And many companies think that the quality of code is immaterial as long they can deliver and it appears to work.

Ultimately it is your choice. If you are not learning much and are not happy, then find a job first and then let them you know you are leaving.

Answer 3

You should not refuse to review the work of a colleague based on your role, paygrade, or place in the organizational hierarchy.

On the Software Engineering Stack Exchange, I've written about reasons why you would want to conduct a code review. Regardless of the relationship between the person who produced the work under review and the reviewer, there is something that can be obtained from the act of conducting a good review of the work. Because there are almost always benefits for both people regardless of their relationship, I don't see that as a good argument for not carrying out the review.

Review is also a cornerstone of professional conduct. Whether it's engineering organizations like the IEEE, computing organizations like the ACM or BCS, or data science organizations like the AdaSci, you'll find the obligation to seek, accept, and offer review and criticism of technical work (along with correcting errors based on that review and criticism). Refusing to participate in technical reviews is, at best, unprofessional behavior.

If you have concerns about the ability of your coworker to do their job at an appropriate level, those are best addressed through the management chain. Participating in reviews and having concrete evidence of the quality of the work is the best way to obtain that evidence. However, if that doesn't work or you're concerned about your current organization not being able to support professional development, then you can consider seeking opportunities in an organization that will. If you do decide to go elsewhere, the timing of those actions or what kind of compensation and benefits package you are willing to accept are personal choices that I can't help you with. However, until your last day, you should maintain professional behavior, which means, among other things, conducting reviews when asked.

Answer 4

You already have reviewed it:

thousands of lines of code, written without unit tests, and scrolling through functions 2,800+ lines long

That seems like valid feedback you should give to your colleague. If you think someone has written unsatisfactory code, the code review is the place to bring that up. By not doing so, apart from the consequences of refusing a direct instruction from a superior, you are relinquishing your power to do anything about it.

Answer 5

You have already gotten plenty of good answers from business perspective. Indeed: refusing to review will only damage your reputation and career.

So yes, you need to fulfill the manager's request.

However... that does not mean you have to scan through thousands of lines of garbage code. Sometimes in code review you find issues that make it pointless to continue the code review to find other problems, because the entire code will have to be rewritten anyways. So you just give the feedback you have, and then stop reviewing any further.

In your case, a couple of things you could point out:

• No unit tests. Please add unit tests.
• Pull request too big. Please split up in several PR's, or at least several commits.
• Code quality not up to company's standard. Please see styleguide and/or run linter
• Scope creep: it's unclear what this commit meant to do. Please link relevant ticket.

(This last line is a reference to you saying the manager has just decided to write some code, and has asked you to check if there's anything that can be of value to you. If I were this guy's manager, I'd tell him to stop wasting time and get on with his own work...)

By doing this you:

1. Did what the manager asked
2. You showed the manager that the lead is incompetent, while you are not
3. You helped teach the lead, and in doing so gained credit with the management

Answer 6

Juniors can and do review code of someone more senior. Either as a learning experience or in some cases someone fresher might have more up to date knowledge of how things are done. I've changed my main tech stack and have picked up on the latest approaches and new language features (which is pretty common to other languages) as such I'm unburdened by the old way of doing things.

A review means different things to different people so get an idea of what is meant or if they agree with what you thing a review is. Some people believe a review is a cursory check, a check on good practices, a check for correctness of the problem being solved, others its much more in depth including getting it running on your machine and checking the code/tests run. A review also should occur when there is still budget and time to correct the mistakes and a willingness to take on board reasonable improvements.

It sounds like potentially they assume that there a good stuff in the other project you should take on board, while it's quite possible you've got good stuff they should be taking on board. It also sounds like from the size of the review project that it's been left too late, or sometimes for prototypes there do have to be relatively large to start with in which case the reviewee should be giving some guidance where to start and in which order to approach the review.

Submit the review in parts and in good faith, and if they aren't willing to take on any of the feedback, do ask what the value of spending the companies time on the review, if it's just a rubber stamp exercise.

Answer 7

You are missing a couple of options:

4. Do the minimum amount of work to satisfy this request, make sure that you are not involved in the project, and let the project fail.

Data science is (still) a hot, new field and very, very few C-level managers understand it. There are millions of companies out there that say that they are "data-driven" where every manager still goes with their gut.

If you are under 35, not learning or getting anything out of your work, have been at a job for at least 1 year and do not have an significant financial responsibilities (children, a significant mortgage or other debt, etc) -- and of course, think you can get a new job within a month or two -- I would leave ASAP. If you are not learning anything, your future salary is decreasing with every day you work.

Lastly, regardless of where you work (in the world) and what you do, refusing to do work is almost always grounds for termination. However, explaining how long certain things will take and asking for a clear list of priorities is often valued -- and also almost always a good alternative.

Make sure that your work you like and learn from has a higher priority than the work that is stupid.

EDIT (based on comments):

One other thing to consider this is:

5. Find a way to make the project succeed! Given the description of your superior, it's unlikely, but maybe there is a valid reason for his project hidden somewhere in the details. Or otherwise, maybe there's a way to otherwise make this project valuable. See if you can do this.

Answer 8

Been there, done that, many times. You should evaluate the cost benefit - on the one hand, if you do what you're told like that, you're probably not going to receive the professional recognition you deserve for your skills. You have to stand up and show your worth in this world to be taken seriously by people who are not able to do what you can (sadly, in my option, but that's just life). On the other hand, how much do you want to risk losing the job? In my last role, I walked out of the most money I've ever earned, directly because I got a new manager who didn't know what they were talking about, as you seem to be identifying here and i just could reason with them because they didn't know the first thing about coding.

Your opinion does matter, no matter how junior you consider your role. It's not an easy decision and there is no right answer, except what you can decide for yourself. I think fundamentally it comes down to whether you really need the money right now, or you have the fiscal ability to wait for the right job; if the latter I'd advise to quit, otherwise, stay and use them as they are using you to get some money; that then gives you an opportunity to relax and wait for the right role.

Forgive me for being cynical but take it from someone who's been around the block a few times and had just the same thoughts as you lately - everyone is fallible, even your managers. If you feel you can stand up to them and take your place in the company by doing so, then stick with it and show them who you are, otherwise just leave, it's not worth getting upset about.

Answer 9

Reading between the lines of your question, I want to suggest a slightly different perspective.

The lead data scientist's technical expertise wasn't checked during the interview (it turned out they didn't know how to use Linux, git, Python, never heard about concepts such as pull requests, never worked with a server before, etc.)

None of these are data science skills, they are more software engineering, development or DevOps skills. You mentioned in a comment that you don't consider yourself a developper but do you have a background in computer science? Or in statistics or another science? And what about the lead data scientist?

Most data scientists I know did pick up some of these skills along the way but it's entirely possible to be a data scientist without knowing much about Linux or git. I wouldn't say the same if you told us they don't know about linear regression…

[…] The lead data scientist decided to replicate my project, they made some changes, and they were successful in selling a fair amount of hot air to the senior managers about the need to improve and revamp my models.

You have given us zero reason to think that there isn't a need to improve and revamp your models. Worse, you talk only about it as code, focusing on the number of lines in functions, unit tests, etc. which suggests you do not know how to properly evaluate a model as such nor realize that data science isn't only about coding.

[…] In my view, it is not my duty as a junior coworker (who is at least one grade lower than the Lead data scientist) to review the code and modelling of the technical lead.

Is your company regularly conducting code reviews? Your question doesn't suggest it. Are you sure that's what you have been asked to do? If that's not the case, then all the advice about treating it as such, making a report about unit tests or code quality may be beside the point.

I feel annoyed about the existence of this twin project. Would I be right to complain about it, or is it normal in the industry to duplicate projects and step into other coworkers' shoes?

It's not unusual to try new approaches by building toy systems or demos outside of a production system. And in my experience code quality for these is rarely up to the standard expected for production code, especially when they are made by statisticians or data scientists, which isn't really the same job as that of a software developer or data engineer.

When did you learn about the project? How come you haven't discussed it with the lead data scientist earlier? Are both of you part of the same team or reporting into the same part of the organization? From your description, it sounds like a significant amount of work and something that took a bit of time to put together. Not discussing it sounds very odd, no matter the objectives.

If an experienced coworker was trying to improve on a system you have been working on, I would expect both of you to discuss subject matter or data quality insights, compare approaches, etc. without the need for you to decipher what they have done from their code. Even if they are more senior and not really interested in your perspective, I would at least expect them to share their main findings with you.

What's unusual is not the existence of this project but communication around it. It sounds like you have a very damaged relationship with a senior employee who is trusted by your management and that's an issue in itself. And instead of trying to understand their perspective or what may be a very complementary skillset you could learn from, you try to dismiss them entirely based on your perception of their skills and call their contribution “hot air”, which can only compound the problem.

Ultimately, the senior managers above the Lead are the ones who bought the Lead's hot air and authorized a cloned project (with or without being tricked into it, which is irrelevant), so they are responsible for the awkward situation, even more than the Lead.

Indeed, that project has probably been authorized or perhaps even requested by management. That may have been misguided but it does suggest that you may be fundamentally misreading the situation. Now, there is a lot we don't know and it's possible that there is nothing of value in the lead data scientist's contribution and that they really are incompetent. But it also seems possible that your frustration and resentment is blinding you to the reality of your situation.

Is management skeptical of the claims of the lead data scientist? You called it “hot air” twice but it doesn't sound like they see it that way. In other words, it seems possible that you have not really been asked to “review” their code to fix its style or check if there is anything of value. Instead, you may have been asked to learn from it to improve the performance of the system.

Why would management let the lead data scientist work on this, order you to review their code, or even take time to discuss any of this if there isn't some dissatisfaction with the existing system or some business benefit from the new approach? Unless “lead” is a fake vanity job title, they are presumably more expensive and busier than you are and there must be some reason they were assigned to work on this and not on anything else.

Conversely, why hasn't management asked the lead data scientist to guide you to implement their approach? Do they really expect you to challenge their work or simply to copy it? If they are in fact skeptical, are they trying to build a case against the lead data scientist through some sort of formal review?

Focusing only on technical excellence or best practices is a mistake I made as well when I was more junior but there are many other things that matter. Everything in your question suggests you haven't been kept in the loop of this project, are you sure you understand the background correctly?

Answer 10

If you're being asked to do a code review from a manager - particularly from Upper management above your regular manager - you absolutely should do it.

This is true whether the technical competence of your manager is far beyond your own, or at absolute zero. And is a normal part of approving/rejecting code changes.

If you feel that your manager has very little technical competence and that his code will likely need multiple changes at best, or at worst be entirely unusable, then be fair but wholly honest in reviewing his work.

---

More generally, in pretty much every area of business, we find that sometimes the person hired into a position is not as qualified as they made it seem during their interview and in their resume.

Despite this, and despite having to pick up the technical slack for your own supervisor, you still need to perform your job duties. If that means 'wasting time' doing code review for him, and you've gotten explicit orders to do so, then that is simply what you have to do.

Think of it not as a waste of your time though, but as an opportunity to show that you are a highly competent employee, and a valuable asset that the company cannot afford to lose - if you truly are the only competent coder in your team, and you can show that through a detailed technical review of your supervisor's work, then you have nothing to lose but quite a lot to gain by doing so.

Answer 11

I've been in your shoes and it's terrible, especially when the senior person struggles with git.

I have observed someone in a similar situation do a spectacular tear down of the code. He wrote a massive email, addressed to pretty much everyone at the department, and described every piece of bad code, calling it a 'bug' (he was fighting hot air with hot air.) Granted, he was a senior and the target was a lead. The target stayed on until his product launched and melted.

But whatever you decide, I think it may be time to start job searching - your management sounds uninformed about modern coding practices, and you've got yourself into a situation where you're taking too much ownership of a project, and people who should have their own projects (like learning git!) are coming for yours. This stinks of people fighting for scraps, and if you're at a company that only has scraps of projects, the company is struggling.

What I tell people in Quality Control is that if you find yourself seriously questioning the decisions of the product team and the quality of the products and business model, do not write up bugs to that effect. You've lost faith in the company, and it's time to move on.