Three books developers should read when they graduate

Books for CS majors who become software developers

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 appears on pretty much every list of books for programmers and for good reason. It’s the best high level coverage of concepts that are useful in day to day programming but that you might not think of or learn in school. Each of the concepts is described with the problem it will help you solve. Need to generate a large set of test data? Write a throw-away program that generates it. Need to change the business logic constantly? Store it in a config file. The paper version of the book I have comes with an insert of the 70 key points in the book, along with checklists for common tasks, if you buy an e-reader version you can get the print out here.

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

Most of the time you’ll be changing code that’s already been written, so should know how to do it well. The number of greenfield projects you’ll get to do, especially as a junior developer are fairly low. Usually you’ll be making changes or fixing bugs in code that someone else wrote. The quality of that code can vary from good to spaghetti and it’s important to follow the boy-scouts rule of always leave it cleaner than it was when you got there. Which is why this book is on the list.

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

Unlike the other 2 books which are useful no matter what type of coding you’re doing this book is less helpful if you’re just doing frontend, DBA work or programming in an non object oriented way. Caveats aside if you’re programming in an object oriented language (statistically you will be) it gives you a great introduction to common design patterns that you see in the OO world. At some point in your career you’re going to be programming OO so you should at least know how to do it well

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

I own a dog eared heavily underlined copy of this book. It was one of the first books I read outside of college and I still think it’s the most comprehensive book on writing good programs. It covers a lot of the same material on coding as Pragmatic but in even more depth. The reason it didn’t usurp it is because:

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

The seminal book on refactoring. When I was reading Working with Legacy Code it felt like an updated version of this. Part of the reason this book doesn’t make the list is because it was so successful. A lot of the points the book makes seem like common sense now because people adopted the advice in it. But things like the evils of enums and writing code that generates code are still underutilized. If nothing else the author even suggests you can read the first few chapters and skim the rest which I suggest you do. A lot of the refactoring techniques in this book have been automated by Resharper.

Mythical Man Month

This is a fascinating book since it’s the first well known book about software engineering and it gives you a glimpse into what it was like to program in the 70s. It falls more into the category of software engineering than coding/developing. In addition although the advice is still relevant the examples are anachronistic. That said every developer should at least read the essay “No Silver Bullets” though and keep it in mind whenever someone says “This new tool I read about on HN will cut our development time in half”