I work as a junior backend developer at a company. It's been two months now. Ever since I joined, they wanted me to pair program with another senior developer. However, since the deadlines were near, this Mr. Senior decided to delay explaining the codebase until after the release. Fair enough. (I've tried to read as much of it as I can but there's too many moving parts and it's hard to understand what goes where.)

So now that all has been done and dusted, he's still reluctant to explain what the code does. (It's a lot and it's spaghetti). I tried being upfront and telling him that I'd require him to explain to me what his code does because Mr. Manager expects me to make changes to it. Mr. Senior came up with the most bizarre excuses and declined.

He wants me to just stay away from his codebase.

Do I escalate this to Mr. Manager? (and potentially make enemies with other devs) or what'd be the right way to deal with this?

  • 2
    Part of the Senior Developer role is mentoring junior staff. It is supposed to be a leadership role. I'd escalate it up the chain, but without pointing fingers or naming names; ask Mr. Manager if someone could spare some time to explain the codebase to you and who he suggests you speak to about it. Commented Jan 25, 2017 at 15:54
  • I will point out that most code bases in business are large and somewhat spaghetti as they have evolved over years of use. It is a good skill to learn how to understand them. Just start with one module and slug through it documenting as you go. If you have questions about what something does, write those down as well and then take the tlist to the senior guy rather than being passive and waiting for an explanation. The more you figure out on your own, the better you will understand what is going on in the application.
    – HLGEM
    Commented Jan 25, 2017 at 16:20
  • What was the ultimate outcome of this situation? Commented Dec 3, 2018 at 16:30
  • 2
    @AlexanderTroup The outcome was that I ended up moving to another place.
    – An SO User
    Commented Dec 3, 2018 at 16:43
  • 1
    @LittleChild Developers like this are unfortunately common. I hope you learn to work with them where possible, around them where necessary, or through them where essential! Commented Dec 5, 2018 at 11:58

8 Answers 8


It's concerning that the company lets a Senior Developer be the only person with knowledge of a codebase; the Bus Factor (https://en.wikipedia.org/wiki/Bus_factor) is one, which is a very undesirable number.

Send an email to the Senior Developer, asking for a meeting to discuss the codebase. Either he'll refuse by email, or he'll attend the meeting and give you the same excuses again. Minute the meeting, then discuss it with your manager; at this point, it becomes your managers problem, not yours. You're being stopped from doing your job (if you had daily project scrums this would have come out long ago), so your manager needs to know. Stick to the facts at all times.

Basically, if you can't do your job, you're the one who'll be fired, not the Senior Developer; so make sure your manager knows the situation.

  • To continue defending his codebase from others, Mr Senior may reluctantly attend the meeting physically, but make no real or genuine effort to give valuable answers or help Mr Junior. This will make it much harder for Mr Junior to prove to the manager that Mr Senior is not being cooperative. How to handle that situation?
    – Gruber
    Commented Jan 25, 2017 at 14:32
  • Mr Junior should ask specific questions, rather than a general "Please tell me about this codebase". He should also stress at the appropriate point that they both want the same thing; a reliable, maintainable and fully tested codebase that can be extended upon when needed.
    – PeteCon
    Commented Jan 25, 2017 at 17:20
  • 2
    Since a pedagogical and sincere walkthrough (or useful documentation) by Mr Senior probably is too much to hope for I agree. In practice however it's easier said than done to find specific questions to ask relating to a largely unknown and impenetrable codebase.
    – Gruber
    Commented Jan 26, 2017 at 8:56
  • @Gruber - then you ask for a high level, non-technical explanations of functions/modules, and a formal plan/roadmap for when the exploring of each individual function/module in codebase is supposed to happen. Definitely, asking for specifics is vitally important. Commented Jun 1, 2017 at 15:40

You are going to tell Manager that Senior has to take a more pro-active role in helping you make sense of the codebase. I take it that nobody has bothered to compile any documentation worth reading, right?

If this is the case, you might have to explicitly document the codebase or at least the part of the codebase you are working on before you can do anything else including writing additional code let alone refactoring.

I have no idea why you'd think that you'll be making enemies out of other devs but whatever.

