My manager does not have computational skills but he wants access to my code: should I allow this? [closed]

Question

My line manager does not have any computational skills: no advanced data analysis, no scripting, no programming. Recently he switched the frequency of our meetings to weekly (from one every 2 weeks) and he wants to check my code week after week.

Background: he's not technical and he's mainly trying to monopolise access to my technical expertise, e.g. if you want to use technology X you must go through me. But other people have been very happy about my work and nobody else ever complained.

He doesn't really know anything about software development. I think that he wants to control my code by either counting the lines or giving it to some friend of his who will tell him "this sucks, pay me and I will do it for less". I think that giving him access to my code will only slow me down. Should I allow my manager to do this?

Answer 1

Should I allow my manager to do this?

Yes, almost certainly. If you are in a normal employment relationship, the code you write belongs to your company and you have no right to refuse that your manager sees your code. Refusing would almost certainly be seen as unreasonable or suspicious and could trigger disciplinary action.

he wants to check my code week after week

If this bothers you, find out what he actually needs. When this next comes up, talk to him about this. If it's mutually acknowledged that he doesn't program, ask what he'd like to do with it and how you can help him achieve that. If what he wants is numbers, and you don't want to be judged by lines, find alternative metrics that you feel better reflect the work you do, e.g. test coverage.

Don't be defensive, be proud of your code.

