How to overcome depression while digging in HUGE code? [closed]

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
31
down vote

favorite

8

Frankly speaking, I have joined a new company 1 month ago. The company has code which spans over 19 long years. Its a big company and code is great without doubt.

But when I am told to work on task to do say XYZ, I had to dig deeper and deeper in 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 other file say HIJ.

So sometimes as I am new and it's a huge learning curve, I get depressed. I mean it. No need to say it makes me sad, reduces my working ability to ace as I used to in previous organization which always had medium service based projects (Current is product based company).

How do I overcome depression,anxiety and perform my best?

new-job productivity stress

share|improve this question

edited Dec 6 '15 at 15:48

Llopis

1441415

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

closed as off-topic by Dawny33, gnat, user9158, Lilienthal♦, The Wandering Dev Manager Dec 7 '15 at 6:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Dawny33, gnat, Community, Lilienthal, The Wandering Dev Manager

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  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.
  – Kimberly W
  Dec 6 '15 at 18:50
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  "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 '15 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 '15 at 21:14
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 6:55
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 13:59
  
  

  
  
  
  

 | 
show 4 more comments

up vote
31
down vote

favorite

8

Frankly speaking, I have joined a new company 1 month ago. The company has code which spans over 19 long years. Its a big company and code is great without doubt.

But when I am told to work on task to do say XYZ, I had to dig deeper and deeper in 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 other file say HIJ.

So sometimes as I am new and it's a huge learning curve, I get depressed. I mean it. No need to say it makes me sad, reduces my working ability to ace as I used to in previous organization which always had medium service based projects (Current is product based company).

How do I overcome depression,anxiety and perform my best?

new-job productivity stress

share|improve this question

edited Dec 6 '15 at 15:48

Llopis

1441415

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

closed as off-topic by Dawny33, gnat, user9158, Lilienthal♦, The Wandering Dev Manager Dec 7 '15 at 6:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Dawny33, gnat, Community, Lilienthal, The Wandering Dev Manager

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  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.
  – Kimberly W
  Dec 6 '15 at 18:50
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  "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 '15 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 '15 at 21:14
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 6:55
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 13:59
  
  

  
  
  
  

 | 
show 4 more comments

up vote
31
down vote

favorite

8

up vote
31
down vote

favorite

8

8

Frankly speaking, I have joined a new company 1 month ago. The company has code which spans over 19 long years. Its a big company and code is great without doubt.

But when I am told to work on task to do say XYZ, I had to dig deeper and deeper in 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 other file say HIJ.

So sometimes as I am new and it's a huge learning curve, I get depressed. I mean it. No need to say it makes me sad, reduces my working ability to ace as I used to in previous organization which always had medium service based projects (Current is product based company).

How do I overcome depression,anxiety and perform my best?

new-job productivity stress

share|improve this question

edited Dec 6 '15 at 15:48

Llopis

1441415

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

Frankly speaking, I have joined a new company 1 month ago. The company has code which spans over 19 long years. Its a big company and code is great without doubt.

But when I am told to work on task to do say XYZ, I had to dig deeper and deeper in 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 other file say HIJ.

So sometimes as I am new and it's a huge learning curve, I get depressed. I mean it. No need to say it makes me sad, reduces my working ability to ace as I used to in previous organization which always had medium service based projects (Current is product based company).

How do I overcome depression,anxiety and perform my best?

new-job productivity stress

share|improve this question

edited Dec 6 '15 at 15:48

Llopis

1441415

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

share|improve this question

share|improve this question

edited Dec 6 '15 at 15:48

Llopis

1441415

edited Dec 6 '15 at 15:48

Llopis

1441415

edited Dec 6 '15 at 15:48

Llopis

1441415

1441415

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

asked Dec 6 '15 at 11:09

Pratik C Joshi

285511

285511

closed as off-topic by Dawny33, gnat, user9158, Lilienthal♦, The Wandering Dev Manager Dec 7 '15 at 6:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Dawny33, gnat, Community, Lilienthal, The Wandering Dev Manager

If this question can be reworded to fit the rules in the help center, please edit the question.

closed as off-topic by Dawny33, gnat, user9158, Lilienthal♦, The Wandering Dev Manager Dec 7 '15 at 6:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Dawny33, gnat, Community, Lilienthal, The Wandering Dev Manager

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  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.
  – Kimberly W
  Dec 6 '15 at 18:50
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  "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 '15 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 '15 at 21:14
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 6:55
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 13:59
  
  

  
  
  
  

 | 
show 4 more comments

