42

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?

closed as off-topic by gnat, Alec, mcknz, user8365, user9158 Aug 17 '15 at 2:52

This question appears to be off-topic. The users who voted to close gave these specific reasons:

  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – mcknz, Community
  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, Alec
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 47
    You can't stop him, it's company property, but you should certainly be well prepared for all the eventualities you mention. – user207421 Aug 11 '15 at 20:41
  • 13
    Have you actually asked him what he wants the code for? How come you know his friends so well that you are sure what they would do with your code? – Masked Man Aug 12 '15 at 1:48
  • 40
    Assuming you're a regular employee, not an independent contractor of some sort, it's not your code. It's your employer's code which you have produced for them in the course of your employment. – Carson63000 Aug 12 '15 at 3:56
  • 8
    What does "monopolise access to my technical expertise" mean? It sounds like your manager is trying to manage you so that he can set priorities, understand the various business units that are asking you to do things, etc. If that's the case, that's a pretty basic responsibility of a manager. I'm not sure why that would have anything to do with needing access to your code. But I can't imagine why you would object to your manager managing you. Particularly when a number of your other questions have indicated you're being pulled in many directions at once. – Justin Cave Aug 12 '15 at 15:22
  • 8
    The fact that you appear to think that you have the power to control whether your boss has access or not is astounding. Do you, and your company, have proper source code management systems in place? if so, how is it that your boss can't already look at your code? – GreenAsJade Aug 14 '15 at 11:37

15 Answers 15

204

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!)

  • 1
    @user52889, What other suggestions do you have besides test coverage as metrics? – Pacerier Aug 14 '15 at 11:03
  • 3
    I mentioned test coverage because nothing else counts if the code doesn't do what it's supposed to. Documentation coverage is important. Performance metrics - time/memory/disk, depending on what matters (though bear in mind performance data is for comparison rather than an absolute metric). All of these can be fiddled if you're determined but typically brief inspection of the code is sufficient to guard against this. There may be other metrics that relate to the goals of the code or the team. – user52889 Aug 14 '15 at 21:17
  • 1
    Metrics can be hard to apply to code output. But, another option is to offer progress reports. Explain the features you are developing or bugs you are fixing at a high level. This could likely be accomplished in 5-10 minutes per week. – Austin Hartzheim Aug 15 '15 at 5:56
58

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.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Aug 13 '15 at 11:59
47

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.

29

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.

  • 20
    So what, he is your manager and he has every right to see your code and get other opinions on it – HLGEM Aug 11 '15 at 20:58
  • 19
    I'll let you in on a secret - None of his "friends" are going to do a thorough code analysis for him. They're going to just give it a cursory glance and see if you have the basics covered. If you've done a good job documenting it as you go, and your method names make sense and your classes are done appropriately for your platform, you're good. – Wesley Long Aug 11 '15 at 21:02
  • 9
    @Monoandale What you think will happen doesn't sound sustainable to me. Your manager must have some really good friends if he is going to have them review your code every week, just so he can pass it off as his work. If he challenges your work, you could always go to his boss and make him back up his challenge. What are you really afraid of? If he really wants to get rid of you, he'll find a way. In the meantime, do good work so you don't make it any easier. – Mohair Aug 11 '15 at 21:02
  • 6
    @WesleyLong: I think it's equally likely that the friends will do a bad job: they'll tell the manager that code shouldn't contain lines longer than 78 characters, or that the linebreaks are in the wrong place with respect to curly braces, or it needs more interfaces or design patterns, or a certain function has unacceptably high cyclomatic complexity. The questioner will be given a lot of work to do with no discernible benefit. But even so refusing to let your boss see your work is still not an effective way to prevent your boss judging your work by half-assed unreasonable criteria. – Steve Jessop Aug 12 '15 at 10:21
  • 2
    @SteveJessop - Then that is also a good thing, as the poster will know that there is no point in staying at this job, and can move on to something that will let them progress in their career. – Wesley Long Aug 12 '15 at 15:39
16

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.

  • 4
    The last paragraph only applies if the person looking at the code actually understands what they're looking at, which the OP has explicitly stated is not the case here. If my manager were reviewing my code, I can certainly see how answering the constant barrage of "What does this do?" could significantly reduce my productivity. – reirab Aug 12 '15 at 16:51
  • 3
    @reirab: Honestly the main thing the manager needs to be is a domain expert. This doesn't mean they need to code, just that they need to know the problem space. The OP should be able to explain how they're handling a specific problem and the manager should be able to say whether the logic is sound. I know I've been taken to task by domain experts who never wrote a line of code in their life over a crappy implementation before simply because I didn't understand the problem space well enough. – NotMe Aug 12 '15 at 16:56
  • 1
    Going over logic and high-level "what it does" stuff is certainly good, but they don't need to see the code for that (and seeing it won't help with that if they don't actually understand programming/software design.) – reirab Aug 12 '15 at 17:27
  • 2
    @reirab: I disagree with you. A developer can point at a piece of code and say "see, it multiplies the monthly deposit by 0.06" then the manager/whoever, could say "I thought it was supposed to be 0.006?" ... There are reasons here for it, and quite frankly none against. Reduce productivity? Who cares, the manager controls output. – NotMe Aug 12 '15 at 18:32
  • 2
    @reirab: or there's a trust issue - which I highly suspect is the case. – NotMe Aug 12 '15 at 21:53
13

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.

10

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?"

10

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.

10

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.

  • hi, 1 or 2 would both be great but I was told there is no money to expand my team unless the startup becomes profitable (I previously wrote academic IT because the context and characters are very similar) – Monoandale Aug 12 '15 at 23:55
7

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.

  • 4
    Obviously legal advice should come from real lawyers, but there's nothing in Sarbanes-Oxley when it comes to who can access code. SOX only cares about audit trails. And I bet 99% of the places that have to do SOX compliance aren't cryptographically signing their commits, which is funny. – Wayne Werner Aug 13 '15 at 19:25
  • 1
    Based on the OP's "I am the only programmer, and there is nobody else using repositories. And I have no team" comment, it seems unlikely that this company is having to comply with any onerous regulations. – Carson63000 Aug 15 '15 at 1:11
6

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.

6

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.

5
  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.
5

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.

  • 7
    If you're really good, you can give them all kinds of choices that are 100% irrelevant to the project and easy to implement. "Would you like this chartreuse or beige?" While (s)he is deciding, that frees you to get real work done. – Wayne Werner Aug 13 '15 at 19:28
4

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.