I'm 3 weeks into my first job after graduating at a web development company.

I feel like I need help most of the time with the most trivial things and that I'm using up more of the other developers' time than it would take for them to fix it. The other developers seems to be getting tired of helping me out with these menial things and I feel I might not keep this job very long if I don't speed up.

Is this common? How can I deal with this overwhelming sense of inadequacy?

  • 18
    In the words of Joel Spolsky: "It’s harder to read code than to write it." Reading a large code base involves great intuition and it's difficult even for the experienced. Like anything else though, eventually you will become better at it.
    – Ken Li
    Commented Nov 15, 2012 at 2:30
  • 5
    It felt the same at my first job as a developer. A big reason for my problems (but not the only) was that the codebase was well beyond a disaster. I was also a little 'green' in my field, but the fact that the code was a big pile of stinking spaghetti php-sql-html with no classes and abuse of global variables obviously did not help at all. Commented Nov 15, 2012 at 9:23
  • 34
    I think that 6000+ line classes are a sign that the code is probably very poor quality anyway. Don't sweat it. Your first 2 months are the hardest but no company in their right mind will give up on a junior developer after only a few weeks. If you have been there for a year or more then I would be concerned but a few weeks is just normal "new job" anxiety. Commented Nov 15, 2012 at 12:32
  • 9
    Is it normal is not a constructive question. I think you could go on programmers and ask for help in how to deconstruct and understand the large code base... but that is a programmers question not a workplace question. Commented Nov 15, 2012 at 15:40
  • 2
    I've found that if a developer can come straight out of school and in their first couple months get enough work done to break even on the time they take from other people, then they will probably become a good developer. If the codebase is bad or just really complicated it might even be hard for a senior developer to break even right away.
    – psr
    Commented Nov 15, 2012 at 17:49

15 Answers 15


I think you should just be honest in your workplace when talking to the other developers. Being new and a junior you will get away with alot as well as be amazed how many questions you can ask. If you have good seniors and mentors they will advise you in the direction either to do a bit of research or help you in a peer programming type of way.

Most of the time that I'm coding, I feel like I need help with the most trivial of things and that I'm using up more of the other developer's time than it would take for them to fix it.

The developer you are talking to most likely would be able to fix it quicker than showing you how. In the short term..... the idea and benefit is that over time you will be able to do more and more yourself and so give back in spades what you may have taken up initially.

The other developers seems to be getting tired of helping me out with these menial things

Yep, they probably are. But that's only because they are under pressure to do their work as well. They will also recognize that they have been in this position once before as well as the fact that by helping you, they are also helping themselves given one day you might take over some of their workload.

Remember that your knowledge gap of the product and solution will be temporary. Everyone who first starts in new code bases drowns a little bit until they get their head around things.

I have this sinking feeling that I might not keep this job for very long if I don't speed up soon.

If you feel this way talk to your boss. Just ask them for a bit of feedback on how they think you are going. Is there anything they think you could brush up on or learn a bit more about. Be proactive and force the discussion with the boss. If it helps ease your mind life will be that much better.

Good luck and I hope your experience picks up soon.

  • Thanks a lot for your reply (and all the other replies!) One of my biggest problem is that while they do dedicate sometime helping me out, it's hard to communicate with them sometimes. My mentor always seems to be in a call and have very limited time to explain stuff with me. I haven't really asked for feedback either because I feel that I might be using up too much of their time. I know that's not the best way to go about it but I find the balance between asking for help and letting them be productive to be very fine line. Commented Nov 15, 2012 at 4:39
  • 8
    @infinityLoop If you feel your mentor is busy, make an appointment with him/her! Batch up a bunch of non-urgent questions, look through your mentor's calendar (if you have access to it) to find a few hours when he/she is free, and suggest that you meet up and discuss those things. That may help with time to give the bigger picture as well, rather than simply answering the exact question you are facing at each moment.
    – user
    Commented Nov 15, 2012 at 10:25
  • 1
    Like @MichaelKjörling suggested, batching up a few question rather than ask them immediately is usually a good strategy for several reasons. Writing them down forces you to be a bit more specific and also helps you find the information yourself since it will become easier to google/find in the codebase. It also gives you some time to ponder the questions subconsciously which can help a lot.
    – Leo
    Commented Nov 15, 2012 at 14:11
  • 9
    +1: For Everyone who first starts in new code bases drowns a little bit until they get their head around things.
    – Jim G.
    Commented Nov 15, 2012 at 17:59
  • 2
    if any developer who's been through more than a couple of jobs in his lifetime says he hasn't been in this exact situation, he is most likely lying. this is nothing out of the ordinary. just keep pushing and keep "bothering" your coworkers for help... shamelessly
    – amphibient
    Commented Aug 4, 2014 at 21:49

