What process do you follow?

Write your answer…

14 answers

Ah, what a perfect opportunity for me to answer this, having started a new job just a week back.

The best way is obviously to dive in to code. Pick out a part of the application that you think you understand the most and trace the code by inserting logs (or breakpoints) to get a grip of the coding pattern. Then, build a similar feature or a solve a bug in the part of the code that you understood. Once your first PR gets merged, you will be touching all parts of the code very very soon.

Happy coding! I am still in the process of shipping out my first feature, I'll keep you posted on how it works out for me. :)


Hashnode is building a friendly and inclusive dev community. Come jump on the bandwagon!

  • 💬 A beginner friendly place

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 >500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Register ( 500k+ developers strong 👊)

  1. Checking readme.md
  2. If there are no readme or no useful info about the architecture/tech stack/etc - read diagrams
  3. If there are no diagrams - check docs/wiki
  4. If there are no docs/wiki - figure out which framework it uses (usually at least this info you can get by asking a simple question) and read it docs if needed
  5. If there is another custom framework or even 2 custom frameworks and 2 custom ORMs in the same codebase (I really have seen such 10years old project) - plan your exit strategy (how/when you will leave team/company and give that s-y codebase to someone else with a maximum profit to yourself)
  6. If you have no choice - find a place where you wouldn't be able to hurt anyone, play relaxing music and read the codebase folder by folder like a Bible and may the dark side be with you.

P.S. in your own life you always have a choice and an option to find a better place.

Show all replies

@danfromisrael this is exactly how you should work on any project. If there is no documentation, start writing at least small notes to yourself. At the end make sure your team contributes and everyone uses it. Problem, however, is that in a typical business you won't have much time for writing good documentation. managers consider it as a time and money waste for company.

At the end when you can choose and your time become expensive you can find a better place/project.

Reply to this…

I usually dive right in. I'd ask for specific bugs I could go hunt down and fix. This is the first step (at least for me it is) in figuring out what is going on in the codel

Sometimes I open up a new text file and write down the execution path (who calls what and who constructs what) in pseudo-code. This is especially useful if the code is too difficult to follow or has too much stuff going on.

  • Try to find out what the code is supposed to do.
  • No matter how bad is the documentation will go through all them if exists.
  • Talk to anyone who might know something about the code.
  • Step through the code in the debugger.
  • Introduce small changes and see what breaks.
Load more responses