This is a repost from the Software Mastery newsletter. If you like what you see, consider subscribing to get emails delivered right to your inbox!

Welcome to the seventh issue of the Software Mastery newsletter.

In this issue, I want to share two software engineering books every junior engineer should read in their first year or two to maximize their performance.

For junior engineers, I would recommend the following books:

1. A good book on your main programming language.

2. A Philosophy of Software Design by John Ousterhout.

A Good Book On Your Main Programming Language

My first book recommendation is not a specific book because it depends on what programming language you spend the most time working with.

Whatever that language is, there’s a lot of value in learning about all it has to offer regarding features, APIs, and tools.

When you understand a programming language and its ecosystem deeply, you can better read code from others and write idiomatic code yourself.

As a software engineering intern at university, I saw noticeable growth in the quality of my Java after reading the well-known Effective Java by Joshua Bloch.

I didn’t understand everything in that book the first time, but as I read more Java written by senior engineers, I saw real-life examples of the patterns described in that book.

For other programming languages, here are some suggestions:

1. C# — C# in Depth by Jon Skeet

2. Go — The Go Programming Language by Donovan and Kernighan

3. JavaScript — JavaScript: The Good Parts by Douglas Crockford

4. Rust — Programming Rust: Fast, Safe Systems Development by Blandy et al.

5. Python — Fluent Python: Clear, Concise, and Effective Programming by Luciano Ramalho

A Philosophy of Software Design by John Ousterhout

My second book recommendation is a software design book not specific to any one programming language.

I’m a fan of A Philosophy of Software Design because, unlike other books in space, like the divisive Clean Code by Robert C. Martin, this book teaches some underlying principles of software design, rather than a list of rules to follow.

Here are some of my favorite takeaways from this book:

1. We’re all fighting against complexity. As software systems evolve, they become increasingly complex, making them harder to understand and modify. Incrementally investing in software design is one mechanism for keeping complexity under control.

2. Modules have an interface and an implementation. Modules, as described in the book, can have many forms (e.g., a service, a class, a function, etc.). When we use a module, we have to learn its interface (cost) to benefit from the functionality in its implementation (benefit).

3. Modules should be deep. A module is deep if it provides rich functionality behind simple interfaces, thus minimizing its cost while maximizing its benefits.

Your Turn!

I hope this issue inspired you to pick up some software engineering books.

Nowadays, people don’t read books cover-to-cover as often as they used to. I guarantee you’ll stand out if you commit to finishing one this year.

Are you currently reading any software engineering books? Reply to this email or comment below to let me know!

Best,

Sammy