Indisputable fact #1: you are not going to be able to do anything unless you can make sense of the part of the codebase that you'll be woking on.

Indisputable fact #2: if you are assigned deliverables and you don't deliver, Manager will be looking for someone to blame not excuses. And you fit that role perfectly.

Confer with your manager. Make it clear that Senior's putting a low priority on working with you is a showstopper for you.


It's very possible that everyone knows what an impossible jerk the senior is to work with. It is because you are junior that you have been stuck with senior. Asking for advice is a good idea. If there is any way to ask your manager for advice about how to better get your job done you accomplish both informing the manager, and also may get advice you can follow. Getting the resources to accomplish the necessary tasks is definitely the job of your manager. If you didn't have a desk or a computer, you'd go to the manager. A second source for advice may be HR. It depends on who you feel most comfortable with.

Staying silent is the worst, as the job is not getting done, and you are obviously not doing it. And you have probably been assigned to senior because everyone knows senior isn't working up to snuff. Senior probably has complained s/he isn't getting enough help. Thus, a new assistant (you) has been assigned. There is more going on here than you know. Get some local help.

  • +1 for the last two sentences. There is a reason why OP was asked to pair with this senior dev, and it might be to assess the senior dev in a mentor role.
    – Trebor
    Commented Jan 25, 2017 at 14:38

It is your job at stake if you don't perform as per manager's expectation! So I suggest, you should discuss this with you manager and also provide some possible solutions from your end.

Ask your manager if there is any knowledge transfer(KT) plan? If yes, then request him to set up a daily meeting with the senior developer and ensure the plan is followed. If no then ask him if seniors can create one? As it would be beneficial in future as well.

If the product is big you can ask your manager in which specific module you should focus on. Refer the internal product Wikis, Forums and documentations and try to get more insight.


Simply email your Senior Dev, cc your boss and say something like

"Hey, Boss has asked for us to have a session to go through the code as he wants me to help you on X. I can see slot is free in your calendar, or is there another time you'd prefer."

You can even add something jovial like "I'll bring the biscuits" or something, if you feel it may annoy the senior dev, or if you want to appease him etc.

Make it look like a reasonable sounding request, include the manager so if it doesn't happen, you have a paper trail saying you did what you could to organise. Then if you get no response/negative response then your manager will see it and sort out accordingly.


I don't think I would be inclined to take this too personally, it could be that the senior developer is simply not good at explaining things. That's a lot more common that you would think. Software developers are not always the most communicative people.

I have 20 years of experience myself and started on a new project last year. I was told to use a person who had been on the project several years as a resource to explain the project, the code, and my tasks to me. I quickly discovered that he was not very good at explaining, partially because he knew the software TOO well.

I suggest you do your best to dig into the code and learn it as best you can in your available time. Read documentation (if there is any). Draw pictures. Whatever helps. You may find you even impress your coworkers and manager with your initiative and your ability to pick up the project.

I can't hurt to mention to the manager that you aren't getting much information from the senior person, but watch it, you don't want to get a reputation as a complainer. If you can't get the information from the assigned mentor, find someone else to ask.


I just want add a thing over the ones that are being said before, Remember that if you do something just for doing your work, it can't be bad.

Actually you are not being able to do your work as junior developer, for my carrier i would do everything to work better.


Cold hard truth:

The senior developer is mediocre and has worked hard to become indispensable to the company, albeit, in a negative way (job security through obscurity (& mediocrity (in code)).

The preferable path to take is to leave that company (which, fortunately, the asker has already done) while remembering and looking for red flags such as:

  • how many developers are there given the company's revenue (is it really a software company? or they're just trying it out)
  • how up to date is their stack (are there influential people stuck in the 90s (e.g. version control is bad, IDEs are what hippies use these days)
  • are they open minded about learning, have they ever heard of iterative development
  • is the codebase a large monolithic chunk written by someone, sometime, long, long ago
  • how does their website look like and where is it hosted (gives an idea about the company's level of professionalism)
  • check reviews about the business/how does the company respond to criticism, suggestions and feature requests.

You must log in to answer this question.

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