Three books developers should read when they graduate

Books for CS majors who become software developers

arthur johnston
Jul 1, 2014 · 7 min read

It’s been a month or so since you graduated and started your first developer job. You figured out how to get to the office before noon and all those other niceties. You fixed some minor bugs but you haven’t had to implement quicksort or construct a consistent hashing algorithm or anything from your CS program. To someone unfamiliar with the field it would seem weird that most CS graduates end up becoming software developers and most developers are CS majors. This is because although CS is a young field software development is still in diapers and the demand for software developers far outstrips the supply. CS majors are the closest college hire to developers that currently exists.

The problem lies in the gaps between the two fields. A lot of what a developer needs to do day to day is not covered as part of the computer science curriculum (and rightly so). What this means is when you graduate you’re not done learning your just done with people telling you what you should learn. A lot of this can be picked up on the job but it’s easier with some structure.

Learning by osmosis is a poor substitute when you have other options.

There are lots of lists out of books developers should read and most of them are great reading lists for developers. So why am I adding another? For a recent CS graduate many of these books are only helpful in the long term. Gödel Escher Bach will make you a better programmer in the long run but it won’t help you figure out how to get your pull request to pass code review. The other issue is that these lists usually lump general programming books together with domain specific ones. A front end developer is going to pick different books then a full stack start-up developer and those two list won’t have much in common with a list made by a big data dev. Roughly the categories that recommended books fall into are

  • Development practices — how to write good code and good software
  • Software Engineering — how to create a complete system
  • Computer Science — data structures, algorithms, etc. This should be the area you’re most comfortable in
  • Products — how to make a product people will buy
  • Front End Development — how to write software the user will see
  • Back End Development — how to write software the user won’t see
  • Data Analysis — figuring out what to measure and and what it means
  • Management — working with other people

A new graduate you mainly care about the first 3 topics and some combination of the next 4 depending on what you’re doing (the last is there for completeness). Although there is overlap between all the topics, especially the first 2 I’m going to concentrate on good development practices since that’s the most important for a new graduate and the one they’re most likely to be lacking in.

Good development practices aren’t just about quickly writing software that isn’t awful. That’s required but not sufficient. It’s also about how to solve or avoid common problems while developing software. Coding in college is about passing the assignment, as long as it runs for the professor you’re good. At work developing software is about more than just solving the problem, but coding well is still fundamental. No matter what type of development you’re doing you need to learn how to code well and design good software. That’s what these books are about

Pragmatic Programmer

This book is full of ideas that seem obvious in hindsight or after you have a few years of experience. When I recommended this book to someone who was learning to code he put it best “It’s things that are second nature to experienced programmers but I wouldn’t have thought of.” If you’re experienced parts of this book are going to seem obvious but with some new ideas you had not thought of. It’s also nice to have someone give concrete explanations for the habits you’ve picked up over the years

Working Effectively with Legacy Code

The book is part tract on the importance of testing and part how-to guide on refactoring/redesigning. Feathers argues that if code does not have tests for it you can’t be confident altering or debugging it. Even if you aren’t 100% sold on the idea of “Everything must be testable” the parts on refactoring and how to work with spaghetti code are worth it. Each chapter is titled with a complaint you’ll say when working with legacy code “I’m changing the same code all over the place” or “I need to change a monster method” followed by techniques to handle those issues. Also the arguments for testing, especially TDD are better reasoned than most of the arguments you’ll get following #TDDisDead on Twitter.

Head first design patterns

There are certain patterns of abstraction you see repeatedly when you’re programming. The repetition is not so straight forward that you can replace it with a component but HFDP explains some of the more common ones and how to work with them. So when you see a problem you can say “If we just create an adapter we can reuse the code instead of rewriting” More importantly it will get you up to speed with the common terminology so instead of flailing around for 10 minutes to explain that you vary your sorting algorithm based off of the results and which service was querying you can simply say “We used the the strategy pattern” and everyone will know what you’re talking about.

It’s an easier read than the original GoF book and the 600+ pages contain a lot of diagrams so it’s not as hard as it looks. It’s actually the easiest read of the three.

These three books won’t make you an expert but they will help you get up to speed. They cover the a lot of the gap between CS grad and professional developer but they don’t cover everything. I chose them because most developers don’t read at all so getting them to read just 3 would be great. If you are one of those developers who reads below are books that I recommend for new developers but didn’t make it into my top 3.

Code complete 2

1. It’s over 800 pages and dense, meaning most people won’t get through it.
2. It’s most helpful OO/imperitive style of coding.
3. Most of it has become ‘common’ wisdom meaning you’ll pick up a lot in this book between Stack Overflow and code reviews

That being said if you’re programming in one of those languages and think you have the fortitude to make it through this I still recommend it as an amazing book.

Refactoring

Mythical Man Month

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store