1. Junior Engineer Reading List
by David Thomas, Andrew Hunt
This is a great book for programmers who have learned the mechanics of programming, maybe in college, but don't quite feel secure deciding what to do. It's like the difference between drafting and architecture. What you learned in that class in college was drafting, and you can draw beautifully, but if you still feel like you wouldn't quite know where to begin if someone told you to write a P2P music-swapping network all by yourself, this is the book for you. (by Joel Spolsky)
by Steve McConnell
The encyclopaedia of good programming practice, Code Complete focuses on individual craftsmanship -- all the things that add up to what we instinctively call "writing clean code." This is the kind of book that has 50 pages just talking about code layout and whitespace. (by Joel Spolsky)
by Eric Steven Raymond
In his preface Raymond says that this is a “why-to” book, rather than a “how-to” book. The lessons described here are applicable to other environments as well, in building classes, modules, packages or micro services. Especially inspiring is the first chapter (Philosophy: Philosophy Matters.)
“More of the Unix philosophy was implied not by what elders said but by what they did and the example Unix itself set. Looking at the whole, we can abstract the following ideas:
- Rule of Modularity: Write simple parts connected by clean interfaces.
- Rule of Clarity: Clarity is better than cleverness.
- Rule of Composition: Design programs to be connected to other programs.
- Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
- Rule of Simplicity: Design for simplicity; add complexity only where you must.
- Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
- Rule of Transparency: Design for visibility to make inspection and debugging easier.
- Rule of Robustness: Robustness is the child of transparency and simplicity.
- Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
- Rule of Least Surprise: In interface design, always do the least surprising thing.
- Rule of Silence: When a program has nothing surprising to say, it should say nothing.
- Rule of Repair: When you must fail, fail noisily and as soon as possible.
- Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
- Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. 1._ Rule of Optimisation: Prototype before polishing. Get it working before you optimize it._
- Rule of Diversity: Distrust all claims for “one true way”.
- Rule of Extensibility: Design for the future, because it will be here sooner than you think.”
by Jon Bentley
A must read for everyone who calls themselves a "programmer", this book is part of almost every list of programming book classics. It is hard to explain why. It is a collection of problems and solutions, but it gets to the root of what programmers do; create elegant, unique and clever solutions. It shows how to solve problems effectively and how to think like an engineer.
Next time when you encounter interesting problem in your daily job, try not to search for a solution on StackOverflow but instead try to analyse the problem the way it is shown in this book. Fun guaranteed, and you will probably end up with better solution.
by Michael Feathers
In almost all other industries legacy is something to admire and something to build on, e.g. Beethoven or David Bowie can be considered as legacy in music. It would be very uncommon for someone in the field of music to suggest that a legacy such as Bowie is should be rewritten or erased as we often hear in case of legacies in our own industry. Legacy code is complicated because we don’t fully understand it, and understanding it requires hard, research work. It’s alluring to come across easier task of writing something new, so we will often hear suggestions to rewrite old code (if you are thinking it is a good approach check out “In Search of Stupidity”, on Independent’s list). This book teaches us how to work with the code we are not fully familiar with but we need to work on. For each complaint that something is impossible it gives us a technique to make it possible.
by Don Roberts, William Opdyke, Kent Beck, Martin Fowler, John Brant
This book shows us various techniques of restructuring that each programmer should be knowledgeable in, especially if they have to add some new functionality to the legacy code. If you work with legacy code, sooner or later you will encounter a code that was not designed to support new functionality at the moment it was created. One approach is to just paste new functionality despite constraints. The other is to refactor code in a way as new functionality was planned from the beginning. This book teaches us how to do that.
by Frederick P. Brooks Jr.
Certainly one of the classics of software project management, this book first appeared a quarter of a century ago, when Fred Brooks tried to run one of the first very large scale software engineering projects (the OS/360 operating system at IBM) and became the first person to describe how radically different software is from other types of engineering. This book is most famous for discovering the principle that adding more programmers to an already-late project makes it later, but that's only the tip of the iceberg. Understanding this book is a prerequisite for thinking correctly about managing software teams. (by Joel Spolsky)
It is fascinating that although this book was written 40 years ago most of the things it discloses we are discovering again today.
“How does a project get to be a year behind schedule? One day at a time.”
by Joel Spolsky
Joel Spolsky is a globally recognized expert on the software development process, CEO (and co-founder) of Stack Overflow and co-founder of Fog Creek Software, a software company and incubator that created FogBugz and Trello. We follow and admire Joel’s work, and as you can see some book reviews on this list are taken from his page. Do you need more reasons to check his collection of writings by other authors?
by Douglas Crockford
JavaScript is a programming language we all encounter sooner or later. And as the author says it is also "the world's most misunderstood programming language”. We often hear complaints and frustrations about it that in most parts are a product of lack of understanding. We are trying to force JavaScript to act as some other programming language we are familiar with. To fully value it we must know it’s basic principles. We recommend this book as introduction to JavaScript fundamentals. There is also a recommended video course from the same author.
by Steve Krug
An excellent and entertaining book on UI design for the web. Finally, a book that tries to understand the principles of good UI design, not just the mundane rules (like "don't change the colors of links"). Steve Krug's primary thesis is that the less you make people think, the easier your site will be to use. "What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is. (by Joel Spolsky)