Ask HN: Overwhelmed with new job. Feeling totally stuck.

Been there... It's a terrible feeling.

A couple of vectors to approach the situation:

- Start top down. Understand what the entire system or product is supposed to do at the macro level. Understand the main architectural components, what the role of each is and how they interact with each other and users or the outside world. Once you can understand the big picture, the individual lines of code have a context that helps understand their purpose and how they perform it.

- Discuss with your lead engineer what his expectations are for your progress. Very senior people I have talked to will claim that it takes 6 months - 1 year before a new hire can really start to contribute. Longer if it is a legacy system as you are facing. Something like, 'Once I am up to speed, what kind of tasks or projects will you expect me to take on? Can you give a few specific examples (maybe things that actually are on the list today) and give a time line for how long you'd expect it to take me to get them done? This can be a bit dicey depending on the style of the manager, but it's good to learn their style in addition to their expectations of your performance.

You're doing great! Many of the commenters here are saying this is normal and you shouldn't be worried. They're right. Relax. You're asking questions and learning... don't worry about not learning fast enough. No matter how quickly you learn, it will never be "fast enough"!

Here's some advice which may help. Focus on smaller problems. If you need to solve a problem with an internal tool with poor docs, tell yourself you're not going to solve the problem right now. Right now, you're just going to improve the docs. So dive into the tool and focus on one method at a time. Read the source, the tests (if they exist), and update the docs with the knowledge you gain. Stay focused on each individual aspect of the tool until you're an expert on it before moving on.

This way you'll be in a position of ever-expanding authority, you'll inevitably arrive in a position where you can solve the original problem easily using the internal tool, and you'll have created some docs which will be useful to other people on the team!

Many times I've relied on new hires, and even specifically asked them to, for improving the documentation and/or onboarding guides. Once someone has been in the team for a few months, they'll picked up "tribal knowledge" and they'll mentally fill in the blanks in any documentation (or obscure code). Those few initial weeks of someone with fresh eyes are precious for that.

This is absolutely the way to go. Another great feature of getting a new hire on your time is that the goals of your team were already allocated with the old bucket of developer hours. Because the new hire was not planned for, they are relatively free to work on any of the nice to have but not critical parts of the codebase.

We always have new developers start by writing unit tests and documentation for the most used components of our codebase as determined by profiling. This way we are always improving our most important code, and at the same time teaching the largest percentage of our code to the new dev at the same time. With core components that are used everywhere, the new dev can literally ask anyone else on the team for help. This can help the new dev by allowing him/her to spread out what he/she thinks are dumb questions without feeling as embarrassed. Then by the time the next planning session has accounted for the larger bucket of dev capability, we have some great bugfixes, and the new dev is more confident and ready to specialize more.

I think this is all normal. Any big company that's been around for a while has a lot of internal infrastructure that's poorly documented. Often, in the first few months of a new job, when I go to a meeting, not only can't I contribute anything, I don't even know what the words mean.

Perhaps you can befriend someone else who started around the same time and talk to them, I bet they're feeling something similar.

Anyway, I do think what you're being too hard on yourself. You're probably developing meta-knowledge: you may not know the details of the code & tools, but you're learning the underlying concepts and who to talk to about what.

You should also be able to ask your manager for feedback on how you've been coming up to speed, or ask what's typical for people new to the job.

Three to 6 months is often stated as a ramp up time, so I wouldn't be too worried about your 2nd month.

Also, there will be a lot of code & tools you never learn well. That's ok, its not about the stuff you don't know, it's about the stuff you do know.

Solving bugs is not glamorous, but it does help with learning a code base and it gives you goals to hit and will make you feel like you are contributing.

I find that the more that you plan to do with knowledge, the easier it is to learn it (and then be able to do something with it). The simplest thing is taking notes to help pay attention in class (which you are doing). But you can work from that basic principle in other ways. For instance, you can say "let me see if I understand this right" and explain back the information. You could also make it a point to always make some kind of guess, even if it is obviously a wrong one. Finally, you may want to find people who like to talk and ask them various questions. Some engineers are impatient and do not like explaining things a second time, but others are not like that. You may be able to find what you need to know in indirect ways.

There is a lot you can do and you sound like a conscientious person, so if you make a healthy and consistent effort, then you should be fine in the long run.