Pair Program

This is the best way I've found to get anyone up to speed with a code base and team workflow.

I typically encourage the new person to "drive" while the experienced person "navigates", at least initially. I assume you have a drivers license (if not, get one!); this is the same thing. You're learning how to keep the car on the road and obey the traffic laws at the same time. Your experienced friend/parent/instructor is there to correct you and make sure you don't get into any serious trouble.

Bond/Be Sociable

Your goal here is to find at least one person who wants to mentor you.

The best thing is to find a topic that you and at least one other developer have in common. Failing that, talk about kids (most parents will go on for ages about this), vacations, volunteering, tech news/gadgets.

Realize that for a lot of people work is a place to just earn money. Some people don't want to open up their personal lives, feel overworked, only want to do the bare minimum, or are just curmudgeons. Curmudgeons aside, most people will at least discuss their career path, lessons learned, etc.

You need some personal goals

Spend some time and come up with a short list of goals for work. Talk to the other developers about them and tweak them if they give you good input.

Git is a problem for you so maybe you should start there. Find the typical commands that your team uses and do up a cheat sheet. Or maybe it has to do with workflow.

Having a goal will let you measure your progress against something concrete and within your control. If you measure your goals and progress, then it gives you something to feel good about.

Think about your career, not your job

A lot of programmers only hold a certain job for a couple of years. There's a lot of reasons for this, however you should be constantly be preparing yourself for the next step.

Cultivate a diverse network of people who you can use as career mentors. Most successful people (not just programmers) love to help others with their career. The idiom "Success breeds success" is quite true from my experience, find as many of these people as you can.

Some social networks are tailored for workplace networking. Join one if you haven't.

Don't forget that in 5 years you might be asking some of the people you are working with now to give you references.

Have fun!

Work is stressful and everyone needs some way to de-stress.

You're tired, cranky, depressed when you go home, so find something fun to de-stress.

Volunteer (talk to first year students about your "unpreparedness"), do something active like yoga/run/paintball. Don't feel like you need to do computers 24/7.

Integrate fun into your work life if you can (are you a geek? put toys on your desk like the rest of us). Find out if your colleagues have a Frankenserver and join them.

You're joining a really great field at a really exciting time. Enjoy it!!!


Most university programs do a poor job of preparing you for real code bases. Yes, most of them are large, complicated, and messy. Many of the pieces of code were written before certain, newer easier ways of coding came into being. They may be ugly and hard to maintain but they work. It is a hard sell to change existing, debugged and working code to something that only the developers will notice as improved.

So what you are feeling is normal. What you do about it is totally under your control. First, when you leave work, leave it behind. Don't destroy your personal life due to work stress. I find that thinking a bit about what I want to do when I get home during my commute helps me refocus away from work and into the personal life.

Next, learn to take things in chunks. And as you start to understand the code, write up some notes in a document for the next new person to help her understand it. By taking proactive steps, you will reinforce your own learning and feel good because you are making it easier for the next person. You can even take these documents to your manager or a senior developer and have them look them over to make sure that your understanding is correct.

Eventually the workflow of new tools will seem less awkward. Part of it is just learning something new. In your field you will always be learning something new, so just accept that the initial awkwardness is part of the process and that it will go away as you feel more comfortable. We all feel a bit out of our comfort zone when faced with using a new tool. But the more experience you have in adapting to new ways of doing things, the easier it becomes and the more you know that you can adapt which gives you confidence.

Talk to your manager about how you are progressing and what you need to get better at and then improve your performance. The people who fail in the workplace are the ones who can't (or won't) learn from their mistakes and who refuse to listen when told they need to fix a behavior. People (especially junior people) who are trying to learn and asking for help will usually succeed.

Talk to your manager about priorities. There may be some things he wants you to get better at first. If he is a busy person, then set an appointment to talk. Remember it is part of his job to get you working at a professional level. If you fail, he has also failed.

It will get better. If the code base is bad, then that is a wonderful place to learn. If you can cope with a spaghetti mess, you can cope with most anything you will see at a better company. You can learn a lot from other people's mistakes in a place like that and you can learn what poor practices to avoid in your own development work.

