1. 18

I’ll be graduating soon with a CS degree and will be starting my first non-internship job in August. I’ve read Refactoring (the first edition) by Kent Beck and Martin Fowler, and Extreme Programming Explained by Kent Beck. Other than that, I have not delved too deeply into the world of Software Engineering literature. What books would you recommend I read through this summer before I start work?

  1.  

  2. 8

    Since no one else has said it, congratulations [:

    1. 1

      Thanks! :D

    2. 5

      MIT put together something for this: https://missing.csail.mit.edu/

      I also recommend this book for anyone looking to learn how to structure code at a medium scale (so, in between “how to name variables” and “how to architect a large interacting set of systems”): https://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Computing/dp/020161586X

      1. 4

        The Google SRE book might be interesting to get a teaser of the operations/infrastructure side of things (https://landing.google.com/sre/books/ - the rightmost one is the original).

        1. 3

          Please tell us more about the job. I have a CS degree, but my first job was in pharmaceuticals. We don’t need to know which company, but more context provides better suggestions. Otherwise, this thread just becomes “what are the best books for a CS grad?” which is very similar to other book lists.

          The classics like Code Complete, Legacy Code, and The Pragmatic Programmer tend to be good starting points wherever you are going. If you were going to Facebook, Twitter, or the like, I’d recommend Designing Data-Intensive Applications because it covers a range of database and distributed systems topics at good level for you.

          If it was a big or more established company, I’d tend to strongly suggest something along the lines of The Rules of Work by Templar. Why? Well, you’ve studied CS and very likely will be exposed to politics, and a range of behaviours that you won’t be familiar with. Good managers would introduce you to these things, but it’s always good to do some of your own reading. Unlike technical books you are don’t take as much direction, it’s more for awareness as you ponder what’s going around you as you focus on being a software engineer. The Harvard Business Review’s guides tend to be small and focused as well, but I’m more familiar with Templar’s books because my manager recommended I read them.

          1. 1

            Larger FAANG company, probably working in either Java or Golang. I definitely am interested in stuff outside of the strictly “technical” as during my internships I found it just as important.

            1. 1

              Hey I’m guessing amazon maybe i could be wrong

          2. 3

            Things you can consider - (in no particular order)

            1. Start following the morning paper - small pieces of wisdom that you can accumulate everyday
            2. Some book recommendations that every programmer should read - previous lobsters thread. Do check out hwayne@’s response
            3. You will surely find something interesting to pick at HackerNewsBooks book aggregator - alongside some fiction/non-fiction too.
            4. Follow PapersWeLove

            Some of my personal favourites here -

            1. A Reading List for Computer Scientists
            2. What Every Programmer Should Know About Memory
            3. Brendan Gregg’s Book List
            4. Good books for Deep Hacks
            5. 11 Books All Software Engineers Must Read
            6. Books I recommend by Jessie Frazelle
            7. The Books That Every Programmer Should Read
            1. 3

              Given a formal CS background, there probably isn’t a whole lot extra computer science that will be useful to brush up on before starting the job. I would focus on books covering project management, especially case studies. Two pieces of reading I’ve found to be very useful:

              1. Strategically: The Phoenix Project is phenomenal (and more importantly, hilarious and easy to read). It’s a case study of a fictional team in a project management death spiral, and how they pull out of the death spiral. As I read the book, I definitely had many moments where I thought “this literally happened to me last week” and “I know exactly who this character is on my team”.
              2. Tactically: Avery Penwarr has an excellent blog post on his philosophy for project management. This should honestly be required reading for anyone project managing an engineering project (whether that’s a TL, EM, project manager, or just an engineer).

              That said, I found this reading useful a couple years into my career (not because it was not useful at the beginning, but because I discovered them a couple years in - I have no data on how useful this is at the beginning). I suspect you might find them unrelatable or highly theoretical. I’d recommend coming back to these about a year in, and seeing how the additional experience changes your perspective.

              (If you end up reading them, I’d love to hear about your initial impressions! Helping educate better engineers is a topic I’m very interested in, and I’m curious about how we can better build project management skills.)

              1. 1

                I will definitely look into these! I found that most of the hard problems that I or my team would encounter during my internships were more organizational rather than technical.

                1. 2
                  Software Foundations

                  The Software Foundations series is a broad introduction to the mathematical underpinnings of reliable software.

                  1. 1

                    My article organiser (Zotero) also made the same ironic, amusing mistake when importing the title of that Joe Erlang paper on errors.

                  2. 2

                    I found Database Internals by Alex Petrov to be quite enlightening.

                    1. 2

                      Code Complete by Steve McConnell is a timeless classic. Working with Legacy Code by Michael Feathers

                      1. 2

                        https://teachyourselfcs.com/

                        Found this site some time ago. It can be helpful for you.

                        1. 6

                          Not sure why this would be their first port of call when it essentially covers what they’ve just studied in their degree.

                          1. 1

                            Studying it once isn’t enough to act natural when pretending you didn’t memorize your whiteboard questions. Gotta hit that leetcode.com too.

                            1. 2

                              Cheers you’ve just reminded me why I have no inclination to throw myself into the big tech meat grinder when I graduate.

                              1. 2

                                OK, upon hearing you haven’t graduated yet, I’ll amend my first statement.

                                I may be exaggerating. I’m a person who has A) done (and failed) at least 50 leetcode-style whiteboard interviews, B) had (so far in ~7 years) rewarding jobs without leetcode interviews, where I had good coworkers and learned lots.

                                Maybe by the 20th time I had to draw a graph or binary tree in a Google doc (like actually typing out symbols like A—–B—–C to draw edges and vertices) to answer a network flow question in 30 min over a scratchy phone line while “vocalizing my thought process”, it got pretty old.

                                I know a common feel-good statement around leetcode is that you’ll only get them when you’re trying to get into the best of the best. That’s a joke too, leetcode will surprise you anywhere and everywhere. I’ve had the most absurd questions for run of the mill “DevOps Engineer” jobs at companies that were most definitely not big tech (or even close).

                                tl;dr: fuck leetcode, hate leetcode, but study leetcode. Just in case

                                1. 1

                                  I’ve been working as a developer for six years, I’ve probably interviewed with 20 companies across a few job hunts. I only had to whiteboard a few times and it was always about architecture rather than algorithms.

                                  Granted I haven’t interviewed with any of the biggest name brand companies, but it’s definitely not a common phenomena for your average interview in my experience.

                                  Most interviewers are aware of the “invert a b-tree on a whiteboard” meme, those who persist don’t have many excuses.

                          2. 1

                            Literally read everything. Books, code, news.

                            1. 1

                              I’ve found LWN to be consistently high-quality technical journalism, and well worth your (or your employer’s) money. If you’re working for a FAANG, it’s likely you can click a button and get it expensed. Older articles are available for free.

                              One of the more fundamental aspects of my engineering philosophy with regard to optimization came from a quote in an LWN article from more than 10 years ago:

                              “It’s not about booting faster, it’s about booting in 5 seconds.” Instead of saving a second here and there, set a time budget for the whole system, and make each step of the boot finish in its allotted time.

                              That mentality has set me up for a lot of success in taming unruly systems.

                              Outside of LWN, the asshole filter was a helpful post in dealing with cross-team communication. The tldr is: people want to get things done and if the official process is not the best way to do that, people are then incentivized to violate boundaries. I’ve seen this a lot in client-based teams that grow from ad-hoc email requests to a formal ticketing system: usually the ticketing system is where tickets go to die, while the clients know that to get real work done you just ping someone on the team directly. Eventually, the only way the ticket system survives is for people who get pinged to reject the ping: “Sorry, we’re trying to use the ticket system for this. Can you make a ticket and we’ll continue there?” By making the ticket system the best way to get something done, people are incentivized to do the right thing. Of course, this only works if the tickets are actually looked at and responded to, and only if the whole team makes a unified effort – otherwise the pings just get shifted somewhere else.