It sounds like you need to learn how to write testable code. For that, I would suggest two books: Working Effectively With Legacy Code and Clean Architecture.

Read Code Complete and Clean Architecture, then start incorporating those tactics and concepts into your own projects.

Another few books I've found incredibly helpful:
Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Clean Architecture: https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...
Domain Driven Design: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

Yep, read these books and apply the ideas directly to your work as you go: Code Complete (which IMO is more detailed and explanatory than Clean Code) then Clean Architecture.

The list is missing Clean Code, Clean Architecture, The Clean Coder, and Domain Driven Design. Also, while the books on the list look great a bunch of them are for very specific topics that don't have much to do with the majority of programming.

After Clean Code, also check out The Clean Coder. Less technical, more career/project focused.

There's also Clean Architecture, but I haven't read that one yet.

Clean Architecture
https://www.goodreads.com/book/show/18043011-clean-architect...

The Art of Scalability (2nd edition)
https://www.goodreads.com/book/show/25686275-the-art-of-scal...

To be entirely honest, most of his books are pretty awful, as they are mostly preaching something for the sake of preaching and selling the books. I bought his last one (Clean Architecture) as I wanted to improve myself as an architect, just to realize its riddled with fluff and rarely anything in there is actionable advice. For some reason the reviews from his followers are mostly glowing.

I also found myself agreeing with everything written in this blog post. For the record I have read his famous Clean Code, Clean Coder and Clean Architecture and I don't find them all that meaningful.

My top priority books:

    Software Requirements - Karl Wiegers

    Programming TypeScript - Boris Cherny

    Associate Cloud Engineer Study - Dan Sullivan

    Design Patterns - Gang of Four

    Refactoring - Kent Beck, Martin Fowler

    Programming Pearls - Jon Bentley

    Patterns of Enterprise Application Architecture - Martin Fowler

    The Pragmatic Programmer - David Thomas, Andrew Hunt

    CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl

    Working Effectively with Legacy Code - Michael Feathers

    Head First Design Patterns - Eric Freeman, Bert Bates

    Code Complete - Steve McConnell

    Peopleware - Tim Lister, Tom DeMarco

    Clean Code - Robert C. Martin

    The Clean Coder - Robert C. Martin

    Clean Architecture - Robert C. Martin

    Don't Make Me Think - Steve Krug

    Functional Design Patterns for Express.js - Jonathan Lee Martin

    The Surrender Experiment - Michael A. Singer

The best books I've ever read:

    Principles - Ray Dalio

    The Power of Now - Eckhart Tolle

    The Effective Executive - Peter F. Drucker

    Think and Grow Rich - Napoleon Hill

    Extreme Ownership - Jocko Willink, Leif Babin

    Influence - Robert B. Cialdini

    The Startup Way - Eric Ries

    The Lean Startup - Eric Ries

    12 Rules for Life - Jordan B. Peterson

    Measure What Matters - John Doerr, Larry Page

    The Fish That Ate the Whale - Rich Cohen

    The E-Myth Revisited - Michael E. Gerber

    The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh

    Management - Peter F. Drucker

    Thinking in Systems - Donella H. Meadows

    Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne

Congrats on your will and enthusiasm, I believe this is already a great first step!

Besides Martin Fowler which was already recommended, I would also recommend the books by Robert C. Martin (Uncle Bob), and his "Clean" series - there are books "Clean Code", "Clean Architecture" - all of them are really good and useful and will give you a solid foundation to build on.

Other than that, the best thing you can do is to get practice & ideally surround yourself with more experienced developers. Either get an internship in a company building something more complex, or participate in e.g. Google Summer of Code.

Doing fun side projects is also a great way - you learn a lot and also have something to show & write about - win-win!

+1 to this

In my own progression as an engineer who writes Java, I read Clean Architecture by Robert Martin which lead to AbstractFactory(s) and interfaces up the wazoo. The reasoning would always be "this can change!"

It definitely took me some time to understand that not everything will change, and if it does change, having some extra work for simplicity is a reasonable tradeoff sometimes. In general, knowing when to utilize OO design patterns takes time and experience.

