What is the norm for introducing new hires to a code base?

Question

After college I worked at one company for 6 months, and I've just now joined another one, bringing the grand total in my career so far to two.

So the first company had a few hundred thousand lines of code, maybe, across a couple hundred files. There was absolutely no introduction to where to start learning the organization of the code base...just, "Here, go find the source of this bug."

It was horrifically intimidating. I did slowly start to find my way around the front end, but 6 months in I was only just starting to be introduced to the server-side code. I was really happy to leave the company...I was relatively terrified of trying to find my way around the back end, which was by far the larger part of the code.

(I'm a front end developer whose work occasionally requires me to make minor modifications to the back end.)

But this new company...it's a big one, focused around a website...think Amazon. 2000 employees. I would estimate millions of lines of code but there's no way for me to know for sure. One of my coworkers showed me a 3-dimensional graph of the file dependencies...I almost fainted. It looked like this:

The coworker was chuckling fondly as he rotated it and zoomed around.

Yet again, there is no guide, no introduction, just....here you go, get coding.

I am horrified and very stressed. The job seems great in every way besides this, and I am quickly starting to worry that I am not competent as I seem to be the only person who finds this intimidating.

What are other people's experience with this scenario? Is it just me? What have you done in the past? How long does it take you to get a firm grasp on things? I have asked my coworkers this question and they said "a couple weeks." A couple weeks to learn a thousand plus files, hundreds or thousands of lines long each? Am I incompetent? Just say it.

Answer 1

For the most part, your experience is what I know as "the norm".

Very often one of your first tasks will be "Go find and fix this bug" and you'll struggle finding your way throughout the source tree (ideally starting at the source code search tool) to search the codebase for the particular error text or something related.

If you have a kind or competent lead then you'll get another bug, or feature, or some work item somewhat related to the last one. The next will also be somewhat related to the other two, and so on as time passes by. One day, someone will reveal to you that they don't have the foggiest idea what the area of code you've been working in does and you'll realize that you are the expert for the particular feature sets that you've been bug fixing for the past n months.

Eventually, you'll get assigned something completely different, and it starts all over again.

The codebase for the product I work on is in the realm of millions of lines of code... I don't know what most of it does - but I generally don't have to.

Answer 2

Other folks have already written some good answers, so I'll just mention them in summary:

1. DON'T PANIC! This happens to everyone. :)
2. Ask questions! You aren't expected to understand the entire codebase. It generally isn't humanly possible anyway.

I'll add to those that reading code is a critical skill that you're developing right now. It's rarely approached in a significant way in a classroom environment for practical reasons, so we've all gone through what you are. It's frustrating at the front end, as learning usually is, but you'll get the hang of it through practice and experience.

Good luck, and don't forget to have fun! :)

Answer 3

"I have asked my coworkers this question and they said "a couple weeks." A COUPLE WEEKS TO LEARN A THOUSAND PLUS FILES, HUNDREDS OR THOUSANDS OF LINES LONG EACH???"

You are panicking and your panic is making you irrational. Slow down, and take a few deep breaths.

Nobody "learns" a large code base in a matter of weeks. In a very large project nobody ever "learns" the whole code base. You learn parts, you specialize, you forget, and you relearn. You use documentation, specs, comments, and software tools to find your way around. Know your tools: IDE, editor, debugger, build system, VCS, and command line tools like grep.

Being given a bug to fix is a typical learning exercise for a new hire. If they have any sense it will not be a complex bug that touches a lot of code. Treat everything not directly related to that bug as a black box until you are absolutely forced to delve more deeply into it. Learn just enough to fix that problem, and then go get another problem. Do this a few hundred times and you'll begin to understand how the project is organized.

Answer 4

It is not uncommon. At my current job, I was asked to look at the current codebase (~200 dlls, ~500 kloc) and at the end of week 3, present to the boss, architects and team leads the top 10 things wrong with it.

The key thing to remember is that you're new. New people have questions. Ask questions. that will help you get your bearings about where (generally) things live. Once you know generally where things live, and (generally) how things work, then you can dig in to learn enough to do what you need. That investigation is the key skill which will determine your competency.

Few people can learn large codebases in depth, but you should learn the big parts and who to ask when you inevitably run into roadblocks. And with experience, you'll ask less and less because the new code will look eerily like codebases you have worked with in the past.

Answer 5

The best way to tackle this codebase is to not tackle it. That is, forget about understanding it whole. Instead, pick a well-defined goal that is small in scope and implement it.

It could be a small new feature, a bug fix, or increasing test coverage of a class or component that already has some tests but could use some more coverage.

Basically, you need to just jump in and do something well-defined and useful.

Answer 6

Encapsulation is a wonderful thing.

It means that you're not going to be looking at that entire object graph when you make a change. You're only going to be looking at a handful of classes, and those classes will be wrapped in unit tests with a very high level of code coverage, so that refactoring a class won't break its basic functionality. You've got clear, testable requirements, right?

Now, excuse me while I go home to my rolling fields, free-flowing chocolate, and dancing unicorns.