• 
  
  
  

  
  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.
  – Kimberly W
  Dec 6 '15 at 18:50
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  "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 '15 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 '15 at 21:14
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 6:55
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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 '15 at 13:59
  
  

  
  
  
  

17

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.
– Kimberly W
Dec 6 '15 at 18:50

@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.
– Kimberly W
Dec 6 '15 at 18:50

7

7

"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 '15 at 20:10

"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 '15 at 20:10

2

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 '15 at 21:14

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 '15 at 21:14

3

3

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 '15 at 6:55

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 '15 at 6:55

3

3

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 '15 at 13:59

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 '15 at 13:59

 | 
show 4 more comments

6 Answers
6

active

oldest

votes

up vote
41
down vote



accepted

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.

share|improve this answer

edited Dec 6 '15 at 20:59

muru

21015

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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! :)"
  – Pratik C Joshi
  Dec 6 '15 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 '15 at 18:19
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @muru : thank for the edit. I'll try to be cleaner next time.
  – gazzz0x2z
  Dec 6 '15 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 '15 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 '15 at 4:55
  

  
  
  
  

 | 
show 1 more comment

up vote
15
down vote

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.

share|improve this answer

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

• 
  
  
  

  
  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 '15 at 18:10
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  The question is usually not "whodunit" but "what were they thinking" :-)
  – gnasher729
  Dec 6 '15 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 '15 at 22:06
  

  
  
  
  

suggest improvements | 

up vote
6
down vote

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.

share|improve this answer

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

• 
  
  
  

  
  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 '15 at 6:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '15 at 11:23
  

  
  
  
  

suggest improvements | 

up vote
5
down vote

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.

share|improve this answer

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

suggest improvements | 

up vote
3
down vote

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.

share|improve this answer

answered Dec 7 '15 at 1:03

stevieg

1312

suggest improvements | 

up vote
2
down vote

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.

share|improve this answer

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

suggest improvements | 

6 Answers
6

active

oldest

votes

6 Answers
6

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
41
down vote



accepted

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.

share|improve this answer

edited Dec 6 '15 at 20:59

muru

21015

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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! :)"
  – Pratik C Joshi
  Dec 6 '15 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 '15 at 18:19
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @muru : thank for the edit. I'll try to be cleaner next time.
  – gazzz0x2z
  Dec 6 '15 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 '15 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 '15 at 4:55
  

  
  
  
  

 | 
show 1 more comment

up vote
41
down vote



accepted

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.

share|improve this answer

edited Dec 6 '15 at 20:59

muru

21015

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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! :)"
  – Pratik C Joshi
  Dec 6 '15 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 '15 at 18:19
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @muru : thank for the edit. I'll try to be cleaner next time.
  – gazzz0x2z
  Dec 6 '15 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 '15 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 '15 at 4:55
  

  
  
  
  

 | 
show 1 more comment

up vote
41
down vote



accepted

up vote
41
down vote



accepted

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.

share|improve this answer

edited Dec 6 '15 at 20:59

muru

21015

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

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.

share|improve this answer

edited Dec 6 '15 at 20:59

muru

21015

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

share|improve this answer

share|improve this answer

edited Dec 6 '15 at 20:59

muru

21015

edited Dec 6 '15 at 20:59

muru

21015

edited Dec 6 '15 at 20:59

muru

21015

21015

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

answered Dec 6 '15 at 12:16

gazzz0x2z

5,93621634

5,93621634

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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! :)"
  – Pratik C Joshi
  Dec 6 '15 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 '15 at 18:19
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @muru : thank for the edit. I'll try to be cleaner next time.
  – gazzz0x2z
  Dec 6 '15 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 '15 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 '15 at 4:55
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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! :)"
  – Pratik C Joshi
  Dec 6 '15 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 '15 at 18:19
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @muru : thank for the edit. I'll try to be cleaner next time.
  – gazzz0x2z
  Dec 6 '15 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 '15 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 '15 at 4:55
  

  
  
  
  

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! :)"
– Pratik C Joshi
Dec 6 '15 at 16:58

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! :)"
– Pratik C Joshi
Dec 6 '15 at 16:58

14

14

"watch funny music" OP I think you have unrealistic expectations of the world in which you live.
– Lightness Races in Orbit
Dec 6 '15 at 18:19

"watch funny music" OP I think you have unrealistic expectations of the world in which you live.
– Lightness Races in Orbit
Dec 6 '15 at 18:19

1

1

@muru : thank for the edit. I'll try to be cleaner next time.
– gazzz0x2z
Dec 6 '15 at 21:43

