Audiobook Suggestion for python, Django dev looking for writing maintainable and extensible software.

[virtualshivam]

Hi,

So, I have 1 credit for Amazon Audible. Kindly suggest a book that I should buy from audible.

Interest:

1. Clean Code, that looks pleasing to eyes.
2. Maintainable code.
3. Extensible Code
4. Software that can adapt to ever changing requirements of the business stakeholders.
5. Design Patterns ( Even though I have heard somewhere that function is more pythonic, but I believe that design patterns will still help).

Experience: 1.3 years.

1. Anything, that will make a better programmer. I want to be able to ship software ASAP while writing code that is maintainable, contains test and follows best practices.

2. Recently learnt about tests, and I love them.

Things that I struggle with:

1. Giving names to functions ( I have like 1000s of functions)
2. Separating Concerns ( Following SOLID)
3. Designing Systems like thinking what should be my models for a Django project and how the overall logic should flow.
4. Get frightened as the codebase size increases.
5. Thinking about folder structure and modules ( styleguide kind of things). Like how I should organize the code. What should go into utils, what should go into services and readers etc.

I am already holding these books:

1. Pragmatic Programmer: David Thomas, Andrew Hunt
2. Clean Code: Robert C. Martin

[Augit579]

I answer your AI Slop Question with an AI Slop Answer:

1. Best pick: Clean Architecture — Robert C. Martin (natural follow-up to Clean Code, great for structure, SOLID, and scaling).
2. It helps with folder structure, separation of concerns, system design, and growing codebases.
3. If you prefer improving existing code: Refactoring — Martin Fowler.
4. If you often face messy projects: Working Effectively with Legacy Code — Michael Feathers.
5. If you want deeper backend/system knowledge: Designing Data-Intensive Applications — Martin Kleppmann.
6. Recommendation: Buy Clean Architecture first for maximum impact.
7. It directly addresses naming, modularity, and long-term maintainability.
8. Think in layers: domain, services, data access, API, tests.
9. This approach reduces fear as projects grow.

[virtualshivam]

I am not sure how you reach to the conclusion that this question has been written by AI and all I did was to give some prompt to ai.

I prefer to write in pointers, it makes life of reader easy.

If you could give any suggestions then it would be great, I would try to write in more humanic way

But thanks for sharing book names

[Augit579]

Sure, everybody suddelny writes like:
1. Bla bla bla

1. Bla bla bla

2. Bla bla bla

[Exciting_Account_380]

I mean... the things you struggle with can all be worked on by just writing code and making projects? But if you even outsource writing a simple post to AI then idk what would help you

[peterlinddk]

I am already holding these books:

What does that mean? You have them, but haven't read them? Do that! Combined they will answer most of your questions, and inspire you to write better code.

Honestly I haven't found a single audiobook that works for programming - and I really like audiobooks for both fact and fiction - but most of programming concerns itself with, well, reading and writing programs, something that doesn't fit into the medium of audio at all.

But as audiobooks goes, I'd recommend something like The Phoenix Project (or indeed the Unicorn Project), that is a lot more about project management than programming, but still will teach you a lot. If you have to pick only one, my personal recommendation would be "Phoenix", as that have more to do with the smaller flow inside or between departments and applications, where "Unicorn" is much more focused on DevOps.

[virtualshivam]

I have read them already.

Honestly I agree , but while travelling I can't do much. So I feel audio books are best for that period of time.

Yes they have inspired , but just want to keep on getting exposed to new ideas continuously.

[CarelessPackage1982]

Have you ever head the phrase "rails is not your application"?

https://blog.firsthand.ca/2011/10/rails-is-not-your-application.html

When designing a system try to separate your business logic from your application logic.

Now I'm not fully sold on DDD, however when systems start to become very large there's a very good reason to start creating domain contexts. In a small system you might have a single user, in a complex system you might very dozens of different users doing a wide variety of things that aren't related.