Bloat happens when programmers don't care about (or don't understand) what code actually does and what the tradeoffs down the line are going to be. Bloat happen

Bloat happens when programmers don't care about (or don't understand) what code actually does and what the tradeoffs down the line are going to be. Bloat happens when code is produced cheaply and quickly. Bloat happens when there is a cultural stereotype that having produced a bloated piece of code means you're smart. Bloat is not the same as complexity, but they are related. Bloat is not always bad, or even perceivable as such by the consumer of the code, but at the same time it's also never good. Bloat is a natural accumulation tradeoff decisions. Anybody who writes code produces bloat, because writing software is an exploratory activity towards solving a problem set. There is no way to always know where the bottlenecks are going to be, and where your chosen abstractions will break down. The difference between doing good work and bad is that the programmer doing good work will revisit decisions and refactor things ruthlessly down the line. The programmer doing bad work simply doesn't care, is too pressed for time, or writes code in a way that makes refactoring prohibitive. Personally, I think a good litmus test for bloat is how much the code you're writing actually achieves for the effort you put into it. If you find yourself constantly massaging and circumventing the limitations of your boundary layers, that's a big warning sign. If you are using a library or framework that prolongs and complicates the effort of solving your problem compared to the expected effort of doing it from scratch, then that library is clearly not useful. Using it regardlessly is a deficiency in the critical thinking required to make good decisions in programming.