This is a long article and the first bits comes off fairly condescending so I stopped reading…but one thing caught my eye:
“If you are a programmer, try to find an answer by reading the source code”
This is basically a superpower at any large tech co if only because few people do it, even though we’re literally all capable of it. When I inherit or start interfacing with a new service, the first thing I do is checkout the code and peruse through it. Even just 30-45 minutes, for an experienced engineer, is enough to get a feel for the layout of things. Then when you have a question about “How does X service handle Y scenario” you can just go read the code and know the answer exactly.
I can’t tell you how many times I’ve had the answer to a question and get something like “dang rco8786 how do you know so much about how everything works” and invariably my answer is just “I read the code”.
Maybe it's because I'm a less experienced programmer, but I find I have a lot of trouble understanding source code if I'm not trying to find or change something specific. I can't read it like a book, I have to experiment with it.
It's definitely a skill that takes time to develop, but don't be discouraged! Even reading code in the way you are now is helping you develop this skill.
Your ability to navigate a codebase, to able to see how its components relate to each other and to the effects the software has on the external world, is the perhaps the most valuable skill you can develop as a programmer. If you also have strong communication skills, you will go far.
I don’t typically read to understand anything in depth unless im doing something like that. But just poking around the folder structure, seeing what the api looks like, the background jobs (usually pretty descriptive in their names), database structure, etc gives you a good feel for high level functionality and then more importantly when you want to answer a more specific question you know right where to go look.
Sometimes a question will come up during a meeting, nobody knows the answer, so I’ll just pull up the source and because it’s already handy and since I know the structure I can find the answer in a matter of seconds.
If you're willing to consider a piece of advice, even the most complex rude goldberg-style codebases will yield to the program entry point. From there, you can start pulling at the wool and process it one knot a time.
It's tedious, slow work, but you can use note-taking, the REPL, tests (reading, if any, but also writing them), diagrams or any other tool for creating mental models until you manage it.
One thing that can help with certain scenarios is to think of it like debugging. "I thought when I did X, Y would happen, but instead Z happened - let me figure out why".
“If you are a programmer, try to find an answer by reading the source code”
This is basically a superpower at any large tech co if only because few people do it, even though we’re literally all capable of it. When I inherit or start interfacing with a new service, the first thing I do is checkout the code and peruse through it. Even just 30-45 minutes, for an experienced engineer, is enough to get a feel for the layout of things. Then when you have a question about “How does X service handle Y scenario” you can just go read the code and know the answer exactly.
I can’t tell you how many times I’ve had the answer to a question and get something like “dang rco8786 how do you know so much about how everything works” and invariably my answer is just “I read the code”.