Also remember, you are not stuck there forever. Spend a year and learn what you can and then move on to a better place. Use this job to learn how to navigate the workplace, how to deal with political issues, how to gain respect from your peers. The single worst action you can take is to run away too soon because it is hard. You are setting a pattern for your work life that will get more and more difficult to break the more times you repeat it. One of the best things you can take away from a job like this is to have learned to be persistent and keep on going when the going is tough. More people are successful through persistence than talent.

  • +1 to Most university programs do a poor job of preparing you for real code bases. Sad but true. And then they release so many naive programmers on an unforgiving world.
    – kolossus
    Commented Nov 16, 2012 at 5:19

Your experiences are normal. I don't think anyone learns 100% of what they will need to do their job in school, I know I didn't. School is all about theory and high level ideas; it's normal to feel a little overwhelmed when it's time for the rubber to hit the road and start coding. Hopefully you have good senior developers that will take you under their wings and show you the ropes. I graduated in 2006 and for the first couple of years I was in your shoes. I actually got hired to work on COBOL and I had never seen a line of COBOL in school; I didn't know much about it at all when I accepted the position. I made friends with senior developers and learned from them, eventually got to work on other things, and transitioned to another job working in Java and C# and I'm a lot more comfortable here.

Don't worry, relax, go into sponge mode and suck up all the info you can. In a couple years, if you don't like your position, look for something more interesting to you. Good luck!

  • I actually had a semester in legacy languages! COBOL was the biggest pain in the ass compared to FORTRAN and ADA. Thanks a lot for the advice! Commented Nov 15, 2012 at 4:43
  • 1
    @infinityLoop ADA definitely isn't a legacy language the way COBOL and (to some extent) Fortran are. Wikipedia (Particularly see the last paragraph.)
    – user
    Commented Nov 15, 2012 at 10:22
  • Let me guess... Now you think COBOL stinks? Commented Nov 15, 2012 at 15:24

Welcome to "The Business". I'll take a few of your concerns

  1. Reading other people's code: Writing code is a form of a social obligation in the software development business. At the back of a decent developer's mind is "Write this class like the next person that's going to read it is a homicidal maniac that has your home address". There's well written code and poorly written code. Start learning to discern between both so you don't needlessly take the blame or berate yourself unnecessarily for an organization's years of neglect and bad practice. See this article for a shortlist of good coding habits (and bad ones). You can start with this category.

  2. Learning new tools: GIYF. Google is your friend. Your first port of call for learning to do anything in this life (Yes, anything), should be all-knowing google. You're not that special in that you have a problem in a tool/project that has never been experienced before. Someone, somewhere has experienced that perfect storm of issues and has written about it. Seek out that forum/blog post and start helping yourself. I'm pretty sure that your colleague's exasperation stems mainly from this fact, things they'd expect you to hit google hard for, you're coming to them. You're only ever truly screwed with google when she only turns up a single page of results. Then you reach out to your mates.

  3. Learning in general: Divide and conquer. Try not to approach those megalithic classes/packages as they are, megalithic packages. Take them in in small, manageable chunks. You've been there only 3 weeks, so give yourself a small break. All you need to know for these few weeks is what you need to execute specific tasks/ functions "Oh, what handles authentication in this project", "What factory method creates the objects". Pinpoint programming is what I call it. Start with what you need for now. You'll grow to cover the bases eventually. Unless you're a Macarthur foundation alum, no one is going to expect you to have the codebase down pat in 3 weeks. Even when searching for solutions on the interweb, you don't go "JAX-WS API", you go "How to authenticate a JAX-WS". Poco a poco, you'll cover all the bases in the API

  4. Be honest with yourself: Identify quickly what areas are your true weaknesses with regard to the technology stack and devote extra time after work to becoming a power user of the tech. Myself as an example, there are APIs/frameworks that I consider myself a power user of, things I'm able to answer questions on in SO. Then there are those that I'm a casual user of either because I don't care enough to go deeper/I have no need to know more than I use or I simply can't get the hang of it. Be able to categorize your tech in order of your strength and with regard to your organization's needs. For your own empowerment and peace of mind. I find myself dealing with issues easier when I've admitted to myself, "This isn't my forte".

  • I agree with you, I've always been trained to exhaust my resources first before I turn for help. However most of the issue I'm having is that I don't think the code base is based on a standard framework or anything and it all seems to be really homebrew. Documentation is also pretty much non-existent so when I need to know how a function behaves, I can either bash my head against the wall and dig through the entire class stack or take the easy way and try to have someone explain it to me. Commented Nov 15, 2012 at 4:42
  • @infinityLoop, in that case, I'd take it up with your manager. If it's not going to be too much of a burden, have him semi-officially designate someone on the team as your resource person and have him on an instant messenger window. Schedule (30 min) sit-down sessions with this person where you'll go thru an itemised list of questions with him. This is a better approach IMHO than piecemeal distractions every couple of minutes. Until and after your sit-downs, you make do with what you have and shoot the occasional private message to the guy. Hell, the manager bit might not be necessary.
    – kolossus
    Commented Nov 15, 2012 at 4:49
  • normally I'd agree with you but it just so happens that I'm at a very small company with one project manager, four developers, a support team, and the owner. The lead dev is I guess, also my manager? I'm not sure what to do when he doesn't have time for me. Commented Nov 15, 2012 at 4:51
  • 1
    @infinityLoop If the lead is too busy with administrative tasks to mentor you, you should try and have one of the other developers do so. Depending on how well you've gotten to know them you could ask one of them directly; alternately ask your manager to do so. When you do so, explain that your manager's being too busy to give prompt assistance is a major bottleneck. In a team that small your coworkers should be aware of how busy the lead is with other stuff so it shouldn't be a problem. Commented Nov 15, 2012 at 13:43
  • 2
    Small companies often lack the infrastructure they need to make a smooth on-boarding experience for new hires due to a lack of experience with new employees and limited resources (mainly time). You can help create documentation to alleviate this pain for future hires - and in doing so, you will be reminding people that you are struggling to ramp up because of the situation, not because you yourself have a problem. You're a normal college grad. Small companies should know when they hire college grads that they will need to invest time into training them. Cheap labor comes with a price tag. Commented Nov 15, 2012 at 19:30

