32

I joined a new company 1 month ago. This company has code which spans over 19 long years. It's a big company and the code is great without a doubt.

But when I am told to work on a task to do, say, XYZ, I have to dig deeper and deeper in an ABC file which is always more than 7000 lines. (The whole project code spans over 2,00,000+ lines.) And inside that ABC file there are lots of calling to outside methods which are in another file, say, HIJ.

So sometimes as I am new and it's a huge learning curve, I feel low. I mean it. It really makes me sad and reduces my working ability to ace as I used to in my previous organization which always had medium service-based projects (current company is a product-based one).

Improve this question
10
  • 17
    @PratikCJoshi Now this might not necessarily apply to where you work (you didn't specify location), but in the United States, depression is an actual psychiatric disease. I doubt looking at code is causing you serious mental distress and if it is, please seek medical help or a career counselor.
    – The Unknown Dev
    Dec 6, 2015 at 18:50
  • 8
    "Depression" seems to be the wrong word here. Would you be open to find a more accurate word? The advice to someone who is really depressed is different to the advice you have chosen as the correct answer. If we could change the question wording to match what you really feel and think, it would make the question better and more useful in future.
    – Neil Slater
    Dec 6, 2015 at 20:10
  • 2
    Give yourself 6 months in a new job to get up to speed. Don't be so hard on yourself. Possibly this is a failing in the new-hire process, not enough on-boarding process.
    – Criggie
    Dec 6, 2015 at 21:14
  • 5
    Rather than "depressed" maybe you want to say "frustrated" or "self-doubt" or "overwhelmed". I open the source file, see it is 7000 lines long, and everywhere I look, there is a reference to some other file somewhere else that is usually just as long. I feel it deflates my motivation, makes me frustrated, etc.
    – Brandin
    Dec 7, 2015 at 6:55
  • 4
    If you are in fact depressed, it may be that you need a clinical solution/support. For the technical solution to this see also this thread - programmers.stackexchange.com/questions/6395/…
    – Brandin
    Dec 7, 2015 at 13:59

6 Answers 6

Reset to default
46

This amount of LOC is common. I've seen much bigger (a big French bank: 173,000 COBOL programs in 2002, must be far more today, not counting new techs). Don't depress, it's part of your job to dig in, and soon you're gonna like it. In the meantime:

  1. Ask those who know. And if you don't know who knows, ask "do you know who could know?". Befriend older people, they usually know much more than they seem to.

  2. Ask for technical documentation. It's clearly not something I'd bet upon, but sometimes, you can find gems. In 2011, my back has been saved by 120 pages of emails printed in 1995. The only doc, but sooooo useful.

  3. Get used to the local style. If you are lucky, you'll soon find that many programs have similar underlying premises & philosophy, which is a great help navigating monster code bases.

  4. If nothing works, ask for more time from your boss, and don't forget to tell him everything you've done to understand. You should not be seen as a whiner, but as a professional facing a mountain bigger than he's used to.

  5. At the end, you'll see yourself as a treasure hunter. Lots of dirt to dig in, but with the occasional, unexpected finding of a true gem.

Improve this answer
6
  • Look at glasher829's answer and my comment: :). "Then you could tell me to do meditation, listen to calm music, watch funny music :) . Losing attitude is NOT in my veins! :)"
    – user18840
    Dec 6, 2015 at 16:58
  • 14
    "watch funny music" OP I think you have unrealistic expectations of the world in which you live.
    – Lightness Races in Orbit
    Dec 6, 2015 at 18:19
  • 1
    @muru : thank for the edit. I'll try to be cleaner next time.
    – gazzz0x2z
    Dec 6, 2015 at 21:43
  • 3
    Point #1 certainly deserves to be #1, imho. Even if there is good documentation (there probably isn't), first port of call should be talking to the veterans, because even getting pointed to the right place to start in the docs will be a massive timesaver! Note that if your workplace has a culture of not wanting the new guys to "waste" the veterans' time getting this assistance, that would be a very bad sign.
    – Carson63000
    Dec 6, 2015 at 23:06
  • 1
    Yes point one is good but you should do more than ask. You should have them show you. Pair programming is the fastest kind of programming. Slide the keyboard back and forth. Keep toys on your desk to entertain people who stop by to help while you pound through a problem (The Intern movie be damned). Trust me. The toys make you more productive. After that be willing to help others. Programming is not for one guy working alone in a dark corner.
    – candied_orange
    Dec 7, 2015 at 4:55
14

If this is really depressing you: Depression is an illness. If you are suffering from depression, then you need to seek medical help. If rummaging around in a 19 year old code base depresses you, then you should look for another profession.

I will assume that you are using the word "depressing" wrong. That it just upsets you that you make slow progress. That low code quality annoys you. And so on. One thing that helps is making sure that you are on your own and swearing loudly at the code :-) Seriously, that will make many people feel better.

"Code is great without doubt" - if I had to dig into a 19 year old codebase, I would have no doubt that I would encounter some of the worst programming imaginable. Including several half-arsed attempts to improve the code base that all failed :-)

