Learning how to read legacy/new codebases (other people's work) is very crucial. I've lost multiple jobs due to inability to understand big parts of the applications + trying to be "polite" and not sound too d*mb. In my experience, almost 90% of projects I had to participate/code, were legacy/large complex "sloppy-second" projects. It was a pure bliss to start a new project - completely different appreciation. This should be noted in every advice you could give to young developers.
This was tremendously helpful. I'm grokking a large-ish legacy codebase and these tips are great. Nice speaking style and production, keep up the good work!
Imagine working on a team which doesn't do code reviews, total nightmare. That's a good question to ask during an interview. Candidate: "you guys do code reviews right? Sr Engineer: "What's that?"
Thank you. But "no progress" rule, may be harmful for your career in some companies with tough working culture, like Amazon. BTW, even ask for help too much in such companies, may be bad idea)
Definitely. There can be some bravado and ego in teams which can make reaching out a bad idea. I guess a good rule is to try to solve it yourself before reaching out.
I think a good thing to do before reaching out is to anticipate the questions your teammate may ask such as- 1. What are you trying to do? What's the roadblock? 2. What have you tried to do on your own so far to solve said roadblock? 3. What led to this roadblock, issue? Or (if you're not sure yet) 3.5 What do you think led to this issue, what did you try that makes you think so 4. Which part specifically don't you understand/ you need your teammate's help with? (Figuring out an approach, asking for clarity) 4.5, If possible, when reaching out to ask for a best approach to a task, prepare your own suggestions of approaches to take as well Before reaching out, make sure to have the answers to those questions so your teammate gets the idea that you did put effort into the task before reaching out. Sometimes, as I formulate the answers to those questions- I end up figuring the answers lol (rubber ducking)
For more on improvements for reading code better, see this video: ruclips.net/video/lj6GH6yWSlk/видео.html
Here are some other videos on software engineering: ruclips.net/p/PL6_nF0awZMoNvi0QLmcv4qY5kfbnHrqg_
Learning how to read legacy/new codebases (other people's work) is very crucial. I've lost multiple jobs due to inability to understand big parts of the applications + trying to be "polite" and not sound too d*mb.
In my experience, almost 90% of projects I had to participate/code, were legacy/large complex "sloppy-second" projects. It was a pure bliss to start a new project - completely different appreciation.
This should be noted in every advice you could give to young developers.
I am feeling myself in the same space. How to overcome reading large complex undocumented codebase.
Thanks so much. I've used the Walkthrough method in the past and it saved me tons of hours and headaches.
This was tremendously helpful. I'm grokking a large-ish legacy codebase and these tips are great. Nice speaking style and production, keep up the good work!
1. Take on small task
2. Get a mentor
3. Ask someone for a walk-through
4. Read documentation
5. Code reviews
6. 'No progres' rule
7.
Imagine working on a team which doesn't do code reviews, total nightmare. That's a good question to ask during an interview.
Candidate: "you guys do code reviews right?
Sr Engineer: "What's that?"
HA, great point! Glad to see code review becoming more and more common.
Good tips, but if you "find dementor" you run, unless you can cast expecto petronum
Very good point. LOL Thanks for watching.
amazing background!!
Thank you.
But "no progress" rule, may be harmful for your career in some companies with tough working culture, like Amazon.
BTW, even ask for help too much in such companies, may be bad idea)
Definitely. There can be some bravado and ego in teams which can make reaching out a bad idea. I guess a good rule is to try to solve it yourself before reaching out.
I think a good thing to do before reaching out is to anticipate the questions your teammate may ask such as-
1. What are you trying to do? What's the roadblock?
2. What have you tried to do on your own so far to solve said roadblock?
3. What led to this roadblock, issue? Or (if you're not sure yet)
3.5 What do you think led to this issue, what did you try that makes you think so
4. Which part specifically don't you understand/ you need your teammate's help with? (Figuring out an approach, asking for clarity)
4.5, If possible, when reaching out to ask for a best approach to a task, prepare your own suggestions of approaches to take as well
Before reaching out, make sure to have the answers to those questions so your teammate gets the idea that you did put effort into the task before reaching out. Sometimes, as I formulate the answers to those questions- I end up figuring the answers lol (rubber ducking)
HELP