3

Possible Duplicate:
How do you dive into large code bases?

I just joined a new company and started to study one of the their bigger system. For me to be productive, I need to understand the entire system without too much help. Other programers are really busy and dont' have time to hold my hands.

I used to use brain map to draw a pictorial representation of the system. Any recommendations on what is the right appproach to dissect a big program? It is a .net prgoram by the way.

Community
  • 1
user394128
  • 463
  • 1
  • 3
  • 7

3 Answers3

7

I would start with the documentation of the system: design document, requirements document(s), database schema or possibly a user's manual. If you are lucky, you will find all of these, but find whatever you can. Read these to get an idea of what the system is supposed to do. Then I would play with the system in a test environment to get a feel for how it works. Once I am comfortable with my understanding of what the system is supposed to do, I would start looking at the code for the simplest subsystem I can find. Maybe a single data entry form or a single analysis algorithm, the key is to find something small enough that you can understand that code completely. Keep repeating this until you have conquered the whole system.

If this is a system of any complexity, this will take a significant amount of time. I would also check with your new manager to see what areas (s)he wants you to focus on. The most important thing is to attack this problem in manageable chunks, you can't learn it all in one shot.

cdkMoose
  • 1,775
  • 9
  • 12
  • 2
    +1 Start with the 10,000 foot view (design docs, etc.) and then drop down to the 1,000 foot view (schemas, library APIs, etc.) and then create a sandbox so you can play with the code. Make a couple of simple changes, predict the outcome *before* you test, and then see if it does what you thought it would. Expect it to take at least weeks, more likely months, before you begin to feel comfortable moving around a big system. – Peter Rowell Oct 16 '12 at 17:08
4

For me to be productive, I need to understand the entire system without too much help. Other programers are really busy and dont' have time to hold my hands.

You should take this is a danger sign. You might want to look for greener pastures.

There should be a big picture presentation of the system as a whole. Multiple such big picture views. A cartoon for management, a more detailed one for the system architect, a different view for the system integrator. They should have shown you those pictures on day one and walked you through it. Someone should be mentoring you along, pointing you to training materials, tutorials, and documentation; showing you the online resources; checking on your progress; and be available now and then to answer questions you have. You shouldn't expect the mentor to spend all his/her time with you, but that mentor should be there.

With a large system it might take months, sometimes several months, for you to come up to speed and become a productive asset to the organization -- and that's with a proper system in place. Without a proper system in place, odds are good that nobody understands the system as a whole. The programmers are too busy because they're busy making a convoluted mess that will eventually come crashing down on them.

David Hammen
  • 8,194
  • 28
  • 37
  • 3
    Would the random driveby downvoter care to comment on the reason for the downvote? – David Hammen Oct 16 '12 at 16:56
  • 1
    As a side comment, new employees are almost always on probationary status. Companies sometimes do make mistakes when hiring. Joe "Looks Great on Paper" Smith is in reality Joe "Can't Program for Beans" Smith. This probationary status is a two-way street. People sometimes make mistakes when accepting jobs. What looked like DreamJob, Inc. is actually Nightmare, LLC. You should be just as ready and willing to fire your new employer as they are ready and willing to fire you during this probationary period. – David Hammen Oct 16 '12 at 18:53
  • 1
    Hi David, I was the downvoter and the reason was largely your first point. I don't think that it's reasonable to reply to "I just started a new job and my coworkers are really busy" with "you should look for a new job" with a bunch of "your company should do [x]" remarks. Certainly, you may be correct, but I don't think it's a constructive answer/feedback for the OP. Your last statement also seems to make a lot of hand-waving gestures at the quality and state of the work environment based off that one initial statement. Sorry I didn't make note of my reasons earlier, I was in a bit of a rush. – Steven Evers Oct 16 '12 at 22:17
  • @SnOrfus - Companies put new employees on probationary status. They have to. *Companies make mistakes in hiring.* This goes both ways. New employees should view new employers as probationary. *People accept job offers that in hindsight are really bad mistakes.* Not treating a new employer as probationary is harmful to career, health, sanity. **Lack of a mentorship program nowadays (the concept is not new) is one of those red flags that your employer is Nightmare, LLC.** Looking for a job after having just landed one is not a fun prospect. Next time around, remember to ask the right questions. – David Hammen Oct 17 '12 at 01:57
1

Personally, I like to dig in and start changing things (learn by doing). Ask for a task and figure out how to get that task done within the system. Don't be afraid to ask questions - the only stupid questions are the ones you already know the answer to. If you can get it, ask for a code review before checking anything in to the repository (any decent company should do this with new starters anyway).

You won't learn the whole system off the bat, but once you get comfortable with changing small parts of the system, you'll find it easier to branch out into other areas and figure out how they work. I don't know the scale of the system your working with, but I've been with my current company for a year, and there's no way anyone on our team can claim to know how everything works.

Bok McDonagh
  • 181
  • 4