@muru : thank for the edit. I'll try to be cleaner next time.
– gazzz0x2z
Dec 6 '15 at 21:43

3

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 '15 at 23:06

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 '15 at 23:06

1

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 '15 at 4:55

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 '15 at 4:55

 | 
show 1 more comment

up vote
15
down vote

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.

share|improve this answer

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

• 
  
  
  

  
  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 '15 at 18:10
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  The question is usually not "whodunit" but "what were they thinking" :-)
  – gnasher729
  Dec 6 '15 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 '15 at 22:06
  

  
  
  
  

suggest improvements | 

up vote
15
down vote

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.

share|improve this answer

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

• 
  
  
  

  
  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 '15 at 18:10
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  The question is usually not "whodunit" but "what were they thinking" :-)
  – gnasher729
  Dec 6 '15 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 '15 at 22:06
  

  
  
  
  

suggest improvements | 

up vote
15
down vote

up vote
15
down vote

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.

share|improve this answer

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

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.

share|improve this answer

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

share|improve this answer

share|improve this answer

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

answered Dec 6 '15 at 15:04

gnasher729

70.9k31131222

70.9k31131222

• 
  
  
  

  
  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 '15 at 18:10
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  The question is usually not "whodunit" but "what were they thinking" :-)
  – gnasher729
  Dec 6 '15 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 '15 at 22:06
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  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 '15 at 18:10
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  The question is usually not "whodunit" but "what were they thinking" :-)
  – gnasher729
  Dec 6 '15 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 '15 at 22:06
  

  
  
  
  

17

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 '15 at 18:10

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 '15 at 18:10

4

4

The question is usually not "whodunit" but "what were they thinking" :-)
– gnasher729
Dec 6 '15 at 21:54

The question is usually not "whodunit" but "what were they thinking" :-)
– gnasher729
Dec 6 '15 at 21:54

1

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 '15 at 22:06

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 '15 at 22:06

suggest improvements | 

up vote
6
down vote

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.

share|improve this answer

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

• 
  
  
  

  
  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 '15 at 6:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '15 at 11:23
  

  
  
  
  

suggest improvements | 

up vote
6
down vote

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.

share|improve this answer

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

• 
  
  
  

  
  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 '15 at 6:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '15 at 11:23
  

  
  
  
  

suggest improvements | 

up vote
6
down vote

up vote
6
down vote

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.

share|improve this answer

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

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.

share|improve this answer

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

share|improve this answer

share|improve this answer

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

answered Dec 6 '15 at 23:12

Cort Ammon

2,7121713

2,7121713

• 
  
  
  

  
  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 '15 at 6:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '15 at 11:23
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  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 '15 at 6:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '15 at 11:23
  

  
  
  
  

1

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 '15 at 6:01

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 '15 at 6:01

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 '15 at 11:23

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 '15 at 11:23

suggest improvements | 

up vote
5
down vote

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.

share|improve this answer

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

suggest improvements | 

up vote
5
down vote

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.

share|improve this answer

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

suggest improvements | 

up vote
5
down vote

up vote
5
down vote

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.

share|improve this answer

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

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.

share|improve this answer

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

share|improve this answer

share|improve this answer

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

answered Dec 6 '15 at 12:17

Kilisi

94.7k50216376

94.7k50216376

suggest improvements | 

suggest improvements | 

up vote
3
down vote

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.

share|improve this answer

answered Dec 7 '15 at 1:03

stevieg

1312

suggest improvements | 

up vote
3
down vote

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.

share|improve this answer

answered Dec 7 '15 at 1:03

stevieg

1312

suggest improvements | 

up vote
3
down vote

up vote
3
down vote

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.

share|improve this answer

answered Dec 7 '15 at 1:03

stevieg

1312

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.

share|improve this answer

answered Dec 7 '15 at 1:03

stevieg

1312

share|improve this answer

share|improve this answer

answered Dec 7 '15 at 1:03

stevieg

1312

answered Dec 7 '15 at 1:03

stevieg

1312

answered Dec 7 '15 at 1:03

stevieg

1312

1312

suggest improvements | 

suggest improvements | 

up vote
2
down vote

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.

share|improve this answer

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

suggest improvements | 

up vote
2
down vote

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.

share|improve this answer

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

suggest improvements | 

up vote
2
down vote

up vote
2
down vote

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.

share|improve this answer

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

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.

share|improve this answer

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

share|improve this answer

share|improve this answer

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

answered Dec 6 '15 at 22:04

Patricia Shanahan

16.2k53256

16.2k53256

suggest improvements | 

suggest improvements |