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?
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.
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.
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.
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.
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.
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!
Welcome to "The Business". I'll take a few of your concerns
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.
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.
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
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".
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.
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.
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.
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:
Finally, as @hafichuk said:
Bond/Be Sociable
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:
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
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
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
