# I'm a new developer in a new position and I'm overwhelmed by the position. How do I ease into the position or do I just change jobs?

I'm a fresh out of school Comp Sci Grad landing his first job at a web development company. I thought I knew my stuff coming out of school but am I ever wrong!

Coming from an SVN background Git seems to be so much more feature intensive and confusing. And the workflow of Jira gives me a headache as well.

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 code base consists of these large multi class 6000+ lines monsters and I have a real hard time figuring out what goes where without much guidance. The other developers seems to be getting tired of helping me out with these menial things and I have this sinking feeling that I might not keep this job for very long if I don't speed up soon.

I've been here for 3 weeks and most of the time I come home tired and frustrated. I currently live with my parents and don't talk much at home because of how tired I am and I can't really think of anything to talk about and my parents thinks that I'm mad at them or something and gets frustrated with me.

I don't really want to spill my life story on here but I'm just wondering if this is common. The main restriction I'm hitting at work seems to be that I just can't figure out the damn code base. I have yet to look up any examples on stack overflow (and I did that quite a bit academically...) because none seem to apply to the work I'm doing.

How would you recommend I begin to deal with this overwhelming sense of inadequacy or do I move on to another job? Possibly in another field?

-
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 Nov 15 '12 at 2:30
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. –  Carlos Campderrós Nov 15 '12 at 9:23
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. –  maple_shaft Nov 15 '12 at 12:32
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. –  ReallyTiredOfThisGame Nov 15 '12 at 15:40
You've got a boss, they're there to make sure you have what you need to be productive. Your productivity is just as much their job as it is yours. –  Jesse Nov 15 '12 at 18:12

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 your 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 recognise 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.

-
@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. –  Michael Kjörling Nov 15 '12 at 10:25
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 Nov 15 '12 at 14:11
+1: For Everyone who first starts in new code bases drowns a little bit until they get their head around things. –  Jim G. Nov 15 '12 at 17:59

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!

-
@infinityLoop ADA definitely isn't a legacy language the way COBOL and (to some extent) Fortran are. Wikipedia (Particularly see the last paragraph.) –  Michael Kjörling Nov 15 '12 at 10:22

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

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

-
Hello @hafichuk! Welcome to The Workplace. –  enderland Nov 15 '12 at 20:13

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

-
@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. –  Dan Neely Nov 15 '12 at 13:43
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. –  Ethel Evans Nov 15 '12 at 19:30

Most university programs do a poor job of preparing you for real code bases. Yes most of them are large and 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 only the developers will notice as improved.

So what you are feeling is not abnormal. What you do about it, it 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 to do this, you will reinforce your own learning and feel good becasue you are making it easier for the next person. You can even take these docs 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 intial 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 them ore 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 alot 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 here 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 of 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 diffiuclt 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 is tough. More people are successful through persistence than talent.

-

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.

-

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.

-

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.

-

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.

-

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

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

• 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 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. –  Ethel Evans Nov 15 '12 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.

-

@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

-