(Unless it's really bad code, in which case, stop writing bad code!)

Answer 2

I think that he wants to control my code by either counting the lines or giving it to some friend of his who will tell him "this sucks, pay me and I will do it for less".

You may be right.

Maybe he wants to count lines. Maybe he wants to check your capitalization style. Maybe he wants to see how well you comment. Maybe he wants to see if you follow the company's style guide. Maybe he wants to learn from your code. You don't really know and we clearly can't know. But no matter - that's his right anyway. You work for him. Trying to deny your boss access to code you write will certainly have negative repercussions on your job.

If your manager really wants to get rid of you and hire his friend instead, he almost certainly doesn't need access to your code to do so.

I think that giving him access to my code will only slow me down.

You may well be right in this case too.

Should I allow my manager to do this?

Yes, but "allow" is the wrong word to use here. If your manager tells you to give him access, and if you value your job at all you have no choice.

You don't own the code, your employer does. You aren't the manager, someone else is. You don't get to decide who does and who doesn't get to access your code, your manager does.

Your manager does not need your permission to access code you have written. Attempting to deny access to code you have written may be a quick way to get denied access to your job.

Answer 3

Strange sounding question.

Normally for software development you always have a version control system where everyone who has the rights can access the code and see its development history. Your question sounds like either you have your code local or in a non-accessible repository (which is an extremely bad idea by itself, data loss is always imminent) or your manager is not aware how the software is stored (which makes him helpless if you decide to leave or a truck hits you).
This raise alarm bells, as all others have already pointed out, the code does not belong to you and you have absolutely no right to deny access. The only exception is if you are a freelancer and you have reserved your rights concerning your code.

My crystall ball suggests that perhaps other people have access and you fear that your line manager is a pointy-haired boss ? There are many reasons why he wants to access your code and some are entirely harmless.

• He does not actually want to look into your code, he simply wants to know how it is stored and how can it be accessed and is too proud to admit that he feels dumb. By demanding to see the code he can throw in this question as valid inquiry without losing face.

• He in fact tries to judge your code by showing (parts of) it to other persons he thinks have knowledge. Yes, having no clue this could backfire for you because he cannot determine if the other person is bullshitting him, but if not, it is completely ok. Code reviews by other persons who have knowledge are a standard practice, especially because people have specific advantages and weaknesses: They avoid certain errors, but are also falling in specific traps. If you do not want that, the problem is you.

• Your line manager is a person who cannot concede that he is powerless and tries to maintain the appearance that he is in charge. Therefore the meetings and demands to see the code. This depends on the person if it is either mostly harmless (time-waste meeting) or extremely annoying (he really tries to use senseless metrics, stupidly comments your code or has found a new silver-bullet programming guru).

• The worst case: Some people have decided that they are not satisfied with your work and seek replacement. Now they realize that a maximum credible accident has happened: They have no clue how your code works and try to fix it. Counterargument: If that would be the case, it is more likely that he would press the matter with daily meetings.

Live with it, do what he wants (user52889s good answer is to talk to find out what he really wants) and if it goes wrong, either solve the problem by complaining to a higher instance or take consequences.

Answer 4

Do you really have the option to say "No?" I'm very surprised that your manager even has to ask. The fact that you are putting up resistance does not really work in your favor. If you stand by your code, you should be able to defend it, especially against someone less knowledgeable.

I cannot imagine the paranoid organization you work in.

Answer 5

Others have answered the question about should you give access. As well as the downsides in not doing as asked. Let me give you the perspective of a manager.

Let's say I have a worker with skills I'm really not qualified to properly evaluate. They produce something, maybe it works, maybe it has issues. Maybe I don't even know whether the kind and number of issues seen are "normal" or if it's indicative of bad work. Perhaps it's the opposite and the work is of a really high caliber but I have no clue and my boss is demanding more be done.

As a manager I need to make sure things are actually going as they should.

I can't exactly just take your word because you'll likely just tell me that the quality of your work is pure awesome - and you might have an overly inflated opinion of yourself.

I could hire a set of consultants to evaluate the work. Then again, no matter what the work is like if the consultants believe that by bad mouthing it they will get a beefier contract with me then they'll bad mouth it. So, my trust level going that route is already low.

This means I need to talk with people I trust. I'll have you package up your work and let these people take a look at it. They won't look too far, because it's going to be a personal favor. Hopefully they actually know what they are talking about. Which leaves a few possibilities.

• First, they are experts and think what you've done is at least good enough.
• Second, they are experts and think your work is a disaster.
• Third, they aren't really experts but don't want to get involved further and just say that it's good.
• Fourth, they aren't really experts but don't want to look bad and therefore pick on some rather meaningless things to have you change.

In each of these scenarios the only one you should be concerned about is if the boss actually knows some good programmers who believe your work is garbage. If that's the case then your best bet is to try and get a meeting with them to go over your decisions while listening carefully to what they have to say.

To be fair, the fact you don't want someone else to see it makes me believe you have something to hide. Perhaps you know your work isn't really that great and are afraid of what someone else might think about it. If this is the case then being able to discuss it with a third party would be a very good thing for you. So, I'd suggest you talk to your manager and ask if they could do the code review on site, with you. That way you can both learn from their experience as well as explain the decisions you've made.

Every great programmer I know actually wants people to look over their work. Why? Because coding is hard and even highly experienced people can make basic mistakes. Whether that's in the code itself or even in the overall architecture. We know that if it's caught early enough then the pain for fixing it is minimized. We also know that no one is perfect and we can all learn from each other.

Answer 6

It's a reasonable request, at least on the surface. There are many good reasons why your boss may want access to your source code, and few plausible reasons for denying it to him. "I don't want him to make my life more difficult" is not a valid reason.

Refusing to show him your code would be tantamount to insubordination. Bottom line, give him what he wants.

Answer 7

Background: he's not technical and he's mainly trying to monopolise access to my technical expertise, e.g. if you want to use technology X you must go through me. But other people have been very happy about my work and nobody else ever complained.

1. Your manager has every right to decide what technology to use, even if he is not equipped to make that decision. It is your responsibility to make your case, backed up by evidence he values. Talk dollars and cents, not raw performance power or spiritual superiority.

2. Is there a formal code review process? If not, start one. Otherwise there is no formal way to capture others' opinion of your code. Maybe those people who seemed happy about your code are the same ones criticizing it to your manager. Or maybe you're just paranoid. Without a formal way to hold you accountable for your code quality in others' judgement, you can't know. Nothing stops the same enemy from backstabbing you, but you can at least make a case of "that was not what he said in the code review."

3. As numerous others have stated, all code should be in a repository on a company server. Ideally periodically backed up, co-located, etc. If nothing is set up right now, make a case for it. ("If I am hit by the bus, you still have access blah blah blah...")

4. Document everything, from design decisions to build process to test cases. Based on your question, I am under the impression you are not an experienced developer in a company with little to none expertise in software development. Your manager may not know how to code, but (I hope) is sufficiently logical and analytical to understand the peripheral documents. They don't necessarily have to be very formal, but you should leave sufficient paper trail (virtual and/or physical) to allow some competent person to step into your shoes without too much difficulty. If you are unwilling to do so, you are holding yourself back in growth and holding your company hostage.

5. Your manager most likely does not have the right to share your code outside the organization. You don't have to worry much about the imaginary "friends".

Be open to your manager about your concerns. Good communication and mutual rapport is vital to any successful relationship, including in a professional setting.

If I were a colleague of you and realize what you're doing or thinking as stated above, I would be very weary to collaborate with you... unless I share your same sentiments against your manager. In that case, I must ask, "this job sucks.Why aren't you looking for a new job?"

Answer 8

As the OP mentions in a comment to @blankip's answer:

I am the only programmer, and there is nobody else using repositories. And I have no team.

It may simply be that your manager is trying to check the quality of your work, as any good manager should as part of a peer review.

Even if your manager is not technically able enough to peer review the code on their own, they can act as a 'cardboard cut-out', i.e. if you verbalise your work to your manager, then maybe you can spot problems, bugs etc. that you might not have done otherwise.

Answer 9

Your very last question is entitled "Everybody wants me for my skills, but I am not supported and all feels like a political tug of war."

It seems your manager is aware that there is more work than you can handle, but he doesn't know what to do about it. It seems that he wants to monitor what work you are doing for whom, which he should do: if he has a resource, he should know which department is using it. You are interpreting this as "monopolizing" but if you are a resource of your line manager others shouldn't be helping themselves to your time. I think it would be a good idea if you kept timesheets of your work. Discuss this with your manager.

Yes you should share your code with him. After all it's the company's code, not yours.

Something has to change. One of the following must occur.

1. They hire a developer junior to you.
2. They hire a developer senior to you.
3. You train your manager to code (it looks like that is what he's trying to do, because there's no budget for the previous two options).
4. You leave.

Your handling of the situation will make the difference between 1 and 2. Which is the one you want? If they hire another developer, do you want to be part of the interview process?

I suggest you take advantage of the meetings with your manager to discuss your workload and the future of in-house software development.

There is a 5th option: you get fired, and they get another developer or outsource. This seems unlikely as there is now code out there that you wrote and you understand best. But if you refuse to cooperate this becomes a realistic possibility.

Answer 10

The consensus in the answers seems to be that yes, you must allow him to see/access the code if he so desires, and be prepared for what, if any, consequences come about as a result. Best case scenario he just wants to see what's happening, worst case scenario it's a red flag that something's not right here but in any event you have no choice.

However, although it's doubtful this applies to you, I wanted to point out one other thing: in certain industries it may actually be bad or even against the law for your boss to access your code, or at the very least have any capacity to modify it. I'm not an expert here but if your workplace needs compliance with something like PCA or SOX (think: financial/banking industries) it can be a big problem in an audit if the boss has been viewing or modifying source code. The theory being that a separation of concerns prevents contamination. It's similar to the reasons why in most places developers cannot access production data. In some audit scenarios you need to be able to say, unequivocally, that only the developers have access to the source code and that managers - which may have access to the production data, unlike developers - do not.

Now obviously this veers into legal territory and you should in no way take legal advice from Stack Exchange, but just as a contrast to the answers above, there is such a thing as a situation where for legal reasons your boss can't have access to the source code even if he wanted to. If so, you might be able to approach him with your concerns that you're trying to keep the both of you out of trouble. Your mileage may vary, check with your higher-ups, void where prohibited, etc.

Answer 11

In workplace relationships, especially with your boss always remember:

You won't get very far by telling people what you're NOT going to do.

First off, he's your boss and any work you do is basically his. This also goes for if you mess anything up it is his fault.

The best way to handle this is to get involved. If he wants your code for a specific reason then ask him what it is and help him to get it. This way you atleast have some control or visibility over what he is using it for.

Answer 12

Requiring access to the code and changing meetings from every 2 weeks to weekly are both symptoms of a manager who does not feel fully informed on your status and progress.

Of course you should supply any artifact you produced on-the-job that your manager wants to see. In addition, think about what you are supplying, and see whether there is more you could do to keep him informed.

One strategy I used in a situation in which my manager was not qualified to directly evaluate my progress, I was on a one-person project, and my project was critical to the company's objectives: We agreed on a series of test cases and dates, and I reported each week on which test cases passed.

That is just an example. You and your manager need to work out together what information he needs each week for your specific situation.

Answer 13

1. The code is not yours - It belongs to the team and the person that paid you.
2. The code should be shared - for quality purposes.
3. You should be proud to show the code to others.
4. If you refuse to show the code, as an employer I would be suspicious to your intent. Are you selling it to a rival? Have you implemented stuff that can be used for fraud?
5. If your code is "crap" perhaps getting others to look at it will benefit you. You always learn from others. Even myself that has been in this business for as long as I can remember.

Answer 14

One other thing that has not been mentioned yet.

Consider that you have a "thumb print" manager. He feels that unless he is part of the job, that he is not doing his job. Therefore he wants to see what you are doing.

Ive had the privilege of working with a few specimen of these. It does not seem to matter to them that they dont understand the workflow, or what your doing. The important is that they can change something, anything. Make it easy for him.

Answer 15

Whatever you do, answer by email, so you have a track record and be very positive and helpful. This is not YOUR code, it's the code you wrote for your employer.

The thing is, if they want to fire you, many states are 'at will' employment .. so he can do that .. and he doesn't need a justification.. More likely, he has another agenda, then you need to help him.

Usually, when I am reticent to show the code I wrote (not "my code"), it is because it works, but it is not pretty...

So, after you agree to share/show you code, tell him that you code was not documented so that it could be understood by others. If he wants that to be part of your standard operating practices, then you can certainly do that, but you will have to revise your project estimates/costs upwards. Also, ask him if there are any coding guidelines or standards he'd like you to abide by.