> bridging the gap from academia to all the perils of building software in industry with microservices, distributed systems, collaboration tools, etc) I’m a mo

> bridging the gap from academia to all the perils of building software in industry with microservices, distributed systems, collaboration tools, etc) I’m a more senior dev and I’d like this, lol! Honestly a lot of these lessons are going to be pretty contextual to your company. There’s not a single “accepted” POV like there is for when to used a linked list based an array kids of problems. Maybe because there’s no accreditation body that defines what it means to be a “software team” the same way there is for a CS degree. Some teams go super deep into systems code. Others make mobile front end apps. Others build backend services. Yet others might manage different components across the stack. Different domains and the level of risk involved in the softwares failure change the rules a lot! There’s cross cutting ideas like testability, software engineering and version control. But your linked resources have many of those. Good news is your team knows you come without their shared context. (Or they should!) Companies hire juniors in large part so they can mold them to the teams view of the world.