I actually think that books which cover software engineering practices, rather than language specific books, have helped me the most. This is due to the fact that the concepts and principles you learn can be applied to many languages.

Two I've enjoyed are:
"The Pragmatic Programmer" by Andy Hunt and Dave Thomas
"Clean Architecture" by Robert C Martin

That being said, no harm in deep diving individual languages. Secrets of a JavaScript Ninja by John Resig was an excellent introduction to JavaScript!

So, in your opinion are Clean Code and Clean Architecture still relevant/updated?
I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer.
I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.

This is an incredibly broad question and touches on many aspects of software engineering, devops and operations. For operations, I would recommend having the team read the google SRE book https://sre.google/workbook/table-of-contents/ it has everything one would need to setup a modern operations infrastructure and associated best practices.
https://sre.google/workbook/table-of-contents/

Sounds like you are unhappy with the quality of code and error handling. Seems like it was written by junior devs? I would recommend having the team read the usually recommended books if they haven't. At the bare minimun:

* Refactoring by Fowler

* Clean Code by Robert Martin

If you are using an OO language:

* Practical Object-Oriented Design in Ruby

The book has "in Ruby" in the title but it's a general purpose book on what make OO design "good"

Then follow it up with

* Patterns of Enterprise Architecture

* Clean Architecture

These books are not perfect or the be all end all, there are parts of them that might be slightly dated but they get you to a large chunk of the way to the promised land.

Lastly, if the application is working, the users are happy, there is no bug infestation and you are not having issues with releasing new features, don't feel the pressure to immediately "fix" the code.

I'd say if the goal is to maximize engineering knowledge, less might be more. Especially if you don't plan to apply it on a day to day basis as an engineer.

For example, I'm currently reading Clean Architecture by Martin that is on your list. While the words on the pages are not hard to understand and it doesn't rely on any advanced computer science/engineering concepts, actually comprehending the posed principles, their implications, how to reason about them and how to pull them off well in a real world scenario is absolutely non-trivial.

I have met many people in tech that devoured douzends of books and conference talks, hundreds of podcast, blog posts, articles and that were an endless source of catchy quotes found in them. But they weren't able to actually apply all this "knowledge" to anything beyond the most basic. And in cases where these people where in leadership/management positions this often had negative impact on the project/product.

To finish with a catchy quote from Clean Architecture:

"The more haste, the less speed."

I agree. I based the Obvious Architecture around Uncle Bob's blog posts Clean Architecture and Screaming Architecture. It's taken months of testing, building and thought, but I think it's come out pretty nice on the other side. Both the delivery mechanism and the external persistence mechanisms are separate and pluggable from the app code itself.

You can go in the app/ directory of a project and read the file names of your actions and entities and know right away what the system does. Testing is fast because it never hits a database. Test doubles and mocking are easy to build and don't require a 3rd party lib. Data traveling between the app and the external systems is validated via contracts. It ends up being the most enjoyable TDD experience I've ever had.

For example, last night I put together an example "twitter" status update app in obvious. I got all the entities, actions, and contracts written TDD in about 3 hours. Today I'll be adding a delivery mechanism and probably filesystem and mysql plugs. Would be easy to write an api or console app and plugs for mongo, postgres, or whatever. Code is here: http://github.com/RetroMocha/obvious_status

I hate to be self-promotional, but if you are interested in Uncle Bob's Clean Architecture, I would love it if you took a look at Obvious Architecture (http://obvious.retromocha.com). It's a working implementation of his ideas in Ruby, but the same structure can easily be done in any OO language. Actually, the implementation would be a lot easier in a language like Go or Scala that has things like type checked interfaces built in.

I encountered a similar argument in Clean Architecture by Robert Martin of correctness vs maintainability, where he argues for maintainability over correctness. The argument goes that if you had to choose between code that did the wrong thing but was easy to make do the right thing, and code that does the right thing but is hard to change, you should always pick the former.

He also talks more abstractly about the value of software (as opposed to hardware for instance) being primarily in its "soft"-ness, or ease of changing.