It is normal.

I had the same experience on my first programming job. It was hard, I was constantly asking questions, I constantly struggled with tasks assigned to me.

I quit after 4 months, as soon as I learned that all the stuff I was doing, was never actually used. Person in charge of me simply tried to demonstrate to upper management that he does a lot of hard work (by assigning crazy useless tasks to me).

It was very stressful experience, but in those 4 months I've learned more than in 3 years spent at school (actually I quit school as well and joined another company).

So here is my little advice to you:

For now it doesn't really matter if the company is bad. You just have to use this opportunity to learn how to do your job (there are many more scary things in software development, brace yourself). In some time (3 - 4 months) you will be able to judge how good (or screwed) your company is. And only then you can make a correct decision.

Don't be scared of getting fired. The only thing you can expect from recent graduate with zero work experience, is a lot of questions. Even for experienced developers it can take up to the few months before they can start doing some useful job.

Don't be scared of large complicated code bases. They are always large and scary.

Don't be scared to ask questions (but you have to try your best to solve questions on your own before asking someone else). Most of the developers still remember what is like to be a beginner, and they know that new guys always have a lot of questions.

  • Thanks for the reassurance. I just have some self doubt whether or not it's taking me some time to ramp up or if I'm just simply too dumb to do the job. I guess time will tell. Commented Nov 15, 2012 at 14:21

I am a developer with 7 years of experience. I switched technology stacks recently, from mostly .NET to mostly Open Source, and am also picking up Git and JIRA. I can assure you that they really are challenging to learn, especially when you have a new job and are learning lots of other things.

At Microsoft and many other companies, the new employee experience in software is referred to as "drinking from the firehose" - because there is just too much to learn, and you absolutely will be overwhelmed. Keep at it. Be empathetic about how you are disrupting people's normal workflows, apologize and try to use the least disruptive way to ask questions that time will permit (email or IM if you can, or visit people in person around lunchtime, when they get in, or when they leave so you don't disrupt them when they're in the middle of their workflow) - but don't stop asking questions and disrupting them. It's part of your job to learn, and you can't do that if you don't get help. Really.

Feeling like you aren't up to the job is normal for software developers. Many new devs experience something called "impostor syndrome" - the feeling that you are less competent than others and need to hide your incompetence. If you feel that way - fight it. You are competent (probably), you are just also new. This is normal. It's just a feeling.

Months 3 and 4 on a new software job tend to be the hardest, especially in terms of self-esteem, according to the charts Microsoft showed us during their new employee on-boarding process about five years ago. This is because of the frustration of feeling like you should be contributing while still being in the process of ramping up. Give it at least 6 months, and I'd recommend giving it a full year before you assume it's the job and move on to a new job. If you aren't happy after two years, you should definitely move on - that's more than long enough (at least in the software industry). I'd recommend giving your career at least 3 or 4 jobs before you switch careers.

