0

I started a postdoc recently. My advisor has unrealistic expectations of progress. I was hired to implement feature X in their software (among other tasks; this is just the first). I have implemented X in a software written in language A, but have no prior experience with language B that their software is written in or framework C that their software uses. I did not know that they wanted someone to program in language B until the interview, and I explicitly stated that they should look elsewhere if knowing language B is critical as I don't know it. Language B is not known to be an easy language to pick up, though learning it has been on my to-do list for a while.

In multiple meetings recently my advisor has been pushing me to start implementing feature X now as if I've forgotten that's first goal. I know that is the first goal, which I politely stated multiple times, but I've emphasized that I need more time to get familiar with their software, the programming language, and the framework. I don't see myself making the changes I outlined for at least a month, probably longer. And I think my advisor would get angry if I took that long and might even fire me at the end of the probationary period (which is in about a month).

What should I do in this situation? I've tried to emphasize that it will take time for me to get up to speed and this is not avoidable, but this doesn't seem to satisfy my advisor.

Improve this question
3
  • 2
    Why does your question read like you are a software engineer in an industry setting? How is this all related to your research?
    – user9482
    Commented Feb 2, 2022 at 10:05
  • @Roland This is a computational science question. The first step is to implement some software, the next steps are using the software to answer some scientific question and improving the software over the state-of-the-art. I am looking for answers in an academic context. That might be different from a normal software engineering context.
    – AtomicAcorn
    Commented Feb 2, 2022 at 16:51
  • 1
    @Roland because that's how some STEM labs roll these days. The lab head would need code monkeys to work on otherwise something very niche (research), are senior enough to not have a need to learn these instruments and given the code quality of an average student/researcher, tech debt keeps piling up which is later solved by hiring even more students solely to maintain this overgrown in-house project the lab was doing for the past 5-10 years. Not that much different from a poorly run software company, really - no wonder people quit to industry in droves.
    – Lodinn
    Commented Feb 3, 2022 at 10:01

1 Answer 1

Reset to default
7

Your hurdles could be summed up in two points:

  1. Proving that you are capable
  2. Proving that a capable person would still take at least a month being posed a problem you are facing.

Note that in order for the advisor to adjust their expectations, the second one would be enough. To that end, an independent evaluation would be helpful... But do not expect it would go exactly as you think it would go.

I have seen this interaction play out time and time again: a good programmer would often quote a longer time to implement some feature than a bad one, but the success comes to the business-aligned one. With the advisor acting as your employer, you have to understand that having no feedback whatsoever for a month from a new hire is a little too much risk. Oh, and writing perfect code is not allowed: the typical employer would sooner accept a huge tech debt than a big delay in shipping features, especially at the early stages. It does get complicated with legacy projects.

That makes finding some way to show your work the best option you have.

Given the system is most likely hard to navigate - mock up everything, implement the feature with hardcoded values instead of fetching real data from other parts of the system, show it. Break down that month you have quoted into something more digestible and explain in layman's terms what are the issues you are dealing with. Reading a book on the language and studying the codebase for that long is not going to cut it, sorry - on this job or, indeed, most programming-heavy jobs out there.

Improve this answer

You must log in to answer this question.

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