Being a young and fairly inexperienced developer recently employed by a "real" software company I'd like some opinions and pointers on how to do the following:

Approaches on how to get familiar with a companies products , especially when you've no idea how it all works. The company I'm at now has one HUGE product , continually evolving and having been here for 2 weeks I've still no idea how it all sticks together apart from a special kind of glue made from the tears and frustration of young developers, it's incredibly fragmented and only 4 people in the office know the inner workings, all of them constantly busy

Give useful input on the product : Now, I know I'm just a kid in the company and I can't be expected to deliver anything ground-breaking in my first months, but you have to give as much as you're paid. I'm getting around twice as much as at my previous job but objectively speaking I've not done anything to deserve it yet. Just sat around staring at my laptop screen trying to decipher code. Now you might say that this is what I'm here for , to start off with at least, but at my previous job I was something of a go-to-guy, making decisions and contributing to almost every aspect of the company's daily running. While that was a lot of work I enjoyed the feeling of being 'connected' in the inner workings of the company I have a stake in (a symbiotic relationship if you will).please edit this point down, I'll leave it up to you guys to decide what's important

I'll post more things as I think of them, have to get back to reading and writing something only vaguely resembling C#

  • I don't think you'll fully learn the product until your tasked with fixing bugs here and there, and implementing new features. Overtime you'll be asking less and less questions. Commented Oct 14, 2011 at 7:40
  • Start with user manual and learning the system from the customer/user side. Once you get the outer workings, getting the inner workings will be easier.
    – SF.
    Commented Oct 14, 2011 at 9:25
  • 1
    Related? programmers.stackexchange.com/questions/84396/…
    – user
    Commented Oct 14, 2011 at 13:07
  • 1
    the exact same thing is happening to me just now...used to being the go-to-guy, now i'm the new guy, still figuring out how my new project app works...which is huge, with no documentation whatsoever. it sucks, but NWS got it right. It takes months to get the "aha!" moment.
    – silverCORE
    Commented Mar 4, 2012 at 6:47
  • Got an experienced developer to ask when you have problems?
    – user1249
    Commented Mar 4, 2012 at 22:14

9 Answers 9


2 weeks ? In my second job it was quite common for new hires to only get the 'oh! i get it now!' moment 9 months in....

If it is genuinely a huge product then they will expect a long time to 'get' it, just keep working hard and ask plenty of questions.

  • +1 for "ask plenty of questions". One thing that I find common among many developers is the desire to go it alone. Commented Sep 24, 2012 at 16:46

Even as a not-so-new developer, I often find myself thrust into situations where I have no idea how the software works or is designed (if it was designed). Often if there is someone around to ask, they don't know much more than I do, or are wrapped up in something else.

  • First step - Get prepared. Install a dev environment, get a notebook, clear off a whiteboard. If there are any design docs, find them and have them available for reference. @mcottle's answer is a great one. If you want to understand a system, you need to approach it like you're going to [take a test]/[teach someone else]. Write down lots of questions, draw relationships between components, and keep track of things that surprised you. If a new developer were to put together a rough sketch of the system in a format (wiki, document, whatever) that I could pass around to other new developers as a starting point - 1 million brownie points in my book.

  • Second step - Approach it as a user. What is this software for? What problem is it designed to solve? Read the manual. This will hopefully give you some context as you move on.

  • Third step - Determine the edges of the system. Where does input come from? What's the final result?

  • Fourth step - Trace an input through the code base. Don't get too hung up in the details on the first pass, just write down questions as you go. As you make additional passes you can try and answer those questions and generate new ones.

  • Fifth step - Find the seams in the system. The idea here is to find the major architectural layers (an I/O or network boundary is usually a good thing to document).

  • Sixth step - Now move on to breaking things into components. Is the system modular enough that you can think about X without wondering what's happening to Y and Z? If not, document that relationship. From here you can divide and conquer your way through the system, breaking each component down until you reach a "good enough" understanding.

Note that this is a fairly thorough method. In a very large project you'll likely be able to go a very long time without needing to know exactly how the Foo module interacts with Bar. I would strive to learn enough about the system that I know which parts I feel comfortable changing and which are shrouded in mystery. This is normal in any project; there are always libraries where you use 5% of the functionality and remain blissfully ignorant of the rest.

  • 4
    I've just read: "Sixth step - Now move on to breaking things" :D
    – back2dos
    Commented Oct 14, 2011 at 12:25
  • @back2dos - That's often step 0 for me :) Commented Oct 14, 2011 at 12:31

I assume you have already installed the development environment and have all the necessary tools working - if not, start with these. Setting up your dev environment usually takes a lot of time, with long idle periods waiting for software to download/install, while you can still do other things.

About your lack of information, I suggest you talk to your fellow developers and manager. If the senior devs are busy, talk to the others - they may be able to explain some things to you, or point you to documentation sources, and/or they are also frustrated by not having the full picture. In the latter case, you can approach your manager together, to work out some solution to your problem.

