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?

Question

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?

Answer 1

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.

Answer 2

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!

Answer 3

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

Answer 4

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](http://www.javapractices.com/home/HomeAction.do#Common Practices).

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

Answer 5

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.

Answer 6

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 that other new people experience, given your level of experience.

Also, you've only been at your job for 3 weeks. Take your job seriously, but seriously, 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. Worse 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.

Answer 7

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.

Answer 8

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!

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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