Ultimately this comes from his point of view as an architect, who fights more for system design than say, a PM might for user features. I've encountered the opposite school of thought that says: MVP to deliver features, refactor/rewrite later. I think the strategy to use will depend on the project and team (budget, certainty, tolerance for failure, etc)

I agree with you up to the point of RPC calls. In general it doesn't matter what specific technology is used, as long as each data source is structured around the use-case and not around backend details like how entity models are actually stored. A lot of these ideas are captured well by Robert Martin ("Uncle Bob") in his book Clean Architecture

I spent some time in Web Apps between video game jobs. I got into some tense conversations where I, as manager, recommended against the abstraction layers the Senior Developer was trying to explain to the team on a whiteboard.

He said something like "Why do all the game developers write code like that?".

He handed me Uncle Bob's Clean Architecture. Uncle Bob is something of a meme to me. I read the book and couldn't figure out how to explain how I thought this style was inferior to what I had done in games before.

Ive been thinking about that ever since it happened. How could I explain to this guy my programming philosophy?

Last night, back in games, after refactoring the same piece of layout code for several hours, I finally arrived at the irreducible, simple, clean result that I wanted. I slotted it into our code base, and mentally noted how I would onboard the team to it on Monday, and how they would instantly understand because the resultant code is so simple. Then it came to me:

"Unit Tests are like pouring concrete on your code base."

Same goes for using "the wrong abstraction". Sometimes you want concrete to encase your precious technology. The problem is when people are writing sub par code, then they pour all this concrete on it via Unit Tests, Inheritance and Abstraction Patterns. It can become harder to improve the core logic of the system if it's distributed across many files, and enshrined in Unit Tests.

I've dedicated over 10 years to coding, and only now do I think I can write clean code that is worth encasing in concrete. I think there might be a general flaw in the idea that everyone should be writing tests. I'm not certain about this, it's just my general intuition based on my experience.

They are pros and cons to every design decision. I acknowledge that they are many pros to these kinds of designs, I'm just enumerating some cons that have arisen from my experience.

I found Clean Architecture to be a big disappointment. I specifically waited for its release to read all of his architecture-related advice in one volume, and then found that most of the meat was in figures and diagrams which I couldn't follow because of my visual impairment. I realise that's not entirely Uncle Bob's problem, but all the way through the book I was telling myself that it would be worth it once I reached the case study in chapter 33. At which point he zoomed through a use case and architecture diagram and called it a day.

Good books have figures. The best books have figures and textual explanations to go with them.

Here are some books, talks and papers that I've found really influential:

Clean Architecture (https://www.amazon.com/dp/0134494164) - Uncle Bob has been talking about this for years, but it's a really good exploration of how to build systems.

Turning the Database Inside Out is a talk that really made Apache Kafka and stream processing click with me. https://www.confluent.io/blog/turning-the-database-inside-ou...

Going through and implementing the Raft algorithm was also very formative for me - it's the first time I really started to grok the challenges with building large scale distributed systems. https://raft.github.io/

And to add a paper to the list to not totally go off topic - Birrell's paper "An Introduction to Programming with Threads" I thought was a very useful read - in part for the historical context, but he also breaks down many fundamental concepts that will look very familiar to the modern reader (it was written nearly 30 years ago).
It's also very readable. https://birrell.org/andrew/papers/035-Threads.pdf

As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility.

Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half-aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned.

The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle.

The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.

Sci-fi

- Ready Player One

- Pattern Recognition

- Burning Chrome

- Do Androids Dream of Electric Sheep?

- Hyperion

- A Fire Upon The Deep

Technical (backend development + security)

- HTTP: The Definitive Guide

- RESTful Web Services

- Designing Data Intensive Applications

- Web Scalability for Startup Engineers

- The Art of Software Security Assessment

- The Web Application Hacker's Handbook

- A Philosophy of Software Design

- Clean Architecture

- The Go Programming Language

- Refactoring (new 2nd edition)

- Algorithm Design Manual

- Cracking The Coding Interview

I'll definitely be able to get through all the sci-fi novels, but not the technical stuff. At minimum I need to go through the technical interview prep books, refactoring, and designing scalable applications.