24

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.
2
  • 1
    Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – Kilisi
    Feb 9 at 3:19
  • 2
    Re the edit; I assume any review will be very, very critical of the code and practices. Given that "According to the senior managers bad code is fine as long as it works", how do you expect your review to be received? Feb 9 at 11:04

11 Answers 11

41

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.

3
  • 4
    "that's a valid concern, especially if "According to the senior managers bad code is fine as long as it works)."" - Well we can learn from it to not trust senior management with code. I can see them fume and cry and fingerpoint as soon as "it no longer works" ...
    – Fildor
    Feb 8 at 15:50
  • 2
    Yes, just bear in mind that a career journey is not like Google Maps: you will probably end up somewhere different than you started out for, with a lot of interesting twists and turns along the way. Every job change I have made came about unexpectedly and led somewhere I couldn't have anticipated. Maybe I'm the model for "The Fool" Tarot card, or maybe not. The word career originally meant, "to plunge headlong." Just be sure the vines are tied securely to your ankles :-) Feb 9 at 13:00
  • You can always ask why review something that's working if they're fine with it? What are the objectives?
    – Nelson
    Feb 15 at 2:55
66

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.

6
  • 3
    "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." -- this depends on the culture and location of your company -- as well as your company itself. Some cultures are very hierarchical, other cultures promote independent thinking from all members of the team.
    – Marco
    Feb 8 at 12:43
  • 20
    @Marco I don't think the implication is that you must do only what you are told to do. But reviewing other people's code, even code from people who are theoretically senior, even if you don't respect them, ought to be part of a developer's job. Otherwise, when you find yourself in a job where you're the most senior developer, who will review what you write? Looking for another job is also a valid option, of course.
    – David K
    Feb 8 at 18:35
  • 4
    I'd review the code, but I would also be very critical. Nobody should be recreating existing projects without some clear goal in mind. Improve how X works, make it possible for Y to be done. And then the recreation would be with the goal of improving on what was already there. Doesn't sound like he had any of this permission or foresight or even looked at the previous code. There could be plenty of bugs and problems hidden in those long methods, so highlighting that in the review is paramount. bad code hides problems that will bite them in the ass later. Feb 9 at 6:19
  • 1
    @TheEvilMetal strangely, people sometimes get to a good result in a bass-ackwards way or entirely by accident. One may assess how long they will accompany them on that, or wait and see what happens. It isn't always obvious in advance. "That's what makes a horserace." Or, a horse race. Or something... Feb 9 at 13:07
  • 1
    @HappyIdiot Doesn't change the fact that this work seems to have been done without approval. If the higher ups had known how much of that employees time plus the OPs time it would take perhaps they would've decided to divert that time and effort to something else. Just because there might be an improvement by happenstance doesn't mean that anything and everything in a project can just be rewritten on a whim. Time is money and this sounds like a lot of wasted time. Feb 13 at 6:11
51

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.

1
  • "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" - that's kind of what I read in the question. The annoyance seems to be rooted in the data analyst's skill issue when it comes to development tools. So, maybe it's a good idea to approach this a little more constructively. For example by suggesting to do the next "optimization" in pair programming style, so no time is wasted because proper tooling was not utilized?
    – Fildor
    Feb 8 at 16:02
46

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.

16

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
1
  • "Bridge out. Could not proceed to objective. Stop" Feb 9 at 12:38
14

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.

2
  • 7
    I agree. I think one of the biggest things the senior can get out of having their code reviewed by a junior dev is clarity. If code is written or rewritten so that the juniors can understand the what and why without further discussion, then the code will be easier to maintain for everyone. At least, in the general case. This specific OP has other problems too. Feb 8 at 18:59
  • 1
    A review of reviews seems to be in order. Along with other practices in the company. "We had to destroy the ship in order to save it." Feb 9 at 12:51
4

You are missing a couple of options:

  1. 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:

  1. 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.
5
  • If you're over 35 or otherwise don't fit the above critieria, the equation gets more complicated, is still roughly true: time wasted == less salary later && less opportunities later
    – Marco
    Feb 8 at 12:55
  • 1
    I agree with this answer.As it highlights the true problem, you don’t seem to think, your contributions are seen as being highly valued by the company.Which in the reason, reviewing code from your superior, sort of irritates you. So I agree start looking for a better job.If you are as skilled as you say you are that shouldn’t be difficult. However, in the mean time, do the work that’s been assigned to the best of your abilities.As not doing the job, will give them a reason, to get rid of you potentially. Then you’ll be someone that’s been fired for not doing the job. The details won’t matter.
    – Donald
    Feb 8 at 13:33
  • 3
    Disagree. Intentionally sitting on your hands hoping others fail is the exact opposite of what a professional should be doing. Absolute worst-case, you should be finding a way to get your concerns documented and on the record. Better would be to do what you can to make it succeed. That's a far more valuable and sought-after skill, than someone whose default position is to say "I knew it wouldn't work" or "I told you so" after the fact.
    – Basic
    Feb 8 at 14:46
  • 2
    @Basic: in an ideal world, you are absolutely right. To be clear, I'm defining "ideal" in which people rationally consider opinions and do what's best for the company, instead of being purely poltically motivated, or even just personally motivated ("I don't like person X, so I'm going to block his project"). I do agree with your point that making projects succeed is potentially the most valuable "skill" you can have. So if the OP can find a way to make this project a success, that's very helpful.
    – Marco
    Feb 8 at 15:10
  • 3
    I agree with #5. And, if you don't have any "significant financial responsibilities", maybe you are working too hard? Your job can't love you back, I was told once... Feb 9 at 12:48
4

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.

3
  • 1
    Fantastic answer. +1
    – Marco
    Feb 12 at 9:30
  • Perhaps: "i just could reason with them" -> "i just couldn't reason with them" Feb 21 at 2:25
  • @DanielRCollins Explain please?
    – Absinthe
    Feb 21 at 3:00
4

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?

1
  • 3
    This is an excellent insight. Data science is new. Integration of the strong statistical and modelling skills of data science and the the software engineering standards of good running production code is a recurring challenge in this new space. This also means switching to a new job could easily land you in the same situation of an org that hasn't learnt how to manage it yet. Lots of data scientists code like they were raised by wolves. The OP should take a step back, work out the strengths and weaknesses of the new DS, and layout the business impact of poor engineering.
    – Adam Burke
    Feb 12 at 2:01
3

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.

1
  • I agree, but if they find out that they can't afford to lose you because you are so necessary, maybe it is time to leave? My first boss said, "No one is indispensable." Or, that should be the case in a properly run company. Actually I had unique knowledge in that company, and when it was bought, the new company simply let everyone go. They didn't need the people or their knowledge, apparently. Feb 9 at 12:33
2

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.

1
  • 1
    The 'dogfight' between seniors would have been interesting to watch. Still, maybe that workplace is a little too exciting. Feb 9 at 12:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .