|
|
|
|
|
by karmakaze
1654 days ago
|
|
Get myself feel onboarded which can be different than whatever onboarding was planned for me. For me that's being able to ship a change to the core system I'll be working on. That paves a green path in process. Be aware of and have access to the logs, stats/SLIs. Choose my editor/IDE and be able to run the (sub)system and tests locally. The other thing I usually want and make is a complete ERD or complete ERD of the teams specific area and connections to other areas. Knowing the logically-unique keys for every table and effective FK relationships and cardinalities can tell you a whole lot very quickly and accurately. Learn terminology and conceptualization (both technical and product-customer focused ones) to put everything above and more into context. Get assigned to an ongoing or new project (or mini-project), fixing bugs is a fantastic way. Allows for deep-dives that cover depth through layers of the system and learn to navigate the codebase and logs, stats, what questions to ask. Start understanding performance or scaling issues, either already identified or be able to discover them by accessing stats or error/slow query logs, etc. Understanding the codebase is low on my list of priorities and approached tactically. For a specific given task, learn as much as I need to know and not too much more. Slowly and organically learn the typically undocumented architecture details, again on a need-to-know basis. All these things become higher priority later. |
|