How can I deal with being told I ask too many questions?

Question

I was just put on a Performance Improvement Plan (PIP) after six months at my first job out of college. I know this means I'm probably going to get fired when the time is up, but I would still like some advice on how to improve for the future.

One of the points in the PIP was:

I was told that I ask too many questions.

Being a new hire, I like to ask questions to understand how our code and infrastructure works. I was reprimanded for this. Apparently I'm wasting other engineers' time when they respond to my questions. I didn't at all realize this was the case - I assumed everybody else at a tech company liked talking about technology, but apparently I've been annoying a bunch of people by asking questions.

Is this usual? Is the new person at a company not supposed to be curious or ask questions that aren't immediately related to their work?

I was told to spend more time trying to figure things out myself

My manager has no way to know how long it is from the time I encounter a problem until I ask someone for help. I pretty much always try to figure out problems on my own for at least an hour.

Is this too short? What's a reasonable amount of time to spend on a problem before asking a coworker who knows the answer?

I was told I need to use better judgement when asking questions

Although I was also scolded for "going down the wrong path" when trying to solve a problem I was not familiar with instead of asking someone who was. When I asked about the contradiction, my manager and HR said I just needed to use better judgement about when to ask questions.

Is this common in other companies, about knowing when and if to ask others for help? How long does it take to learn?

---

I tried raising the points I mentioned above, they just got mad at me for arguing with them and not taking their advice well.

I usually check our documentation before asking a question, but our code is severely lacking in documentation and comments, which is also often out of date.

Answer 1

Never just present a problem

I took a quick look at your profile and noticed you've been around the StackExchange community for a while. You will undoubtedly have noticed here that the questions which receive the best responses around here are the ones that present the problem and the reasoning that they've taken already in an attempt to answer the question.

Work life is just like this. If you are asking a question then you want to be sure to also let them know what you've done to try to answer it yourself already. This benefits you in a number of ways:

• It shows that you're not asking unnecessarily. If you expose your reasoning then you are letting the person know that you're making an attempt before asking a question and not just being lazy.
• You will likely receive feedback that will benefit your thought processes. If a peer comes to me with a problem and exposes how they've attempted to answer a question not only will help to guide them on the right path but I'll also help them to understand how they could have thought about the question to get there themselves. The more you expose your thought process and reasoning the more other people can help you to build upon them for future problems.

Answer 2

There are a couple of points here to unpack.

I assumed everybody else at a tech company liked talking about technology...

Not necessarily. Many technical people will talk about technology that is relevant to the task they are doing now, but may have absolutely no interest in anything else.

I think you may be getting confused between this and:

I was also scolded for "going down the wrong path" when trying to solve a problem I was not familiar with instead of asking someone who was

Consider the boy who cried wolf :) If you spend someone else's time talking about stuff that is not relevant to what they are doing, then when you ask them a relevant question, you may find that they feel they have already lost enough productivity with you.

I pretty much always try to figure out problems on my own for at least an hour. Is this too short?

In many cases, yes it is too short. Unless the problem you are trying to resolve is simple, then you should invest more time in searching for and trying different permutations. If the problem is simple, then an appropriate web search should yield the correct results.

Put all these together, and what I see is a young programmer who has some issues with judgment, which is what your HR person told you. It's not insurmountable, but there are some things you need to think about.

• Save hypothetical tech questions for the lunch room. It's not appropriate unless you know the people well to waste both your and other people's time on irrelevant questions.
• Learn how to apply better web search terms. If you are being told that you are asking too many questions and taking too much time to ask, then clearly you are asking the wrong questions.
• When asking a question, show what you have tried. Classic Stack Overflow mentality. If you haven't got anything to show as a concerted effort to resolve an issue, then you haven't tried hard enough. In fact, don't be afraid to utilise resources like Stack Overflow if there is something tangible to ask that may be in the public domain. And lastly;
• Save questions for business-specific questions. Don't ask about how to drive your programming tool, but do ask about domain- or environmental-specific issues that won't be in the public domain.

There are a lot of things here you can do to improve. You may find that the PIP may be a very valuable tool for helping you to become a better developer :)

Answer 3

