Prologue: as I read the article below, thoughts kept coming up that I wanted to share. There were so many of them, in fact, that I had to write my own separate article 😄 And so…
I’ve brought you a bit of a long read (it contains links to other related articles, so the reading sprawls even wider):
➡️ https://www.spicyweb.dev/the-great-gaslighting-of-the-js-age/
I won’t retell it — the author’s pain is better felt firsthand — but the gist is this: often young (and not-so-young) developers voluntarily become hostages to one technology, or a small handful of them (the article uses React as its example), and treat it as the ideal, the future, or [any admirable adjective]. They have little desire to learn anything outside that ideal and even consider it harmful.
The problem runs deep and applies not only to React or the web but to any technology a developer loves. Subjectivity is a very poor — even somewhat destructive — quality for a developer. Sure, some technologies may be closer to your heart, but they shouldn’t cloud your objectivity when making decisions. The final technology choices should be driven by requirements, timelines, and team skill level, in that order of importance.
Personally, I believe a programmer should first and foremost understand general principles and approaches — that’s what professionalism demands — while specific technologies like React are “for the soul”. General principles and approaches don’t depend on where you apply them — web, desktop, mobile, IoT, low-level, or even hardware development. That’s where the value of such a programmer lies: an incredible ability to adapt to change, and software development is one of the most dynamic fields there is.
But what do these “general principles and approaches” actually mean?
General principles and approaches
These are all the knowledge and principles accumulated by the best minds over decades of software development and confirmed in practice countless times. It’s a huge topic, and no short post can cover it — but I can at least map out a path to start your immersion. Below are the main directions to explore, ordered by how hard they are to absorb and how broad the material is, along with the most useful links to literature for getting started.
1. SOLID DRY KISS for YAGNI
If that sentence looks like nonsense to you, and you have no idea who the girl Yagni is or why anyone would kiss her, don’t worry. Each word is an acronym for a development principle. Study them one by one and it will be a huge boost to you as a professional. The phrase’s overall message boils down to structure, unambiguity, and clarity in the code you write.
A short list of books for studying these principles in more detail:
SOLID — start with Robert Martin’s books, since he introduced the term into common usage. Specifically:
Agile Principles, Patterns, and Practices in C# - an excellent book. Don’t be put off by the C# focus — the examples and explanations are universal to any language. SOLID gets its own section in the book, where every letter is explained thoroughly. The book deserves a cover-to-cover read: the concepts and ideas it describes are fundamental and independent of any language or platform.
DRY — same logic here: start with the book that introduced the term:
The Pragmatic Programmer: From Journeyman to Master - a timeless classic. The book is practical, and the book is philosophical. It looks at programming as an art — one that turns you into a wonderful and subtle artist. Exactly what a professional needs.
KISS / YAGNI — here you’re best served by the books on code cleanliness.
Refactoring: Improving the Design of Existing Code
Clean Code: A Handbook of Agile Software Craftsmanship -
both are recipe books for improving your code. You don’t have to agree with
every recipe, but the books’ messages are right and needed, which is why
they’re rightly considered classics. If you come across “analog” books
elsewhere, they’ll most likely say the same thing in different words — so start
with these two.
And a couple of books that don’t belong to any one principle, but are conceptually about the same thing:
Code Complete: A Practical Handbook of Software Construction - a must-have for beginner (and not only) programmers. It instills good, sound habits from day one. Not everything in this book will be to your liking, and you may not entirely want to agree — but that’s how it should be. It teaches independence and the development of your own style and sense of beauty.
A Philosophy of Software Design - a book not for beginners, but for those seeking fresh perspectives on development and system design. It’s a mix of topics, so you can read only the sections that interest you. The author’s view on some questions doesn’t align with Fowler’s, for example — and that’s great. The more opinions you’re exposed to, the broader your horizons. Our goal is to make you a professional, and a professional is never fixated on a single opinion.
2. Data Structures and Algorithms
Knowing data structures and algorithms helps you write efficient, concise code that other programmers can understand. As you study them, you’ll notice real understanding dawning about the technologies and tools you use every day — information will start settling into the right places in your mind. By the way, when applying to FAANG-level companies, this is a must-have, and those folks wouldn’t ask for useless knowledge.
For structures and part of the algorithms, there’s an excellent free course on Stepik (link). But overall, this is exactly the case where practice is the best way to learn — and LeetCode or its equivalents are perfect for that. These services typically offer lists of practical problems on algorithms and data structures, with the ability to evaluate your solution and an explanation of the best approach for each problem.
It’s hard to recommend anything specific from books, since there are countless options, but the most useful for me were:
Algorithms Illuminated - a series of books and videos on algorithms (the books are at the bottom of the site). The mathematical foundations of the main algorithms are explained quite well. The books are structured as a reference, so you can pick the algorithm you need and study it in isolation (only the first part includes an introductory tour of general algorithmic mathematics). Some of the algorithms are also covered by the Stepik course above.
Introduction to Algorithms - I’ll say up front that this book is complex and not for bedtime reading — unless you’re using it to fall asleep 😀 But there’s probably no more detailed book on algorithms, their construction, and mathematical analysis. If you only need algorithms as part of your general knowledge, this book is probably overkill.
3. Design Patterns
Many have heard of them, but far from all use them. And that’s a shame, because these are ready-made solutions to common problems that have stood the test of time and an endless stream of programmers. Patterns are abstract, so they apply regardless of programming language or paradigm. Sure, there are many patterns and you can’t remember them all — but you don’t need to. Treat patterns as a reference book with answers to common questions, one you should at least skim so you know which questions exist and what ready-made answers are on offer. In practice, you need to know roughly 7–10 of the most common ones.
Design Patterns: Elements of Reusable Object-Oriented Software - a timeless classic and the unmatched original. All the main patterns were first formulated and documented in this book. It may be a bit too strict and formal, so below are a few more modernized alternatives:
Agile Principles, Patterns, and Practices in C# - I already recommended this book above, but it also has a separate section with the main and most “practical” patterns.
Refactoring.Guru - a very handy site when you need to quickly recall the right pattern. It has pictures, examples, and references to other patterns — just what you need for everyday use.
Patterns.dev - a pattern reference written in JavaScript and partly in React.
4. Software Architecture and Design
Any code you write is a small part of something bigger, and seeing that bigger picture is exactly what knowledge of architectural styles and designs gives you. Microservices, DDD, EDD, and so on are precisely the vocabulary of this layer. You can study it endlessly, because this layer essentially builds on the knowledge from the previous ones and adds the ability to see how to assemble your final application from disparate parts. There are many books, and even more information online. What worked for me:
Fundamentals of Software Architecture: An Engineering Approach
Software Architecture: The Hard Parts
Building Evolutionary Architectures: Automated Software Governance -
I discovered these books by chance, and their contents turned out to be
invaluable. They explain what system architecture is and what role an architect
plays in a project’s life. They’re written vividly and engagingly, packed with
useful notes from the everyday working lives of developers and architects. The
books will show you how to turn your project into a maintainable, working
product. There’s also a catalog of ready-made architectural solutions,
detailing how and where to apply them. In short, excellent reading.
Clean Architecture: A Craftsman’s Guide to Software Structure and Design - a good, lively book. Maybe not as fundamental as one might like, but there’s plenty of useful material to extract. I love Martin’s writing style, so I couldn’t help including it 🙂
Patterns of Enterprise Application Architecture - a reference of ready-made architectural solutions by Fowler. The solutions are narrow in scope, but that doesn’t make them bad. They partially overlap with Fowler’s blog, which is also worth following and reading.
Implementing Domain-Driven Design - a full immersion in DDD. Today DDD is one of the main concepts in building systems, and this book will help with that. DDD will keep coming up as you study various architectural solutions. The book is grounded and practical, and does an excellent job of revealing what DDD is. The author will explain why your architecture should be viewed through business eyes and how to turn it into something that solves business problems.
In the context of DDD, it’s worth mentioning the book Domain-Driven Design: Tackling Complexity in the Heart of Software, as it’s the original source of the term, though the author’s style can be somewhat dry and formal.
systemdesign.one - a wonderful blog on system design. Here you’ll find analyses of the design and architecture of the most heavily loaded applications in the world, with plenty of examples and patterns. An excellent resource for going deeper into the topic.
Conclusion
I’ve tried to cover every sphere of fundamental knowledge for a programmer. The books here are well-known and universally recognized, so you may not find new titles or revelations — which is why I’d be grateful if you shared links to any materials that left a strong impression on you and brought real benefit. I hope this was useful, and I’d also appreciate it if you shared this text with your colleagues and fellow programmers 🙏