51–60 of 90 posts
* If there's no architecture-document that gives a short (3-5) page overview on the layout of the code then start writing one.
* Skim through the folders / packages / classes and write down a few obvious questions that pop into your mind while "speedreading" the code.
* Try to make an improvement to see how the whole CI/CD process works.
* Look through the list of direct dependencies / libraries and see where they are used.
1. Get confortable using “grep” [1], or better, “ripgrep” [2], which is quite faster than the former. They are both available in Linux, macOS, and Windows via WSL. 2. If the project uses a version control system (Git, Mercurial, Subversion, etc.) then take a look at the most recent additions, modifications, and/or deletions in the version control log (git-log, or whatever you want to call it). Sometimes, the most rel…
E.g. from `axios.get(`/users/${currentUserId}`) in frontend code jump to `class UserSingleView: def get(self, user_id):` in the backend, and vice versa.
From the root of the repo: grep -HIron 'your search pattern' * Sometimes I'll add -i (case-insensitive), or drop the -o (for some context but beware minified files), etc.
--exclude-dir=.git --exclude-dir=.svn
If there is no unicode setting "LC_ALL=C" can speed things up considerably too.
Contrary to what the terminal wizards might tell you about configuring vim, tmux and using grep, just install a real IDE
A lot of people in this thread are recommending grep and ripgrep, but you do not have context with those tools, so it isn't as helpful, imo. With an IDE, you can find usages of symbols, trace connections, build graphs, etc.
- Familiarizing yourself with vim is great and one of the best timesaving skills I decided to pick up randomly. You can install vim plugins for most IDEs
- Pick a small feature that you are curious how it works, and focus entirely on how it was implemented. The simpler the better really. Use git history to see the commit that the feature was introduced, and look how that engineer implemented it. It's quite easier for me to learn how something works by just focusing on seeing the Pull Request for the implementation. Just focus on looking how various things were implemented, and you'll (hopefully) see a pattern in code practices & design patterns.
- If you have questions, you should feel free to ask other engineers that work on the project. I was in a pretty senior position at my last job and we had quite a large codebase, and I personally never minded helping out junior and new engineers ever when they were coming up to speed on a new codebase. I always took the viewpoint that it's always in my best interests to help out the newer team members get up to speed quicker and have a better understanding of the product so they are able to effectively contribute. Hopefully engineers on the project you are working on think similarly.
- Absolutely learn how to perform proper debugging if you are not familiar already. Learn how to hook the browser to your IDE, how to troubleshoot things on the backend if you get to the point where you're doing fullstack work. Effective debugging is an incredibly important skill to pick up.
- Learn how to use IDE / other editor tooling such as jump to definition, refactor, inspect, find all occurrences. If this is a react project learn how to use browser extensions like devtools to help with debugging and understanding document structure.
Contrary to what the terminal wizards might tell you about configuring vim, tmux and using grep, just install a real IDE
I use an ide for core development but knowledge of vim, tmux and linux tools has served me really well.
Also, it helps that a lot of the similarities in newer IDEs are inspired by the predecessors.
There are times where you can't use the ide (middle of ssh session to a remote server, quick edit in a file w/o loading entire folder &c.), so its worth investing some time into these basic tools.
Step 2: Document their knowledge