The problem is that, when you interrupt someone's work, they do not only lose the 5-15 minutes it takes them to answer. They lose much more time, since they need to regain concentration. And that can be quite frustrating.

I was in a situation similar to yours. I used to go to people and ask them questions right away. Even when they did something that would block me. That may even have interrupted other people nearby.

My manager gave a solution: use email and instant messaging, even when the person is sitting next to you. That way, you will think more how to formulate the question, and during that process you may answer yourself. Also, the other side can answer you when they have some free time.

Another option is to set a meeting, where all things are cleared up.

Answer 4

I am going to try to answer from the perspective of the company. I am not that company, so there may be things that I don't see, but I have seen this before at my own company.

Too Many Questions

Most of your confusion seems to come from the fact that you didn't understand that asking questions is a dangerous game. It is!!!

When you ask a question, you're admitting you don't know a thing, and that you can't figure it out. As a software developer, one of your tasks is to figure it out. You are insulting the "current" dev team by basically asking, "So you wrote such crap code here that I can't possible figure out how to read it or what it's doing, so I am going go need you to explain it to me."

Now the tricky part here, is that some times that is exactly the case and you should be asking questions. It's just important to remember that, no matter what, there is a negative side to those questions.

Another thing that I think I sense in your OP is that you're asking questions way too early. It is absolutely fine for a new developer to sit there reading, and researching for an entire day, to write 2 lines of code. In fact, with 14 years experience, I still end up doing that. Writing professional code is not about "how much" gets done, it's about "how well" it gets done, and being able to repeat that success. I doubt anyone will bawk at you for taking 100 times longer to do a tenth of the work as a trained, and established developer. In fact when I hire someone, I write off the first month as not expecting any real work, and the first six months as not expecting much.

Not spending enough time on your own

This is a biggie!!! When you ask a team member for help, you are pulling down the productivity of that person as well. You are impacting their process and insulting them (see above) at the same time. There is no way for you to win, if you have to ask for help. Think of every ask, as a lost battle. You can still win the war, but you lost this battle.

There are some things you can do to mitigate the problem:

1. Ask in email, never in person or chat. Chat might be the preferred way to do it "officially", but email is nicer because the receiver can handle it in their own time.
2. Approach it from a "lower" stance. You're the supplicant here. Do some grovelling. It's OK. A little bit won't hurt you and will show the receiver that you do care about their time, i.e. "I know you're really busy, but I can't seem to figure out how to integrate with your API. When you get a few moments can you show me what I'm missing?" It shows that you're in the wrong not them. It's important.
3. List the steps you have taken on your own. "The API document says to pass in a String representing the user's id. I tried passing the user.id property and the user name, neither worked." This shows that you at least tried something, and that in general, you are starting to "get" the product.

Better Judgement When asking questions

This, to me, sounds like you "whined" to someone, and they didn't have a nice way of saying, "You're annoying everyone with your lame questions. Stop it!" In other words, I think this is a non-issue. Once you correct your other issues this will go away.

Bad Documentation

Ahem! That's another personal insult. Never ever say that. EVER!!!! Once again you're saying that their code quality is so poor that you can't figure it out. Their response is always going to be "Works for every one else, so you must be the idiot, not me!"

Also, this is a bit of "welcome to the real world". In the real world, clients pay for working applications not code or documentation (most of the time) so it's very common for documentation to degrade over time.

If you think documentation is poor and needs to be addressed, then bring that up, quietly, with your team lead. Let them decide.

I will say this though. No matter how crappy the documentation is, with the source code right in front of you you shouldn't need it. It's a real nice to have, don't get me wrong, but you can work without it.

Being Late

Obviously, don't be late. That's a no brainer. In fact in your situation right now, be 30 mins. early!! No excuses. You're ruining any hope of finding your next job with this one. If I called the HR department there and asked about your attendance, and they said "He was frequently late" or "He was written up for being late" that is an instant red flag. I mention this, because whether you keep this job or get a new one, this more then anything else will stop you from getting that next job.

Low quality Code

