For obvious reasons (be a better developer) I desire to gain a deeper understanding of not just my code, but the systems / frameworks / libraries that I work with. As a senior-ish dev* I feel I should have more than a surface level understanding however I am struggling to bring myself to that level of expertise.

In more concrete terms. I have been working with Android for ~5 years now. I know the APIs well, but recently have come across a bug. On second screen rotation FragmentManager is failing to find it's target Fragment after restoration thereby crashing the app.

After doing the usual

  • search google stack overflow
  • debug through my code step by step
  • read through / debug sections of framework code that seem relevant

I have come up empty so I go one step further.

  • read through documentation
  • watch tech talks on youtube

If that does not help usually it finally leads me to attempting to read the entirety of a class or two of framework code in an attempt to understand it more fully. This is almost always a fruitless endeavor.

Not to sound dramatic, but it can feel quite hopeless when I get to this point and still don't have a solution. Now I am reading through entire classes of code. But I struggle to put the information in context, or grasp its true use.

As an example Reading something like below I can kind of gork that it has something to to do with restoring fragments with retained children, but it is just one piece of nebulous disconnected information when I move to the next member or method.

// For use when restoring fragment state and descendant fragments are retained.
// This state is set by FragmentState.instantiate and cleared in onCreate.
FragmentManagerNonConfig mChildNonConfig;

After reading the whole class I am juggling many seemingly unrelated concepts in my brain, and still have no clue how they interact with themselves and other classes.

Sometimes I wonder if I am too dumb to be a senior level developer. (It is ok to say it if it is true. I am not trying to put blinders on here and pretend everything is OK if it is not)

If you have made it this far, thanks for at least skimming my rambling. What I guess it boils down to is

How do you approach understanding large interconnected systems that you did not write?

* I have been a professional software dev of sorts for nearly a decade now. However I have made the mistake of finding roles where either A) I work alone, or B) there is little allowance for personal growth. I certainly do self directed study, and have learned lots over my career, but I still feel in comparison to people in similar positions I am lagging behind. I am really hoping to find some strategies that will assist me in elevating myself to the next level.

Another side note, I am working on finding employment on a proper software dev team where I can have code review, and co-workers to bounce ideas off of. I am sure that will help somewhat, but I am not certain it will be as much of a benefit as I am hoping.

  • sometimes you need to step through the code, or just understand some subsystem first. – esoterik Jul 12 '18 at 19:43

All of what you said sounds reasonable. There really is no simple way to learn something complicated.

The one idea (you touched on) which I would encourage going further with, is running under the debugger.

If you can get a symbolic debugger working, with source code for all the hidden system components (this depends a lot on the language & tools you are using, and if the library source is all available) - I have found just wandering through the code in the debugger a great learning tool.

Typically - pick an action or operation you kind of understanding (from a users perspective running the software) - and step in and follow the process you go through. At each stage debugging, you can decide where you want to drill down and understand more deeply, and where you want to skip and see what happens next.

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