Ironically, i find the fastest way is to not start with the code. I find just learning the business and use case beforehand is a great way to start. Answering what the application does, and what is the business use case can help get in the right frame of mind before exploring the code. This builds a solid foundation.
After that, I find just exploring the code with my first story adds an additional layer of understanding. Focus on structure more than implementation details in the first few weeks. If you are a more senior developer, try and understand the approach/paradigm and design pattern used in the underlying code. This will help you remember where everything is from a higher level perspective.
For tools, definitely use an IDE (I prefer intelliJ). An IDE will give you the power to explore a code base quickly and understand how everything is laid out in one application. It will also help you find potential bugs and opportunities of refactoring early on.
I definitely agree! I also usually start from business context, answering a question “how is it supposed to be working?”. This way there will also be clear division between normal (expected) things and the stuff usually described as a legacy.
This is especially important if you are coming to a complex context you are not familiar with. Modeling the main system components in my head and on paper added to code digging made it much faster for me to discover what is what.
I use paper to draw flow charts ALL the time 🙈 It's funny because the majority of the time the end result isn't even organized enough to be helpful at all, but the process of drawing it helps me understand a more organized flow in my mind...if that makes any sense!
Re: business context
It's funny you mention business context...closely related, I was just working on a bug where I found myself saying, "I'm not sure what use case is even possible to lead to this issue". The context is everything.
So that said, any ideas on how to bridge context with code for new hires beyond "vanilla" documentation? Or asking (read: low key bothering) more seasoned teammates?
Re: IDE
I tend to use VIM, but as soon as you mentioned IDE I could imagine where a heavier IDE would be very helpful for navigating the code. Maybe I'll try a heavier IDE for a bit 🤔
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ironically, i find the fastest way is to not start with the code. I find just learning the business and use case beforehand is a great way to start. Answering what the application does, and what is the business use case can help get in the right frame of mind before exploring the code. This builds a solid foundation.
After that, I find just exploring the code with my first story adds an additional layer of understanding. Focus on structure more than implementation details in the first few weeks. If you are a more senior developer, try and understand the approach/paradigm and design pattern used in the underlying code. This will help you remember where everything is from a higher level perspective.
For tools, definitely use an IDE (I prefer intelliJ). An IDE will give you the power to explore a code base quickly and understand how everything is laid out in one application. It will also help you find potential bugs and opportunities of refactoring early on.
I definitely agree! I also usually start from business context, answering a question “how is it supposed to be working?”. This way there will also be clear division between normal (expected) things and the stuff usually described as a legacy.
This is especially important if you are coming to a complex context you are not familiar with. Modeling the main system components in my head and on paper added to code digging made it much faster for me to discover what is what.
I use paper to draw flow charts ALL the time 🙈 It's funny because the majority of the time the end result isn't even organized enough to be helpful at all, but the process of drawing it helps me understand a more organized flow in my mind...if that makes any sense!
Business context and IDEs are great points!
Re: business context
It's funny you mention business context...closely related, I was just working on a bug where I found myself saying, "I'm not sure what use case is even possible to lead to this issue". The context is everything.
So that said, any ideas on how to bridge context with code for new hires beyond "vanilla" documentation? Or asking (read: low key bothering) more seasoned teammates?
Re: IDE
I tend to use VIM, but as soon as you mentioned IDE I could imagine where a heavier IDE would be very helpful for navigating the code. Maybe I'll try a heavier IDE for a bit 🤔