This is probably true. Given the question problem, you are probably not writing good code. You're new though, and that's to be expected. I find the colleges don't teach a damn thing about real world coding. Never have I hired someone straight out of college and gotten a "good developer". That doesn't mean that they didn't go on to be good developers. They just don't start out that way. Writing good code means staying on top of the latest trends and techniques. You're constantly learning. The moment you stop is the moment you start sucking.

In conclusion

This post has been rough, but I wanted to show, clearly, what a company's stance may be. Often times they (companies) wrap up their comments in so much "manager speak" that it may be hard to understand. I tried to reduce the manager speak in this post as much as I could, but that means it comes off a bit rough.

Your most important steps to fix your failing career:

1. SHOW UP TO WORK EARLY!!!! (I can't stress that enough)
2. Ask questions with a mind set that you're already insulting the person you're asking.
3. Show your work. When asking a question state clearly what you have already done.
4. Spend more time learning on your own. It's important to spend way more time researching things then asking things. Honestly 3-4 days looking something up on your own, will be more respected then a 30 second question.

Answer 5

Learn how to take criticism. I realize you're an engineer-type person, so you deal with right and wrong. You want to defend your questions. Start with indicating you're going to accept their feedback and try to ask fewer questions. If you get a positive response from that (pay attention to how they react!!), you could ask for some clarification on what is a good and bad question. Think of the situation like working with a technology that has a bug. You can argue all day long that your code should work and there is no need for a work-around, but that's not reality. Do what works (and that applies to when you think there is a bug with the technology but the way you implement it is what is really wrong.).

Your situation may be an example of people not confronting problems and going behind someone's back instead of offering feedback. Now it may be too late. Are you sure no one has been telling you to stop bothering them all along?

There can be problems when someone asks a question:

1. I have something to get done, so now is not the time. Ideally, people would tell you when is a good time.
2. This is something you should be able to research on your own. Unfortunately, it's easier to Google obscure solutions to problems with antiquated technologies than it is to find policies and procedures for your own company People don't document. It's sad but true.
3. You keep asking the same question over and over.
4. Your questions come across and overly-critical and people get tired of explaining/defending why they do things a certain way. This is even more difficult when dealing with new people. "Why are we using COBOL?" Because it was the best technology at the time and has been running since you were in diapers. Now go do your job.

Based on what you're saying, you haven't been given a lot of feedback until being put on probation. That's a shame. Many places do not put the resources and practices in place to train and mentor new people. If someone really cared enough to help you succeed, they would have said something to you.

Answer 6

Been in exactly same situation.

Problem

What you describe is the issue faced by most fresh graduates. Most universities only teach you basics or concepts whereas in practical job you need a lot more.

Most companies when hire fresh graduates have training plans in place, which if you follow you should get confident doing your job within an year or so. But some people do get curious, if you give them a simple task to fix a small component in a system, they don't get it until they master the whole system and I believe you are one of those...

I think you ask questions because,

• You feel you are taking more then reasonable time completing a task, as you don't understand some part of system.

• You are just curious to understand system completely

• Your company didn't provided you proper training

Solution

If my assumptions are right then stop asking questions unless you must have to (full stop - right now)

• Start spending more time understanding system (not just 8 hours)

• Use SO or other related sites instead (after doing your research part)

• Ask your company to train you properly @areas you need help with.

I followed above and now working in same company after 5 years and I can claim I know more then anyone here.

Answer 7

I wanted to take a crack at this from a management point of view.

A PIP is a comprehensive thing

It's quite likely that the performance improvement is a collection of the things that your management has highlighted, all done together. I suspect that if you were the person who asked lots and lots of questions, but came early, stayed late and did a great job when writing code, the team would treat the question asking as a personal quirk, or that you are exceptionally thorough.

But when the team has to help find and fix more bugs in your code, after answering more than the usual amount of questions, and they see you working less hours or showing up late with no notice, the team and the manager are going to feel that you're not contributing to the level you need to be, and you're not putting in extra time to come up to speed. The question asking was likely raised in light of the other problems, because if you try to fix code quality by asking MORE questions, it will be unsustainable by the team.

Every hour counts

A new college grad IS an investment in team time. Any manager who tells you different either has never hired a new college grad, or is lying, or has really exceptional team leads working for him/her. Any new hire is some investment, but college grads are MORE time. Usually the tradeoff is worth it, though - but be aware that college grads do ask more questions than more seasoned developers.

However - every hour counts. A team of developers will get more done in a given week when everyone is up to speed, knows the code and doesn't ask many questions. Also, a team in this gelled state will be able to ask and answer questions very quickly - which also speeds up productivity.

Answering questions does take time. And there's a context switch every time a developer stops writing code and starts answering questions. So highly interrupt driven question answering is much more of a productivity killer than sitting down for an hour and answering a collection of questions.

I'd be safe arguing that ANY context switch costs 1 hour, so even if you have a 5 minute question, you've cost the team an hour when someone stops to answer your question. That means that taking 1 hour and not getting it, then asking for help actually costs more time than taking 2-4 hours.

There is no such thing as "it will only take the other guy 5 minutes to save me an hour". Given the metric of at least an hour per interruption, the other guy had better be saving you 2-4 hours.

Tips for Asking Questions Well:

• Understand and ask questions in accordance with the urgency - if you absolutely MUST have a problem solved in an hour, then interrupting almost anyone who can help you is a good idea. If you were given a 3 week deadline, then interrupting less and solving your own problems more is a better idea. This means that in an emergency, people often ask lots of questions that they would otherwise research on their own. Because it's absolutely essential to have the answer as quickly as possible.
• Use question forums for their defined purpose, or intuit the purpose from existing questions/answers. Stack Exchanges, for example, have a fairly extensive set of ground rules that are pretty well documented, and a particular expectation that users search for previous answers prior asking. A different forum may expect repeated questions but only about a very narrow area.
• Research your question. Expect that writing a good question can take as much time as giving the answer - in many cases, you're describing (tersely!) the steps that brought you to the point of being unable to answer the problem. Also you are likely to be documenting all the symptoms of the problem.
• Target your questions - figure out who can actually answer questions when possible rather than asking everyone. Not every question is worth a discussion.
• Aggregate a big pile of questions - especially when you are new, take a day to review the problem and the code. Aggregate your questions into a bulleted list with topics aggregated together. Then ask a mentor or buddy where to go to get help on these. It's quite likely that most of the questions in hour #1 will be answered by hour #6. Questions that came in hour #1-2 and couldn't be answered by hour #8 are probably at the top of your list since you know that in 8 hours you couldn't figure it out.
• Code is not "self documenting" but a whole lot of information can be learned by reading it. I learned many undocumented systems by sitting with a notebook and drawing my version of the design as I went. If you haven't read several levels above and several levels below the area in which you are working and you haven't read through the docs of external APIs you are using, you haven't researched well enough.
• When trying to figure out an answer, it goes a long way if you can suggest possibilities, rather than asking for the answer. "Would this be the right way to do it?" is better than "How do I do it?" - even if the answer is "you're doing it completely wrong" - you can still ask "why is my way wrong?" and the more meta "how would I learn to do it right repeatedly"? This is the "teach a man to fish" approach - learn how to fish, don't ask questions that only get you 1 fish.
• Avoid questions that are merely a polite way of disagreeing. There is a line between "is my way of doing this workable?" vs. "I don't understand (ie agree with) why you did it your way?" Those are fine conversations, but they are better held informally after you've gotten to know people.
• Moderate your big picture questions - these are usually the "why" questions. New people are well within their rights to ask lots of "where" & "who" questions (where's the docs, where's the process for this, where's the place in the code I may want to look at? who can answer this? who do I invite to the review?) and some number of "how" questions - is this how I should approach it? how can I get your agreement? But "why" as in "why did we build it this way?", "why don't we document code more?", "why is this not a priority?" - they are legitimate, but until you've got more experience with the work and the business, they are not the most necessary questions. They can be GREAT for a 1 on 1 with your boss where you have no other urgent issues, but if the "why" crowds out the where, who and how then you are not focusing on your job.

Answer 8

There are plenty of answers here already, but I want to address a few specific parts of your question.

Although I was also scolded that I don't spend enough time trying to figure things out on my own before asking others for help. This isn't true though, and my manager would have no way to now how long it is from the time I encounter a problem till the time I ask someone for help. I pretty much always try to figure out problems on my own for at least an hour.

Is this too short? What's a reasonable amount of time to spend on a problem before asking a coworker who knows the answer?

Emphasis added is mine.

For starters, yes, one hour is probably too short of an amount of time. I say probably though... it really depends on the problem. And having a time limit is good, but you should rely more on indicators that you are at a wall than only a time limit. But importantly, when you are ready to ask questions, the recipient of your questions should be able to see the research you've put into your problem just by the sort of question you're asking.

And that's when we get to the bolded part of the quote. You're technically correct. No one but you can really know exactly how much time you put into a problem before reaching out for help.

But based on what question you ask, what information you provide with the question, the context of the question, and how easily I can find the answer with a simple Google search, I can make a pretty good estimation at how much effort you put into solving the problem on your own.

If you ask a question, and the first Google search I try yields your solution as the number one result, that's two strikes for you, basically. It doesn't matter if you spent 10 minutes or 10 months on the problem. You should have already studied that page and it either fixed your problem, or you're telling me about this page and why it didn't solve your problem.

But moreover, what sorts of questions are you asking? Are you asking for outright solutions? Or are you asking for a little nudge in the right direction? Sometimes, the wall you're facing is that you're completely unaware of some library or some existing part of the code base that will make solving your problem simple.

Answer 9

If you're asking non-work related questions then it could be considered idle chit-chat which is a bad thing in your bosses eyes, so stop doing it.

However, asking work related questions is a good thing as it shows you are interested in your work and want to improve yourself.

If you have been accused of wasting other people's time, I would suggest they need to manage their time better and tell you they are busy rather than answering questions when they should be doing other things. However, a more helpful answer would be to ask if they have time to answer a question before you ask that question.

Sounds to me like your boss is a bit dumb, or he just wants to get rid of you for whatever reason. They are going to fail as they don't document things which is a recipe for disaster when their main developer(s) leave, been there, done it.

Answer 10

I would say you have learned about what this company expects through the school of hard knocks. Questions at this place are a no-no.

I think your main problem is visibility. Asking questions on slack is something that a lot of people can see; even if they don't feel compelled to answer, that might still affect their judgement of you. Meanwhile, if you spend a day figuring out a single feature at your desk, nobody sees that wheel-spinning. You appear to be doing something wrong, rather than just pounding the keys at your desk, which looks like work. Sure, maybe in weekly, monthly, or yearly reviews, your productivity will reflect poorly. But your slack questions are seen multiple times a day, while your actual productivity is measured far less frequently.

I was in a position like yours. I was hired to fix bugs in a propriety CMS while the lead (read:only) developer scrambled like mad to add features for customers. We were way backlogged. The codebase was not in version control, and each side had its own bespoke version. It was a complete mess.

Naively, I thought it better to take up 10, 20 or 30 minutes of mine and the lead's time chatting so that he could explain things to me, rather than to spend half a day, a whole day, or even several days to reverse engineer a feature to find out 1. what is was supposed to do, 2. how it was supposed worked, and 3. how to fix the bug.

Turns out, when my boss (one of two partners) found out about this, he though it showed poorly on me that I was unable to troubleshoot code on my own, and that I was taking any of our precious lead developer's time. (The lead developer seemed to enjoy talking about how his codebase worked-- in any case, he didn't complain to my boss about it, as he told me.). So, I stopped asking questions, and my productivity dropped probably to 10% of what it was. I was let go about a month later.

Anyway, this company is telling you, in a poor manner, that they don't value this time efficiency and documentation side-effect. So don't do it.

Spend a day trying figure something out. Spend a couple days-- spend a week! Who cares? Not this company. Whatever you do, don't ask questions, because that is something they do care about. Whether it's management, or your peers complaining, it doesn't matter. The company has told you what kind of culture it is cultivating.

So if you think about your situation, with tardiness and poor quality code, dropping productivity might add up to being too much. Instead of waiting until the ax falls, you might want to look for a place that's a better match for you and your style. Someplace that perhaps has some code comments and documentation, for a start.

So how did my story end up? After a period of unemployment, I got a new job. Aside from the codebase being much better (we're using an industry standard CMS, we're on version control, we have dev, staging, and prod environments, etc), my peers are outstanding and my company encourages learning. We have a wiki, where we share our information and avoid re-inventing wheels. We chat all day on slack, talking about work, asking questions, brainstorming, sharing news, info, and discoveries. We start projects to improve our processes, such as agile, vagrant, and implementing continuous integration. We teach each other and learn from each other. We act like colleagues and collaborators; not competitors. We have an on-boarding and orientation for new hires and contractors, which we would not be able to have without this culture. That's a good thing, because in the time I've been here, we've grown from two (me included) to eight, and also contractors during busy times.

Our company sends us on trainings, conferences, and encourages taking time for web-based classes and casts. I've learned more in this time here than in any other period in my career, esp. in subjects I specifically don't work in. It's wonderful; I've been here 4.5 years, and don't see much reason to leave, other than to learn a new technology. The culture at my new place is really geared towards learning, understanding, and implementing best practices, which leads to productivity. It's a win-win.

Seriously, there are better places to work for. This is not the place for you, and you are not the person for them.

Answer 11

Types of work questions:

1. How do I do something I need to learn to do the job.

2. How do I do something I need to learn to do the job, but I have already been told.

3. How do I do something that I should already know.

4. How do I do something that is off target to the job, and I know it is off target.

5. How do I do something that is off target to the job, and I don't know it is off target.

6. Funny questions and small talk.

So...

You can pretty much ask as many #1s as you want. They might think you are annoying but it is a good/smart annoying. You wouldn't be written up for this.

If you are asking #2s then they think that you have a comprehension problem. Or you just like to ask questions but not listen. This is put up with to a certain extent and gets old quick.

Depending on your position and what odd things you bring to the team #3s might be OK - you know a specific area well, you are cheap, whatever. However you better not ask #2s after you ask a #3.

There is no doubt that the #4s are not good. You can get away asking some of these but not as a new employee. Co-workers would expect you to ask #1s (and some #2s) way before thinking about #4s. If you are asking a lot of #4s they think you are all over the place.

This is the worst. Just asking a couple of #5s can put you off to any team member. It means you don't get it and probably don't have the aptitude to get it.

Hmmm... #6s are dependent on the person. A lot of people can ask tons of #6s if they are entertaining or funny. On the other side if you aren't #6s can be really bad especially if you are asking #2-5s.

If you think to yourself why can't they just be nice to me and help me out if I am having issues and asking #2-5s all the time. Because they can hire someone else who knows more and doesn't ask stupid questions. If I were you I would start paying attention more, maybe even carrying a notepad with you at all times, and when someone does answer something you make sure you are 100% sure that you get it or ask for clarification on the spot.

Answer 12

This answer is about how to take feedback (the other answers already cover how to ask questions very well).

Although I was also scolded for "going down the wrong path" when trying to solve a problem I was not familiar with instead of asking someone who was. When I asked about the contradiction, my manager and HR said I just needed to use better judgement about when to ask questions. I never realized asking questions could be so dangerous.

That was a bad reaction on your part. Picture yourself in their place for a moment. You know some employee is performing poorly, and you are telling them what they need to improve. Without bothering to think about what you are telling them, not showing any interest in your feedback, let alone apologize for not fulfilling expectations, that employee incorrectly claims that you are contradicting yourself.

When receiving feedback, in particular if it is negative, you should first listen, then seek to understand (asking clarifying questions as necessary), and only then respond.

That's because, unless you have intentionally messed up, you and your boss disagree on whether you messed up. Either your boss is wrong, or you are (or both of you). You should entertain the possibility that it may be you, because it's very unlikely that your boss is entirely wrong, and you are entirely right - and even if you are, you can only convince your boss that he is wrong by showing him where he is wrong, and that requires listening to him, too.

You might also ask for advice on how you could do better.

For instance, after hearing that you are asking both too many and too few questions, you might have asked:

So I have asked both unnecessary questions and failed to ask necessary questions. How should I determine which questions are necessary? That is, what kinds of questions should I be asking more of, and what kinds of questions should I be asking less of?

The following factual discussion would likely have revealed what you need to do in order to improve.

Is this usual? Is the new person at a company not supposed to be curious or ask questions that aren't immediately related to their work?

To what extent asking questions is expected or desired differs among workplaces. You might wish to adapt to the culture of your workplace, which you can discover by observing your peers, taking note of how people react to your actions (are they annoyed by your questions, or delighted about them?), or ask for their feedback ("Was it ok for me to ask that?").

Answer 13

I think if you're young like myself your mentality is to save time and find the answer and then move on to the next problem. However I find with the older generations that is not a concern nor a priority to them. So yes taking an hour to solve a problem is too short to someone who is older, however may seem like too long to you. I suggest observing the generational gap and follow suit even if you don't agree. Eventually you will become quicker at solving issues with more experience.

As for getting in trouble for asking questions I try to use the explanation of I want to see how it should be done, or go by company standards. Again I noticed in older generations this is irritating for some reason. I think older people tend to think I solved this by myself and I didn't get any help so they are less willing to help. They feel interrupted as well. Like someone mentioned above try to find the right time to ask for help, whilst stroking the ego, IE "I heard you were the guy to go to about this...." "Someone said you are the expert on...." hopefully that will make them overlook an interruption and they will be more willing to help since you gave them something to prove. Be careful with that last piece of advice as I am sure in some cases it could backfire.

Answer 14

I find it hard to define exactly, but I've worked with a number of junior devs, and some of them asked questions that were very satisfying to answer, and some of them didn't. Answering your questions distracts your coworkers from their work, and that's okay, if something good comes of it and the company benefits in the long run. That means you need to ask the right person, ask the right question, and get to a place where you've gained understanding that lets you make significant progress. If you have a knack for that, people will feel like time spent helping you is time well spent, and you're a valuable collaborator. If not, they're liable to find you annoying instead.

Obviously if there's a lot you don't know, that puts you in a delicate situation, but attitude and aptitude make a big difference. No one expects you to know everything, but they do care about how you deal with it. Others here have already covered the things you can do to get the most bang for the buck when you do have a senior dev pigeonholed, so I won't repeat their advice; I'm just trying to shed some light on your coworkers feelings that led to this situation, so that you can understand and avoid it in the future.

Answer 15

This is almost more of a suggestion for your employer, but perhaps you could make it work for you.

Did they assign you a mentor when you started? Giving a new employee an assigned mentor, someone that they can go to with their questions is a good idea. This gives them someone already experienced at the company and prevents the new guy from constantly bothering everyone else. :-)