There are two ways to handle this, which you have to agree upon with your manager: Either you make the least amount of changes to the code, only adding correct documentation as you go through it. Or you agree with your manager, that any piece of code that you have to modify anyway will be modernised as you go. That should only be done by someone who is truly competent, so don't try this unless you are.

Improve this answer
5
  • 17
    Ok, so we have a youngster here. Doesn't understand how this stuff works. To the original poster, this answer has a very valid and appropriate suggestion. Fixing bugs and making changes to mature large codebases is always an exercise in spelunking, dead-ends, primrose paths, secret doors, etc. If you expected the answers to your tasks to just jump up and wave at you after a few minutes of poking through code, then truly, you misunderstand what working for a big company means. Think of your task as being like a mystery novel. You have to go through to the end to find out "whodunit."
    – dwoz
    Dec 6, 2015 at 18:10
  • 4
    The question is usually not "whodunit" but "what were they thinking" :-)
    – gnasher729
    Dec 6, 2015 at 21:54
  • 1
    true, dat. However, it's also usually true that whatever they did in the code that you find odious, AT THE TIME it seemed like a logical and appropriate solution to the point-in-time particular swirl of requirements and constraints.
    – dwoz
    Dec 6, 2015 at 22:06
  • "Code is great without doubt", what does that mean?
    – Omar and Lorraine
    Jul 4, 2019 at 8:01
  • Look for another profession? More look for another job at a professional company.
    – dan-klasson
    Jul 5, 2019 at 8:44
7

I treat such code bases as though I am an anthropology professor out in the field. Remember that, even buried under millions of lines of code, there's a human element to the puzzle. Each fragment of the code made sense to one developer at some point in time. Making sense of how a few dozen developers thinks can often be easier than trying to make sense of a few thousand functions.

Once you start to understand how the previous developers were thinking, you'll learn the paths of least resistance for the code. Then the daunting feeling will start to disappear.

Improve this answer
2
  • 1
    I like your point of view. But how about a code patched by serveral coders over time?. Things start to become blurry.
    – rpax
    Dec 7, 2015 at 6:01
  • 1
    well, that's archeology. Software archeology. Was my job for several years. It's standard in most big shops. And even in several smaller ones. Takes time to get used to it.
    – gazzz0x2z
    Dec 7, 2015 at 11:23
6

Sounds like you jumped headfirst into a mess, but that's fine, you can get through that.

How do I overcome the Depression,anxiety and perform my best? Thanks.

One method is to view it as a job, don't get passionate about it, don't allow yourself to get frustrated. Just wade through it commenting as you go. Try and see if there is any documentation that might be helpful, or if the last person doing this job is still around, ask if you can have some of their time allocated to help you get started. But at the end of the day, the key point is not to allow frustration to seep into your mindset. It's only work. You can only get depressed and anxious if you allow yourself to be.

Don't push yourself to work at your best, this sort of task is for plodding through carefully and methodically. So don't stress on it.

Improve this answer
5

I've been in your situation enough times to recognise a pattern in my behaviour when dealing with new code:

  1. The ignorance is bliss stage. I don't know enough to realise I'm out-of-my-depth.
  2. The enormous pit is approaching stage. There's a problem but I don't know what it is yet.
  3. The OMFG, I don't know anything, I'll never understand this application stage. This is where you are. It's a horrible feeling.
  4. The climbing the mountain stage. Nothing but hard work can get you through this bit.
  5. The euphoria and amazing view from the mountain top stage. Everything from here is plain sailing.

These days I just accept stage 3 as a necessary terror I subject myself to. There's no secret except believing in your own abilities and intelligence and the knowledge it will pass. Get to stage 4 as best you can -- whether that's looking at diffs from old bug fixes or new check-ins, whatever it is identify how you can help yourself learn the product. Pick the easiest looking bug off the queue. Look at all the configuration settings, understand how the app fits in with your eco system. Step through with a debugger.

You've faced this kind of terror before during your education many times. You got through it by being capable.

It's corny, but believe in yourself and you'll be fine.

Improve this answer
3

I have two pieces of advice, one practical and one related to emotions.

Practical: The trick to working with big piles of code is to find strategies to minimize what you need to look at to do a given task. That may include finding documentation, talking to the oldest inhabitant to get the tribal lore, and running tests. In general, you should try to put a fence around a relatively small piece, and only find out how the rest of the program interacts with that piece. Sometimes, your ignorance of the rest of the program will come back to bite you, but that is life.

Emotional: Many years ago, I went through a few months when normal problems seemed overwhelming. Knowing the work could not be completed on schedule really troubled me emotionally. I was already an experienced project leader, so I knew intellectually that too much work, too few people, and too little time was business as usual, and I was just going to have to prioritize and get the most important stuff done. In my case, I went back to normal in a few months, but if it had persisted I would have sought medical advice. If your emotions do not improve as you get more confident, consider doing so.

Improve this answer