You are just in the second month, this is totally normal. Till the 4rth month I couldn't understand when my colleagues asked me things and felt pretty stupid. Tree months and a few projects later the dust settles and the pieces bond together. Just stay hungry to learn. Nobody expects you to do anything that fast especially as an entry level, so take advantage of this time to learn as much as possible. Monitor others and teach yourself on being clear when asking questions or directions. Master this art, trust me, helps like hell. Also try to understand even the basic office politics, where your responsibilities start and end. It's an exciting world and getting started from a big firm is considered a "blessing". Try to think of it as "being paid to learn". Won't get much chances for that, believe me.

Having just gone through what you're feeling, I can tell you that it's totally fine. It takes time to ramp up in any company. Working with a code base with the sort of complexities you're going to encounter just adds to the time/effort it'll take (and to the stress). Just keep slogging through and getting to know how everything is connected.

Also, do you have any regular feedback loop with your immediate supervisor/manager? Having a regular one-on-one can be a great way to get some perspective on how they think you're doing. You're probably being sort of impatient with yourself and are doing fine :)

Get used to using 'grep' or 'ack' to dig through a codebase to find things. For example, if your task is, "Add a new button 'Find Vendors' next to the 'Find Clients' button on the Company Search report", I would:

1. grep for the string 'Find Clients' to find the UI

2. Note the URL that it hits when you click it

3. grep for a unique fragment of that URL to find where the routes are stored. Make sure you grep for something 'static', so if the url is '/search/query.html?action=search_clients' you could grep for 'query.html'.

4. The route should map to some code that implements it. grep for the controller or whatever else you find in the routes.

5. Once you've found the controller, something there should retrieve a list of clients. Find out how it's hitting the database.

Then you should know enough to tack on a new button in the UI and modify the controller to hit the database in a different way. Something as simple as 'grep' I never used in college or high school, but use all the time having needed it on the job for the past couple years.

IDEs really are much better at this than grep or ack. My experience has always need something that can perform symbol resolution, and something more powerful than grep or ack wins here. You may be ack-guru and and do that on the fly, but the rest of us mortals are not willing to put in the effort when some other dev has given us a command line tool, an editor plugin, or an IDE to do that for us. Its all about how much time you want to spend feeling cool and how much time you want to spend getting things done.

This is more or less how I felt when I started my first job out of school. I assure you it does get better with time: 3-6 months is probably a conservative estimate for when you will feel "up to speed".

What really helped me at first was having another engineer I could latch onto and do a lot of pair programming (sometimes just watching over his shoulder). If you are on a project all by yourself where nobody else knows the system either, that's a lot tougher to do.

> I don't have a mentor assigned to me, but I do work closely with the lead engineer to ramp up.

Congratulations, you've just found your virtual mentors here on HN!

Now-- go find your own local, real-life mentors. Seek out senior engineers, grab some coffee, share a meal together, ask for their specific advice. Pro-Tip: make a friend, don't ask 'will you be my mentor'.

Ideally, you'll want 3-5 go-to-guys with whom you can share ideas, compare notes, and get solid feedback. Think of it as building your own personal brain trust. The onus is on you to make this happen.

It usually takes from 3 to 6 months to know where are the parts of the system that you are using, and also if this is an old codebase maybe longer, your boss knows this, relax, keep learning!

I think your questioning if that's the type of direction you want to take in your career. Anything can be learnt in time but ask yourself this before you do. Will you be happy working on a 20 year old codebase likely using old tech and processes? If you commit years of time like this and choose to leave, will your experience gained be of benefit? If not consider walking away.

That's basically standard. Give it 6 months.

It's usually a bad sign when teams pawn off their maintenance work on new people. It means that they have no intention of actually fixing the system (or replacing it) because it's easier to just keep rolling the shit downhill.

If it doesn't feel better in a couple months, definitely consider quitting. You'd probably be happier on almost any other team.

Edit: downvoted by people who pawn off their crapwork on the newbies :P

I usually assign simple, low priority maintenance task to new team members so they can start to learn the codebase, the tools and the process.

Once they get those first few simple issues done, they're quickly assigned increasingly more complex issues.

Whatever helps them get acclimated is fine. The problem is taking projects no one wants to do and forcing the new person to do it without help.