Iyfjky

Question

I hold a PhD in mechanical engineering with a 7 year background in self-guided, self-paced research including 2 years as a graduate level course instructor and a subject matter expert for various engineering projects in a university setting in the United States.

For the last 10-11 months, I am working in a research industry in France where my task is to debug C++ spaghetti code written over a period of several years by my current supervisor. It is a team of 2: just I and my supervisor.

Diurnally, I am posed with a "bug of the day" to get out of this C++ code. My supervisor generally gives me about 15-30 minutes to solve it and then accosts me about whether or not the task is completed and then rinses and repeats this until the end of the day.

Off-late, my supervisor has been holding 6-7 hour long "meetings" where instead of giving me the usual 15-30 minutes on my own, we both face a computer screen and he furiously debugs code while I sit besides him and look on. During this time, he quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself and am not given time to get familiar with it. I make this clear to him but is met with exasperation on his part and his pointing out that my programming skills are lacking. The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time.

There are no deadlines on paper, except that my supervisor tells me that "it is urgent". I have approached this subject of "urgency" with him and he has usually given me deadline dates that he seems to pull out of the air (I have missed several dates and have been met with no consequence).

In fact, I was hired for a certain job description which I am not doing at all (I was hired for non-programming equation development and have been thrust into programming). This I have approached him about too and was met with a brusque "change in plans" reply. I have also noticed that there is significant scope creep in this programming project. As having had that on a regular basis during my PhD (scope expands when you don't know what you are solving, such is the nature of some types of fundamental research), I suppose that is OK in industry setting for research.

HR has been lukewarm in their response to this issue of non-conformation to job description and lack of milestones. They say they understand the problem but they haven't done too much to enforce a better professional attitude on his part. He is a "permanent" employee whilst I am "temporary" (on-contract) and as I understand, "permanent" employees in France get a significant leeway in their approach to work and in turn their employees.

I understand that sometimes one is faced with difficult positions such as this and I would like to make the best of it for my own personal and professional development. How do I tell him in tactful fashion that being babysat for 6-7 hours a day is not really a good use of anyone's time and that just letting me do the job during that period of time may be a better solution? Is this something I should have just expected in industry settings since this is my first sojourn into industry?

I voted to reopen this. No idea why it is closed or why this couldn't have acceptable answers. — Mar 2 '16 at 21:48

score 38 · Answer 1 · 2015-03-23 22:50:26Z

The supervisor's attitude seems pretty bad, but as a manager the following points stood out to me:

For the last 10-11 months, I am working in a research industry in France

We both face a computer screen and he furiously debugs code while I sit besides him and look on

He quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself

The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time.

I have missed several dates and have been met with no consequence

It looks to me that you haven't picked up the work and are still struggling. My worry would be that even though you are getting knowledge transfer (even far from ideal kt), you are still not getting to grips. The progression of your supervisor from dealing tasks to pair working indicates his concern. I would want to ask you some questions:

Are YOU asking questions during the sessions to help you understand?

What do you think is an acceptable time to diagnose a bug, how different is that to your supervisor's? Do you suggest a better timebox for your bug investigations if 30 minutes isn't getting anywhere ("I'll spend an hour/2 hours/half day looking at this and get back to you")

Do you ask for timescales (ideally in writing if there are issues with missing them), do you feedback to the supervisor when they are being set to something you can't deliver, or do you wait until they are about to hit?

As bad as the way your supervisor is managing you, you sound as if you're happy to just sit back and complain. People who get on aren't managed, they manage upwards.

Having worked with PhDs before I've seen similar issues, usually due to the person being used to taking "as long as it needs" to complete a task. Given the nature of a PhD this is normal, but in business (even research) there can be more of an urgency to get things done. The deadlines may sound arbitrary to you, but you might not know the full story (or it may be based on what the supervisor is telling his boss).

As regards asking your supervisor not to babysit you, I don't think you can. It sounds like you aren't in any position of trust. You need to work on this and on getting to a decent level with the C++ code, things should then get easier, but make sure you are driving the timescales AND make sure YOU deliver.

Work is about managing expectations, either what you will deliver or when you will deliver. It sounds like you aren't doing either.

Excellent response; I especially like that you picked up on the OP's passive nature during the pair programming (I was going to concentrate on this in my response) and your conclusions. — Mar 25 '15 at 6:22
Sometimes if you give an employee the proper spanking they don't need to be babysat, but answer is pretty dead on. — Mar 3 '16 at 15:51

Kate Gregory 105k40230332 · Answer 2 · 2015-03-23 17:37:57Z

It seems quite likely to me that these are not meetings, but pairing. He is trying to teach you some of what he knows. You were presumably hired for a reason, perhaps to reduce his workload, perhaps to improve the software beyond its current level. I suspect he believes that if he continues to "show" you how to do it, and to "pair" with you, that you will magically be able to take over soon.

I am not sure this is salvageable, but assume you want to try, I would suggest attempting to achieve the following:

a list of bugs, enhancements, and stuff that was left for later. Not to be handed them one at a time, but to work together to create this list. Keep it in a work tracking system, or a spreadsheet, or on a piece of paper, but have a list

an agreement that you will spend so many hours a day trying certain ones yourself (that you choose) and so many hours a day pairing on the ones where you think you need his help

an agreement that you will type during pairing. He can read and think and remember and such, but you will type. When you wonder "where is that defined?" you will have to ask him out loud and he will have to answer you out loud. This will be slower at getting the bugs fixed than him typing, but faster at getting your knowledge of the code base up

I also recommended you purge your vocabulary of words like "baby sitting". If you think you're being treated like someone more junior, you need to start producing like someone senior. That's the big benefit of the list - it lets you pick off a few things you can actually take care of yourself. The more you do alone the less he will subject you to what I am quite sure is an improvement program.

+1 for pointing out that this is probably the manager's attempt at pairing, which is a valid and valuable knowledge transfer method. — Mar 23 '15 at 18:00
@DaveJohnson I did the same thing when lecturing to students:"Think, pair, share". However, the "think" (individually) portion is largely omitted by my supervisor. So we just "pair" and he "shares" his thoughts. I don't have any thoughts or very few thoughts since I was not allowed to "think". — Mar 24 '15 at 9:04
@KateGregory Interesting point about baby-sitting. I have only now realized, post your comments, that all junior level PhDs are being "babysat" by their supervisors at my work place. Perhaps its a work culture issue too? — Mar 24 '15 at 11:02
@drN oh definitely, there's no doubt in my mind that what your supervisor thinks a supervisor should do seems to be a long way from what everyone else does. But the thing is, especially in a research lab, you're not going to change that. So you need to stand up tall and improve things for yourself as much as you can. Start getting things done (even tiny things) to show him you can. If you're not learning from the way he's teaching, do something about it. Start steering. The same skills we used to finish our doctorates. — Mar 24 '15 at 11:14
The third bullet is very, very important. If part of the objective of a joint session at a computer is knowledge transfer the person with the knowledge needs to keep their fingers off the keyboard. All typing should be done by the knowledge recipient, after understanding the next step. — Mar 2 '16 at 22:36

score 19 · Answer 3 · 2016-03-02 19:57:40Z

sleske's answer touches this a bit, but I just wanted to address this question:

Is this something I should have just expected in industry settings since this is my first sojourn into industry?

How your supervisor is handling it isn't normal, but others have covered that so I won't go there.

As far as work in the industry goes, this is definitely not normal. When you sign up for a certain job description, you're perfectly reasonable for expecting to work on the kinds of tasks outlined inside it.

Your post doesn't scream enthusiasm for software development, and you even state that the job description was non-programming. And given that you still feel out-of-the-loop on the software after almost a year, software doesn't seem to be your calling(or this employer is absolutely horrendous - could be both). I'm sure you're well aware that you're not a software developer at heart.

I think you need to fight for your original job description and tasks related to it, or find another job. Just because C++ doesn't look like alien scripture doesn't mean you're qualified for the tasks you're being given.

More importantly, if you want a career related to mechanical engineering, you're actually hurting yourself by not doing tasks related to it. You're missing out on learning the tools of the trade, and by the time you reach the "5 years of experience" mark, you won't have 5 years of experience with your tools...at best you'll have 4 if you change things up right now.

Although a doctorate mitigates the "5 years experience" hurdle - usually 5 years exp is the equivalent of a master's degree. I strongly second the notion of "get a different job". — Mar 23 '15 at 16:34
More importantly, if you want a career related to mechanical engineering, you're actually hurting yourself by not doing tasks related to it. This. If you want to be a programmer and work at a help desk... you aren't learning to be a programmer. Why would this experience count towards anything? (although you can spin things in a resume done right) — Mar 23 '15 at 23:49
This was supposed to be a mechanical engineering research job (per job desc.) with me hired to develop equations for new mech. cooling technology. The code was something that would also be developed in tandem as a numerical design tool. However I have found myself in the coding portion of this project. — Mar 24 '15 at 9:02
This, very much. You've spent a long time becoming an expert in a certain field and are now subject to an absurd training regime from a very bad teacher. Ask yourself if you enjoy your work there, if you gain any skills valuable for the job you'd like to do, and if you would like to continue like this. If they haven't assigned you to work in your original field for a year now (!), is there any evidence they will actually do it in the future? Seriously ask yourself if you wouldn't be happier elsewhere, where your hard-earned skills are actually in demand. — Dec 9 '16 at 11:28

gnasher729 71k31131222 · Answer 4 · 2015-03-23 18:18:10Z

The supervisor has written the code over the last six or seven years. It is obvious that he has a lot of affection for it and doesn't want you to touch it.

I can actually not imagine anything more useless to learn about this codebase than sitting besides someone who is happily typing away on the keyboard. Even at the level where your eyes try to identify things on a screen, having someone else controlling scrolling, paging up and down, makes it impossible to follow anything.

In that kind of environment, you are just wasting your life. From the company's point of view, you are also wasting their money. From the supervisor's point of view, you are wasting his time as well (however, he is the only one to blame for this situation, so he's the only one that I don't feel sorry for). I'd recommend searching for another job while you still have your sanity, and then quitting when you found something new. You might check with HR if there are any other positions at the company, but I would probably prefer to start somewhere fresh.

We can all speculate about the exact motivations of your supervisor (and there have been several reasonable speculations), but I'd say that this job is a dead end for you.

Thank you for your honest answer. Yes, I am under the impression that besides learning "how not to treat your employees", this job will impart few technical skills to me. — Mar 24 '15 at 9:01

sleske 9,79633655 · Answer 5 · 2015-03-23 10:29:04Z

To answer the last part of your question first:

This is a horrible way of working, and is not something to be expected in a (healthy) company - even though it is not as uncommon as one might wish.

As to how to cope:

This is difficult. It seems that your boss' management style has multiple issues (most importantly, lack of planning and micromanagement). One way to tackle this might be to point out more or less what you have described in your post.
As usual, do not accuse him (or any one else). Just explain how you would like to work, and why you feel you'd be more productive that way.

This may help to allow you to work in a way that makes you more productive (and hopefully happier).

However, seeing the multiple problems you describe, personally I'm doubtful whether you'll be able to change your situation significantly - changing people's work habits is hard. In that case, you'll probably have to change boss, which might mean changing your job. But that's a decision only you can make.

"even though it is not as uncommon as you wish". Are there any anecdotal case studies that describe such a non-conducive work environment? Thank you for your answer. — Mar 23 '15 at 10:37
@drN: I'm not aware of any published studies, but I've heard of and experienced situations that bore similarities to yours. A formal study would certainly be interesting. — Mar 23 '15 at 10:40

Peter Mortensen 45547 · Answer 6 · 2015-03-23 19:58:30Z

Your supervisor is hiding a few things from you and is deliberately keeping you in the dark. It should be obvious to you, if you re-read your own post, that he has embarked on a major humanitarian project, that is, keeping his butt out of the fire.

I see you're being compelled to sit with him as some kind of parody of pair programming, because you are doing zero coding - you should be doing 50% of the coding. In pair programming, both halves of the pair know exactly what they want the code to do. In your case, you are at least 80% in the dark, and I am not sure that your supervisor is in full control of his own code, given that he seems locked in some kind of life-and-death struggle with it.

You need to take a much more active part on the coding process. It doesn't look like you will fully understand what's going on when your supervisor finishes fixing his own code, but you should at least aim to achieve a much higher level of understanding of what he is doing, what he is doing and how he is doing than what you have right now.

If you say to him that you understand what he is doing and you actually don't, that little white lie will blow up in your face if you are ever tasked to do anything with his code on your own at some point in the future. Ask him questions, try to get at least a general picture of what he is trying to do, because if you have to meet deadlines and milestones with the understanding of his code that you have know, working on his code could well be a Resume Generating Event (RGE) for you.

Hello Viethni, would you mind re-reading my question? No where in the question do I say that I tell him white lies or that I don't make an effort to understand what is going on. If that is implied, it might have slipped me completely while writing the question! How does one exactly take active part in a project when my supervisor doesn't allow me enough breathing space to take an active interest and participate? Also I am not embarking on an RGE (as you put it). Forgive me but I have been trained in academia to not do work "to generate resume bullet points". That might be wrong, but so be it. — Mar 23 '15 at 12:37
Here it is, in your own words: " During this time, he quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself and am not given time to get familiar with it. The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time." What do you tell him when he asks you whether you understand what he is doing? — Mar 23 '15 at 13:03
Ah! Very good point you make. I'll make the corresponding edit. However, it can only be implied on what I say at this stage to my supervisor. — Mar 23 '15 at 13:09

Forrest Christian 512 · Answer 7 · 2015-03-24 19:51:20Z

Almost all these answers provide you with solid advice that you should listen to as you come out of academia and into industry. @TheWanderingDevManager provides especially clear advice for software.

Yet I think they muddy the issue a bit for you because they miss two important points:

(1) Your "supervisor" is not a supervisor but in a highly skilled Direct Output (DO) role. He is not a manager; he is a DO, so he is not managing you in any way. Comments that imply that he is will not be useful in this situation.

(2) You are a contractor. To employees, you are simply a service person who should do whatever he is told. This is why HR will not do anything. You are not an employee and therefore have no employee rights.

These mean that you are not his employee and he is not your "supervisor". What you are doing is called an "Assisted Direct Output" (ADO) role. Your job is to help him achieve his outputs (getting this software working). This makes you his Assistant, not subordinate.

He sounds like he has an advanced degree but is not considered good enough at the field to do the work, so he's stuck writing programs to support those doing the work.

This does not make him evil. He thinks that you should be working at a higher output, as has been said. He is "pair programming" with you because he is trying to get you to work out. You are resisting this mostly because this work does not stretch you in any way. You are both bored and overwhelmed.

This is not going to get any better for you because in the end you don't want to do this type of work, even if the DO suddenly became different. Follow everyone's advice and get a job in your field, then do what @TheWanderingDevManager says because he's right. And leave on the best terms possible with the DO and his managers: really work at this.

(I say this as someone who has hired and managed PhDs and ABDs, worked as an ADO to PhDs both as employee and contractor, led dev teams, managed DOs and managed managers of software developers.)

score 38 · Answer 8 · 2015-03-23 22:50:26Z

The supervisor's attitude seems pretty bad, but as a manager the following points stood out to me:

For the last 10-11 months, I am working in a research industry in France

We both face a computer screen and he furiously debugs code while I sit besides him and look on

He quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself

The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time.

I have missed several dates and have been met with no consequence

It looks to me that you haven't picked up the work and are still struggling. My worry would be that even though you are getting knowledge transfer (even far from ideal kt), you are still not getting to grips. The progression of your supervisor from dealing tasks to pair working indicates his concern. I would want to ask you some questions:

Are YOU asking questions during the sessions to help you understand?

What do you think is an acceptable time to diagnose a bug, how different is that to your supervisor's? Do you suggest a better timebox for your bug investigations if 30 minutes isn't getting anywhere ("I'll spend an hour/2 hours/half day looking at this and get back to you")

Do you ask for timescales (ideally in writing if there are issues with missing them), do you feedback to the supervisor when they are being set to something you can't deliver, or do you wait until they are about to hit?

As bad as the way your supervisor is managing you, you sound as if you're happy to just sit back and complain. People who get on aren't managed, they manage upwards.

Having worked with PhDs before I've seen similar issues, usually due to the person being used to taking "as long as it needs" to complete a task. Given the nature of a PhD this is normal, but in business (even research) there can be more of an urgency to get things done. The deadlines may sound arbitrary to you, but you might not know the full story (or it may be based on what the supervisor is telling his boss).

As regards asking your supervisor not to babysit you, I don't think you can. It sounds like you aren't in any position of trust. You need to work on this and on getting to a decent level with the C++ code, things should then get easier, but make sure you are driving the timescales AND make sure YOU deliver.

Work is about managing expectations, either what you will deliver or when you will deliver. It sounds like you aren't doing either.

Excellent response; I especially like that you picked up on the OP's passive nature during the pair programming (I was going to concentrate on this in my response) and your conclusions. — Mar 25 '15 at 6:22
Sometimes if you give an employee the proper spanking they don't need to be babysat, but answer is pretty dead on. — Mar 3 '16 at 15:51

Kate Gregory 105k40230332 · Answer 9 · 2015-03-23 17:37:57Z

It seems quite likely to me that these are not meetings, but pairing. He is trying to teach you some of what he knows. You were presumably hired for a reason, perhaps to reduce his workload, perhaps to improve the software beyond its current level. I suspect he believes that if he continues to "show" you how to do it, and to "pair" with you, that you will magically be able to take over soon.

I am not sure this is salvageable, but assume you want to try, I would suggest attempting to achieve the following:

a list of bugs, enhancements, and stuff that was left for later. Not to be handed them one at a time, but to work together to create this list. Keep it in a work tracking system, or a spreadsheet, or on a piece of paper, but have a list

an agreement that you will spend so many hours a day trying certain ones yourself (that you choose) and so many hours a day pairing on the ones where you think you need his help

an agreement that you will type during pairing. He can read and think and remember and such, but you will type. When you wonder "where is that defined?" you will have to ask him out loud and he will have to answer you out loud. This will be slower at getting the bugs fixed than him typing, but faster at getting your knowledge of the code base up

I also recommended you purge your vocabulary of words like "baby sitting". If you think you're being treated like someone more junior, you need to start producing like someone senior. That's the big benefit of the list - it lets you pick off a few things you can actually take care of yourself. The more you do alone the less he will subject you to what I am quite sure is an improvement program.

+1 for pointing out that this is probably the manager's attempt at pairing, which is a valid and valuable knowledge transfer method. — Mar 23 '15 at 18:00
@DaveJohnson I did the same thing when lecturing to students:"Think, pair, share". However, the "think" (individually) portion is largely omitted by my supervisor. So we just "pair" and he "shares" his thoughts. I don't have any thoughts or very few thoughts since I was not allowed to "think". — Mar 24 '15 at 9:04
@KateGregory Interesting point about baby-sitting. I have only now realized, post your comments, that all junior level PhDs are being "babysat" by their supervisors at my work place. Perhaps its a work culture issue too? — Mar 24 '15 at 11:02
@drN oh definitely, there's no doubt in my mind that what your supervisor thinks a supervisor should do seems to be a long way from what everyone else does. But the thing is, especially in a research lab, you're not going to change that. So you need to stand up tall and improve things for yourself as much as you can. Start getting things done (even tiny things) to show him you can. If you're not learning from the way he's teaching, do something about it. Start steering. The same skills we used to finish our doctorates. — Mar 24 '15 at 11:14
The third bullet is very, very important. If part of the objective of a joint session at a computer is knowledge transfer the person with the knowledge needs to keep their fingers off the keyboard. All typing should be done by the knowledge recipient, after understanding the next step. — Mar 2 '16 at 22:36

score 19 · Answer 10 · 2016-03-02 19:57:40Z

sleske's answer touches this a bit, but I just wanted to address this question:

Is this something I should have just expected in industry settings since this is my first sojourn into industry?

How your supervisor is handling it isn't normal, but others have covered that so I won't go there.

As far as work in the industry goes, this is definitely not normal. When you sign up for a certain job description, you're perfectly reasonable for expecting to work on the kinds of tasks outlined inside it.

Your post doesn't scream enthusiasm for software development, and you even state that the job description was non-programming. And given that you still feel out-of-the-loop on the software after almost a year, software doesn't seem to be your calling(or this employer is absolutely horrendous - could be both). I'm sure you're well aware that you're not a software developer at heart.

I think you need to fight for your original job description and tasks related to it, or find another job. Just because C++ doesn't look like alien scripture doesn't mean you're qualified for the tasks you're being given.

More importantly, if you want a career related to mechanical engineering, you're actually hurting yourself by not doing tasks related to it. You're missing out on learning the tools of the trade, and by the time you reach the "5 years of experience" mark, you won't have 5 years of experience with your tools...at best you'll have 4 if you change things up right now.

Although a doctorate mitigates the "5 years experience" hurdle - usually 5 years exp is the equivalent of a master's degree. I strongly second the notion of "get a different job". — Mar 23 '15 at 16:34
More importantly, if you want a career related to mechanical engineering, you're actually hurting yourself by not doing tasks related to it. This. If you want to be a programmer and work at a help desk... you aren't learning to be a programmer. Why would this experience count towards anything? (although you can spin things in a resume done right) — Mar 23 '15 at 23:49
This was supposed to be a mechanical engineering research job (per job desc.) with me hired to develop equations for new mech. cooling technology. The code was something that would also be developed in tandem as a numerical design tool. However I have found myself in the coding portion of this project. — Mar 24 '15 at 9:02
This, very much. You've spent a long time becoming an expert in a certain field and are now subject to an absurd training regime from a very bad teacher. Ask yourself if you enjoy your work there, if you gain any skills valuable for the job you'd like to do, and if you would like to continue like this. If they haven't assigned you to work in your original field for a year now (!), is there any evidence they will actually do it in the future? Seriously ask yourself if you wouldn't be happier elsewhere, where your hard-earned skills are actually in demand. — Dec 9 '16 at 11:28

gnasher729 71k31131222 · Answer 11 · 2015-03-23 18:18:10Z

The supervisor has written the code over the last six or seven years. It is obvious that he has a lot of affection for it and doesn't want you to touch it.

I can actually not imagine anything more useless to learn about this codebase than sitting besides someone who is happily typing away on the keyboard. Even at the level where your eyes try to identify things on a screen, having someone else controlling scrolling, paging up and down, makes it impossible to follow anything.

In that kind of environment, you are just wasting your life. From the company's point of view, you are also wasting their money. From the supervisor's point of view, you are wasting his time as well (however, he is the only one to blame for this situation, so he's the only one that I don't feel sorry for). I'd recommend searching for another job while you still have your sanity, and then quitting when you found something new. You might check with HR if there are any other positions at the company, but I would probably prefer to start somewhere fresh.

We can all speculate about the exact motivations of your supervisor (and there have been several reasonable speculations), but I'd say that this job is a dead end for you.

Thank you for your honest answer. Yes, I am under the impression that besides learning "how not to treat your employees", this job will impart few technical skills to me. — Mar 24 '15 at 9:01

sleske 9,79633655 · Answer 12 · 2015-03-23 10:29:04Z

To answer the last part of your question first:

This is a horrible way of working, and is not something to be expected in a (healthy) company - even though it is not as uncommon as one might wish.

As to how to cope:

This is difficult. It seems that your boss' management style has multiple issues (most importantly, lack of planning and micromanagement). One way to tackle this might be to point out more or less what you have described in your post.
As usual, do not accuse him (or any one else). Just explain how you would like to work, and why you feel you'd be more productive that way.

This may help to allow you to work in a way that makes you more productive (and hopefully happier).

However, seeing the multiple problems you describe, personally I'm doubtful whether you'll be able to change your situation significantly - changing people's work habits is hard. In that case, you'll probably have to change boss, which might mean changing your job. But that's a decision only you can make.

"even though it is not as uncommon as you wish". Are there any anecdotal case studies that describe such a non-conducive work environment? Thank you for your answer. — Mar 23 '15 at 10:37
@drN: I'm not aware of any published studies, but I've heard of and experienced situations that bore similarities to yours. A formal study would certainly be interesting. — Mar 23 '15 at 10:40

Peter Mortensen 45547 · Answer 13 · 2015-03-23 19:58:30Z

Your supervisor is hiding a few things from you and is deliberately keeping you in the dark. It should be obvious to you, if you re-read your own post, that he has embarked on a major humanitarian project, that is, keeping his butt out of the fire.

I see you're being compelled to sit with him as some kind of parody of pair programming, because you are doing zero coding - you should be doing 50% of the coding. In pair programming, both halves of the pair know exactly what they want the code to do. In your case, you are at least 80% in the dark, and I am not sure that your supervisor is in full control of his own code, given that he seems locked in some kind of life-and-death struggle with it.

You need to take a much more active part on the coding process. It doesn't look like you will fully understand what's going on when your supervisor finishes fixing his own code, but you should at least aim to achieve a much higher level of understanding of what he is doing, what he is doing and how he is doing than what you have right now.

If you say to him that you understand what he is doing and you actually don't, that little white lie will blow up in your face if you are ever tasked to do anything with his code on your own at some point in the future. Ask him questions, try to get at least a general picture of what he is trying to do, because if you have to meet deadlines and milestones with the understanding of his code that you have know, working on his code could well be a Resume Generating Event (RGE) for you.

Hello Viethni, would you mind re-reading my question? No where in the question do I say that I tell him white lies or that I don't make an effort to understand what is going on. If that is implied, it might have slipped me completely while writing the question! How does one exactly take active part in a project when my supervisor doesn't allow me enough breathing space to take an active interest and participate? Also I am not embarking on an RGE (as you put it). Forgive me but I have been trained in academia to not do work "to generate resume bullet points". That might be wrong, but so be it. — Mar 23 '15 at 12:37
Here it is, in your own words: " During this time, he quizzes me now-and-again on whether or not I understand what he is doing. To be completely honest, I understand what is going on only about 20-25% of the time since I haven't written the code myself and am not given time to get familiar with it. The other 70-75% of times, I know that if I spend enough time with the "bug", I'd be able to figure it out. Alas, I am not granted such time." What do you tell him when he asks you whether you understand what he is doing? — Mar 23 '15 at 13:03
Ah! Very good point you make. I'll make the corresponding edit. However, it can only be implied on what I say at this stage to my supervisor. — Mar 23 '15 at 13:09

Forrest Christian 512 · Answer 14 · 2015-03-24 19:51:20Z