The mentor will also know the right people to ask and the right places to look for things such as documentation. For example, some projects might have Google Doc documents, another has them on an internal file server and a third has them committed inside the source repository. While other projects don't have any docs at all.

Another tip is that when starting work on a new project ask for a tour. A solid block of four hours of time with you and an experienced person can get you up to speed without requiring that four hours of time as interruptions spread over several months.

Answer 16

One thing to remember: code is like grammar. People may know theirs suck but don't like to be told so. For example, if I pointed out that you repeatedly misspelled "judgment", you might be annoyed because I am not really adding anything constructive. Well I just did it anyway :)

But couple that with the fact that many seasoned programmers do tend to adopt a diva attitude. What you intend as sincere questions rooted in logic may be very threatening to them. I have worked with countless examples (and I may be one myself) who have been maintaining the same old crappy code that hasn't been relevant for 15 years. They know there's a better way to do it these days but they have no interest or motivation to learn new stuff, so your mere presence as the next generation is a threat to them. When they pull the prima donna act, just laugh it off to yourself and remember that you're the one with the real power -- you have many years ahead of you to work with the technology of the future and the ultimate direction your career takes is still in your hands. That's not usually the case for the seasoned snobs.

I concur with others who mentioned that this doesn't sound like a good incubator for aspiring developers. However, this is common. It takes time and experience to identify your niche, find an employer that is a good fit for you, and determine what matters most to you. So pay your dues there, take your lumps, plan your career and get out after you've put in a few years of solid work. For now just take the advice for what it's worth, don't worry about the PIP and keep reminding yourself your current situation is just a means to an end. Your supervisors expect you to clock in and out on time as if you worked at Wendy's. That's not how it has to be, even for inexperienced new developers, so there can be a much brighter future ahead elsewhere.