Even if the seniors are fully engaged, they probably understand that spending some time on teaching/mentoring the juniors now may reduce their workload in the long run. But it is management who ultimately decides about task assignment, so the decision is theirs to make.

  • 2
    A good approach. Everything's been installed , I've actually been given tasks already, hopefully finished to satisfaction( not getting a lot of feedback, so I figure I didn't screw up too bad)
    – Dani
    Commented Oct 14, 2011 at 7:24

One tip, ask lots of questions but not as you think of them. Keep a list of questions and when you do get time with a senior developer bring out the list. It's a far more efficient use of their time to answer 10 well thought through questions in on burst than five questions over the course of a day that interrupts their focus.

Consider using e-mail if they'd prefer that.

When you have the answer to a question, document it. If there's a wiki use it. If there isn't create one. Even tiddlywiki would be better than nothing.

  • Is tiddlywiki actually usable?
    – Pacerier
    Commented May 12, 2014 at 13:36

If I were you wouldn't worry so much about understanding "how it all works". If you are hired as a junior/inexperienced then focus on your tasks and ask questions when time given. For example when you are given a new task try to use that connection with your seniors to ask more general questions but don't ask too many questions at once. Also try to devote a little of your time each day in browsing through other parts the software, documents or whatever you have access to. Before you know it you'll see how it fits together end you'll end up being the senior.

Remember that if you consider it to be fragmented it may not actually be so, maybe you just don't know enough about the product yet.

  • 1
    There are 9 modules in the solution, each module has upwards of 20 views specific to that module, there are also around 50 shared views called throughout the solution and that's leaving out all the web services and separate vendor software. Fragmented? I'd think so.
    – Dani
    Commented Oct 14, 2011 at 7:52

While I admire those who can sit back and read code like they read a novel, I find it a bit tedious at times and that it does not really work with large complex software products and libraries.

I wrote a long post about reading and understanding code here that might be useful for this particular discussion - technikhil.wordpress.com/2010/07/06/how-to-read-code-a-primer The post deals with reading code in the context of improving oneself, so it talks about how to go about finding good code to read; but in this case since you already have identified the code you want to comprehend - these points might be useful -

  1. Go through the design documentation and try to get a feel for the way the code has been built. Good software projects follow certain architectural patterns – these dictate the code organization. Once you get a handle on this, understanding the code becomes a whole lot easier. If you can create a class diagram of the code you can get a good idea of the layout.
  2. The next thing to do is to compile it and run it. This can be straightforward or tough depending on the process followed in the project and it’s documentation.
  3. Now it’s time to fire up your favorite IDE and go exploring. A good place to start your code exploration would be to try to trace a functionality of the project that you are familiar with. This would let you go through the various layers and sub-systems and get a handle on how they inter-connect. For example when I was exploring NUnit – I started by writing a test and looking at the code classes I needed to do that.
  4. Try and identify the design patterns used in the code. If you do not know what design patterns are, then you need to stop reading this post right now and read this book. Familiarize yourself with design patterns – they form a great way to recognize and understand the design of well written code. This makes it easier to keep it in your head while reading code. It also helps you identify nuances and customizations made by the programmers more easily.
  5. Try to write tests for the code to fully understand it – this is really useful way to understand the dependencies between different parts of the code. When you try to write a test for the code you first need to satisfy (mock) all its dependencies. Next you need to understand the possible entry points as well as the exit values for the code. This improves your understanding of the code and gets you to the next level.
  6. Try to refactor the code. In this step you have moved from simply understanding the code to becoming familiar enough to be able to modify it. As the sophistication of your refactoring increases so too does your understanding.
  • @Dani don't take point 5 light. coz writing tests (search Test driven development) are the best way to learn the app functionality. You try that, and you will understand the magic happening. Commented Mar 3, 2012 at 8:25
  • your blog post was superbly informative. All junior software developers must read it!!!! Thanks..+1 Commented Sep 4, 2013 at 18:17

Also, if it's a truly huge project, you may not ever know how all of it works. You may only know the details of a few modules, and then just know how they interact with other modules. Very few engineers are experts on an entire system.


Everyones different but I found the best way I came to grips quickly was to do the "hard" yards and get down and learning. Basically this involved reading and more reading, investigating and more investigating and not being afraid to ask questions (although in the right situation and time).

If there are log files, look into these. I found to a certain degree being involved in looking into bugs was a great way to start coming to grips with the project. Although boring and not the most enjoyable it gave me a chance to really delve deep into a solution. As long as you are prepared to investigate an issue as thoroughly as you can. Even if you can't resolve it yourself and need to escalate it to a senior member, if you have shown your ability to really look into the issue and can help point out the areas you investigated and even offer your own opinions on what might be going wrong.

I found that senior members were more willing to sit down and then go through it with you at your desk if they know you have already taken the time to do alot of the donkey work.

An important note which may help you is when you ask questions try to write down the answer so that you do not make the same mistake of asking again. Although most senior developers have a great deal of patience for juniors it can quickly wear thin when the junior does not seem to be paying attention to what you are saying.

Good luck in your new role.


If the project is really huge, they won't expect you to know it in two weeks, or even two months. If they do, then you are at the wrong place.

My latest position is one where a high degree of relevancy isn't expected on the actual product shipped for a year. To get up to speed I spent a lot of time reading documentation, just playing around with the product/hacking it, and asking a lot of questions. The first few tasks you get (bug fixes, minor changes) should start to get you up to speed with the project. Each one after that should bring more understanding.

I'm sure there is a process that you can have laid out and follow but, I've found it best to just keep plugging away at it. The more you do, the more you will learn.

Not the answer you're looking for? Browse other questions tagged or ask your own question.