There are a lot of great tips here in the highly rated responses. I just wanted to give some perspective to go along with that advice.

I am going to give one tip that I don't see here:

Record your experiences, especially the parts that are painful.
What information did you want that was hard to find? What training did you need, and what worked for you? What learning resources are you discovering? You can pass this information on to your manager and other new hires, build out the team's documentation, and maybe even offer the information to help HR improve their on-boarding process. Turn this painful experience into a career opportunity. This isn't necessary, but will probably earn you some big kudos if done gently. This is an opportunity you will have every time you start a new job - so watch for it in the future as well.

  • Good idea that last paragraph!
    – andy
    Commented Aug 18, 2016 at 7:32

Talk to your supervisor. Tell them what things are like, that you want it to get better, ask for feedback, and what you can do to improve things. Also, ask if this is an experience for other new people as well given your level of experience (and if so, then there may not be a problem).

Also, you've only been at your job for 3 weeks. Take your job seriously, but relax and ask for information. The stress sounds like it's mostly coming from not being sure how you're doing. Fix that by asking. Worst case is you'll find out you're tanking, but I guarantee you'll get some feedback that will point you in the right direction, even if this one job doesn't work out. Really, no matter what, you'll be in a better position: either you'll find out you're fine and you can focus more on the work than the stress, or you'll find out what you can do to improve.

The one thing that won't help is not asking and just going into work and stressing out about it.

  • The thing about finding out that you are tanking (in your worst case scenario) is that then you can do something about it before being fired. The ones who don't ask never really had a chance to fix the problems before being let go. SO really it is better to know you are tanking and work to fix it than not know you are tanking and get fired out of the blue.
    – HLGEM
    Commented Feb 20, 2013 at 15:50
  • Just of note, it's sometimes more complicated. Some companies have very high expectations and would say you're doing badly even though the situation doesn't allow much more. This is more likely with companies that hire students fresh out of school and expect them to be full-fledged pros.
    – leokhorn
    Commented Aug 5, 2014 at 11:30

An observation from someone who grew up in the trenches and got cajoled in to management.

First off the fact that you're feeling this way and taking steps (asking questions) to resolve the issue puts you heads and shoulders above the majority of recent graduates that I've hired. Way too many of them come in with little or no clue of the real world and simply can't or won't adapt.

As for asking questions in the work place, keep asking them! Most of the team, while sometimes being annoyed at an interruption understand where you're at right now. They've been there and done that.

But make sure you don't ask the same question multiple times. Ask meaningful questions. And take some initiative to answer the question yourself before you go to someone else.

Asking a question in a way that shows you've already put some effort in to it builds confidence in you and lets your team know that you're putting out some effort. It also shows that you're learning because over time your questions will reflect what you've learned as well as your thought process.

As for the codebase, well you just have to find the time to work through it and to build an understanding of the code, business process, and overall approach of the shop.

Keep your chin up!


From @HLGEM's answer:

Most university programs do a poor job of preparing you for real code bases.

This is true. What you're feeling is normal.

You need to change your approach to your assigned tasks. Here are some pointers:

  • Keep an organized notebook. Take diligent notes whenever a fellow programmer is teaching you the problem space or giving you coding pointers. Endeavor to never ask the same question twice.
  • To the best of your ability, break down your assigned tasks into even smaller tasks. Keep breaking them down until they're each small enough to be completed in one sitting. Document these steps on a separate page of your notebook, then order them in a way that makes sense to you. [Note: This strategy supports the Pomodoro Technique very nicely.]
  • Whenever you encounter a problem that you can't easily solve, try to identify its constituent parts. Can you break this problem down even further? Identity all outstanding questions and start Googling. If Googling for the answer doesn't help, prepare to ask a well-stated question on Stackoverflow.
  • As a final option, if you can't find answers on Google and Stackoverflow, prepare to ask a fellow coworker or your manager for help. Never take their help for granted. Take the time to research your problem to the best of your ability. Be prepared to summarize the steps that you've already taken to solve your problem. Be prepared to state your problem with very succinct language.

Finally, as @hafichuk said:

Bond/Be Sociable

  • Read Keith Ferrazzi's book 'Never Eat Alone'.
    • While the author does recommend hosting dinner parties and eating with others at lunch time, his advice extends far beyond social eating.
    • He implores the reader to be sociable, and describes how being sociable can yield a satisfying and prolific career in any line of business.
  • 1
    +1 for the notebook. Even better, capture it in a team wiki or other documentation, so other new team members don't have to ask either. Commented Nov 15, 2012 at 19:15

There are a lot of questions here from the specific (using Git Hub with ease) to the general (wrong career path).

I think you need to break down the issues, sounds as if you are overwhelmed because of the way you are looking at it.

The most important here is that you are in learning mode. It is expected that other developers will need to help you. However, there should be a balance between them helping steer you and you providing the motion as ambition and ability to learn. Get the books on the code base, find as much info as you can online, etc and study it good.

You definitely got to put in your time to get past the learning curve.

As long as you are truly doing your best, don't worry too much what other people think.

Also, you are cheaper labor, as a new hire, don't forget that.

  • Like the comment - don't worry too much what other people think. That is so true. Who cares what other experienced developers may think. Commented Apr 4, 2014 at 9:44

@Jim G. All of these guys are right on. Your frustration, self doubt, confusion, overwhelmed--all normal. Your first two months are pretty much a give-me. The questions on the minds of your manager and team mates are, does he know to ask questions, are they good questions, does he ask the same questions, and is he prepared for the answer?

I've worked with all kinds of personality types and skill levels. I learned the hard way, that you get the best a person has to offer when you appear confident; don't make excuses or apologize for your inexperience. A person worthy of mentoring will be constructive and instructive. Anyone who acts otherwise is not worthy of being a mentor and you should simply not use them as a resource.

Finally, before asking, look into it yourself for about 15 minutes--pay your dues, you will learn much faster and it will stick. Make sure you understand the problem or confusion, be prepared to answer any assessment questions they might have for you, and then compose a concrete question. Write it down, bring any supporting information--error message, etc.--and be sure to write down their answer. If not for yourself, to demonstrate respect for their time and hard earned skills.

Do this and you will be pretty independent and up to speed in less than six months. Good luck.


In addition to the other answers, I would suggest you do the following:

  1. organize your questions so that you can ask multiple related questions at the same time, and do it in a "session" rather than multiple interruptions

  2. set aside a time for 1-on-1's or learning sessions where it's scheduled, such that you are not interrupting the work of other developers

  3. document your findings such that if another new developer were to join, you could share your learning with them and bring them up to speed quickly


I think we've all been in your situation before.

First rest assured that being a new developer is a difficult position and that by the sound of their code base, they had made it harder for you than it needed to be. On the positive side, you will be seen as a competent developer faster than otherwise if you stick with this place for a few years simply due to their incompetence.

You need to do a few things. First, learn git in your own time outside of work. You can learn how it actually works on your home machine and go beyond the basics of the shell commands. Read about and learn the underlying mechanics, than try it out locally. It is absolutely important to get this right because some developers will pick on it before they pick on your code. If you can get this right, you're 50% of the way there.

Now when it comes to the code I suggest when you get home you write down in a notebook how the part of the system you worked with that day works, pros and cons of the approach and how you would of done it. Soon you will map the whole system and have a good set of notes to guide yourself around. This is more useful than just working with it because by writing down thoughts you give yourself the opportunity for insight.

If there is the option to refactor as you go, perhaps check with your lead first and then do light refactoring in separate commits to your bug fixes/features. Only do this if there is decent test coverage and to begin with just stick to things like style guides, factoring out multiple responsiblity methods into single responsibilities etc. Always get refactoring reviewed by a senior developer and don't do it on work someone else is working on otherwise the merge may aggravate them.

Also just try to ask questions less often if people are getting tired. Maybe try writing tests if you're not sure on how something behaves or just having a quick experiment. There isn't a world of difference you can make on this front, if they're not great people then being a junior is always going to be painful even if you're a good ju.

The best piece of advice in this thread was in another post, be friendly and convince someone to want to mentor you.


Fortunately for you, everyone feels like this at their first job. Don't be afraid to ask questions or get help - it's much better to learn something right the first time.

As far as git goes, you should check out the free course for git at codeschool.com: https://www.codeschool.com/learn/git

Also, tons of people say that they know git but if you get 5 of them in a room together you might get 5 different answers on how to do something. That's why we use 'git blame' :D

  • 1
    this doesn't seem to offer anything substantial over points made and explained in prior 14 answers
    – gnat
    Commented Aug 16, 2016 at 14:34

You must log in to answer this question.

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