Personally I'd start with Corporate Confidential by Susan Dephillips. Skip the first chapter but pay attention to the rest. You aren't in academia anymore and this will give you some hints as to what's expected of you as your career progresses.

(As an aside, people here will suggest the other Corporate Confidential by Cynthia Shapiro but I do not recommend it. It does contain some nuggets of valid and useful information but a lot of it is presented in an excessively cynical and lurid way designed to appeal to the conspiracy theorist, something there's no shortage of on HN, or aren't applicable to the software profession. For example, Secret 29 "Your Values Are On Your Desk" particularly made me roll my eyes; nobody gives a hoot what's on your desk unless it's growing mold and the "...many internal promotions fail within the first year and are either fired or demoted..." also elicited a snort. Unless you're unlucky enough to be starting your career in a particularly toxic work environment, people are not going to be out to get you to that degree.)

If you haven't read DeMarco and Lister's Peopleware, that would also be an excellent choice.

I have written a book and have a blog on this topic. Primarily focused on "soft skills" (I think they're pretty hard) because that's what I wanted to write about.

https://letterstoanewdeveloper.com/

There are some other books covering similar ground.

From my book proposal and other research, here's a set of books/sites I'd recommend:

   * https://medium.com/basecs
   * New Programmer’s Survival Manual: https://pragprog.com/book/jcdeg/new-programmer-s-survival-manual 
   * Your First Year in Code: https://leanpub.com/firstyearincode
   * Code Complete (long and some parts aren't very modern, but very in depth)
   * The Pragmatic Programmer
   * Don't Make Me Think
   * Badass: https://boingboing.net/2015/02/27/kathy-sierras-badass-how-to.html
   * The core docs of whatever language you are using (don't underestimate the power of understanding the core libraries!)

I'll be interested to see what else is suggested here.

First off, congrats on graduating and getting your career started. You have some exciting times ahead of you.

I've had quite a few friends and family members ask me the same general questions, which became the basis for a book I wrote titled "Junior to Senior: Career Advice for the Ambition Programmer." I'm currently revising it and it's due to be published later this year.

https://www.holloway.com/b/junior-to-senior

While you'll certainly learn new technologies and sharpen your technical skills in your first role, there are plenty of other things you'll need to learn to navigate your career. Things like:

  * Self-confidence
  * Learning to work with your manager
  * Recovering from mistakes
  * Reading unfamiliar code
  * Ways to add value
  * Identifying and reducing risk
  * Communicating effectively

My advice to you: Don't put off the soft-skills until later in your career. There's a lot more to being a software engineer than just writing code.

> 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.

Thanks, you encapsulated what I was thinking when I first came across this Ask HN. When hiring a new grad, I wouldn't expect them to know "all the perils of building software in industry with microservices, distributed systems, collaboration tools, etc"! I'd expect them to:

   * know "of" these concepts, or at least be curious when I mentioned them
   * be willing to ask questions
   * learn about them in the context of our systems

> 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.

This so much!

I think it helps to read content that's written by people in similar situations, to learn from other recent grads' experiences! For example:

https://medium.com/@maitrishahhhh/adapting-and-excelling-at-...

LinkedIn has one for SRE new grads - https://linkedin.github.io/school-of-sre/