How to work with an unhelpful team lead? [closed]

Question

I came across a team lead who isn't exactly helpful. Any questions regarding the code base end up in : "I'll have to look into it, so you might as well do it."

Its frustrating as the code base is not in the least bit documented. I had approached the guy multiple times only to be swatted away.

Now that I learned the code (to some extent), I am quite angry as now I see how I used to slog over for doing something simple (and readily coded). I wasted a lot of time on this. The management is not concerned at all. Every time I brought up a problem, I get a "you need to put in extra effort" (which basically translated to "work on holidays".)

Multiple instances, I code something; only for it to come up during code review. I get a: "You could have done this instead" after him telling me off for the same problem.

I recently (after giving my resignation) started documenting the code as I didn't want the next guy to go through the same thing (when I am done with my work). Apparently (as per the same guy) I am wasting company time and should instead go home if I am done; taking a half day.

The guy doesn't even have the guts to say anything to my face, he just sits with his friend(s) and speaks just loud enough for me to hear.

I'll be starting somewhere else soon and want some advice on how to handle such cases (my friends tell me its quite common).

P.S. I went through: Dealing with an unhelpful senior developer, how to?

I already talked to my management. And I got through the time, but the thought is a little disturbing (to slog through the whole thing again).

Answer 1

Ah, wouldn't it be lovely if every company had a beautifully documented, well written codebase that the lead developer understood in its entirety? In practice however it just isn't like that. The pragmatic reality of our industry is that dealing with an undocumented, frustrating code base is simply a skill that you have to acquire as a developer.

You seem to be under the impression that the team lead knows the code base, knows the answer to your question, and is deliberately being unhelpful or can't be bothered to answer. It's likely quite the opposite - he doesn't know either, and would have to spend just as long as you would working it out.

Now that I learned the code (to some extent), I am quite angry as now I see how I used to slog over for doing something simple (and readily coded). I wasted a lot of time on this.

...but you didn't waste time, since this process has clearly gained you a knowledge of the code base. The fact that it took you a lot longer when you first started is expected, and not something to be angry over.

Multiple instances, I code something; only for it to come up during code review. I get a: "You could have done this instead" after him telling me off for the same problem.

Constructive criticism on your code is something to expect within a code review. It's not a personal attack, and just because there's bad code already in the code base, that's not a reason to add more bad code of the same style.

I recently (after giving my resignation) started documenting the code as I didn't want the next guy to go through the same thing (when I am done with my work).

That's great, if you've had authoristaion to use your time this way. If you haven't, then despite your good intentions, you're doing work the company hasn't authorised, so it's not surprising they don't value your time on this.

In short, it really doesn't sound like your team lead here was as unhelpful as you're making out - while I'm sure he could have done more, it sounds like you were also expecting a bit much of him.

Answer 2

Honestly while this particular Team Lead does sound somewhat obnoxious I think the root cause of the contention is down to a mis-match of expectations. He was expecting a dev who was more self-sufficient and you were expecting to be more spoon-fed. I'm not saying either stance is wrong - more that they clearly aren't a good fit for the two of you and while I'd hope that some of the less pleasant attitude the Lead showed wouldn't be common many of the specific hurdles you encountered will be:

"I'll have to look into it, so you might as well do it."

On larger, more complex code bases it's absolutely to be expected that the Team Lead doesn't know all the ins and outs "Encyclopedia" is generally not in the job description. A good Team Lead however should generally be able to point you in the direction of someone else on the team who does know the answer (or at least knows a decent amount about the area you are looking at). Sometimes however there simply isn't anyone (due to staff turnover, sickness, holidays etc) in those cases "you might as well do it" is about the only answer you can expect and you have to be prepared that you will not infrequently be expected to be able to figure that stuff out on your own as a last resort.

Its frustrating as the code base is not in the least bit documented. I had approached the guy multiple times only to be swatted away.

Best will in the world the majority of code bases I've worked with aren't documented. Even when there is every desire to get it done by the dev team there often isn't time allocated for it by the business. An in reality I'd expect a competent, experienced developer to be able to (mostly) figure it out from the code unless it's especially awful or obfuscated (been there, done that!). And in the (rather likely) eventually that it isn't documented then there's no real point in approaching the team lead "multiple times" over it - they certainly aren't going to drop everything and generate a load of documentation simply because there's a new team member. You just have to figure it out as you go, and it's probably a good idea to document as traverse the code and learn - even if it's just a comment or some notes for yourself.

More than once during my career I've been brought in to work on code where there was literally no-one in the business who knew anything about the code (usually because of an acrimonious split with a prior dev/dev team, although there was one memorable instance where it was because the poor guy had died suddenly!)

Now that I learned the code (to some extent), I am quite angry as now I see how I used to slog over for doing something simple (and readily coded). I wasted a lot of time on this.

I may be misinterpreting your meaning here - but isn't this totally normal? The more you get to know a code base the easier and faster it gets to work on. But the only way to get to that point is generally to slog around a bit and learn the code.

The management is not concerned at all.

Given the amount of times I've seen management be of the opinion that their twenty-year old code base with millions of lines of code doesn't have a learning curve I would think having them be "not concerned at all" that you had to spend some extra time on even relatively simple tasks while you got up to speed on their code is a Good Thing(TM)

Multiple instances, I code something; only for it to come up during code review. I get a: "You could have done this instead" after him telling me off for the same problem.

Without knowing more specifics this sounds like the code reviews were functioning normally to me.

I recently (after giving my resignation) started documenting the code as I didn't want the next guy to go through the same thing (when I am done with my work). Apparently (as per the same guy) I am wasting company time and should instead go home if I am done; taking a half day.

This sounds like a pretty poor attitude from him to me (as I mentioned above), I'd probably counter by asking if you'd be getting paid for the half day at home (if the answer is yes then feel free to leave a Bhoot-shaped hole in the wall on your way out!) but if not then ask him if there is anything he wants you to work on as a priority over the documentation.

Answer 3

You always have to expect situations where your coworkers cannot help you because they don't know the answer or don't have time. You have to get your work done anyways, so developing the right kind of behavior and skills is a great help.

If you saw the pattern

• Lead developer doesn't want to analyze the code to help you
• You code something
• In code review the developer suddenly tells you where to find the ready-made code

You should have changed your behavior rather than trying to change the lead developer.

He obviously didn't want to invest much time to help you, so you should limit your question to something small and fast enough for him to answer.

1. Could you show me the code that does X? (takes too much time)
2. Didn't we have something like X somewhere? (very vague, but sometimes yields results)
3. Do you know the name of the unit / class / function that does X? (with some luck he remembers, without luck he doesn't know)
4. Do you know what feature uses code that does X? (more likely, you'll have to analyze your way through the feature but you don't have to search for the needle in the haystack)
5. Do you know who implemented something like X so I can ask them?

If you don't get any help, start searching for classes and functions with the most probable name. Don't limit yourself to asking only the lead developer. If you have questions about a certain feature, find the person who implemented this feature, they are the most likely to help you.

Answer 4

The best thing to do in such a situation is to look for another job and then resign, just as you did.

I have worked in such places before and know what you are talking about. If the lead architect is not willing to help you understand their codebase and even discourages you from documenting their code (which is a tremendously ungrateful task to begin with), then you should just save yourself the trouble and leave.

Places like this will only drag you down and frustrate you to no end.