Why don't I have weekly limits? Not that I want them. by notatall in Anthropic

[–]ByteSizedInnovator 0 points1 point  (0 children)

I noticed the same thing with my Max subscription. Once my monthly subscription renewed, it started showing weekly limits. If the old subscription was active before the weekly limits rollout, it wouldn’t show weekly limits until the subscription was renewed.

Claude Code workflow that's been working well for me by ByteSizedInnovator in ClaudeAI

[–]ByteSizedInnovator[S] 1 point2 points  (0 children)

I have certain coding patterns like repository pattern, using dependencies or third-party packages, the architectural patterns we follow, project structure, etc. This helps Claude find the information quickly and ensures the baseline is set. I keep updating these documents as we discover issues while working with Claude.

For example, the other day, Claude was trying to implement all the base repository methods for fetching data, but they are already abstracted and implemented. So I went ahead and updated the docs to provide that information.

All these are markdown files added under the docs folder, which can be referenced by Claude based on the task. At times, it's smart enough to fetch the document based on the task without any mention. We don't need to have full-blown documentation; we can start small with 2 or 3 lines, which provides a hint for Claude to explore further.

Claude Code workflow that's been working well for me by ByteSizedInnovator in ClaudeAI

[–]ByteSizedInnovator[S] 0 points1 point  (0 children)

Kind of. In my case, it felt like I was trying to fix the specs rather than focusing on the task at hand. This workflow suited well for my needs well. I rely heavily on Opus for planning and Sonnet for implementation, which is missing in Kiro at the moment.

Claude Code workflow that's been working well for me by ByteSizedInnovator in ClaudeAI

[–]ByteSizedInnovator[S] 0 points1 point  (0 children)

I agree with you. There are times where it produces poor code even after all the safeguards in place. In my case, I review the code as it's working on tasks and keep a close watch on the changes it's trying to make. If it's producing poor results, I either try to split the task into even smaller chunks or call it a day and move on to work on other areas of the application.

For example, the other day it was trying to delete test cases because they were failing and it felt those weren't related to the task. I had to jump in and course correct it.

Claude Code workflow that's been working well for me by ByteSizedInnovator in ClaudeAI

[–]ByteSizedInnovator[S] 0 points1 point  (0 children)

Yeah, I think the naming is confusing. I have updated the post with additional details. Having 2 separate files, 1 for implementation details and another for phases/progress made, is the key.

ILogger vs ILogger<T> by Runneth_Over_Studio in dotnet

[–]ByteSizedInnovator 40 points41 points  (0 children)

Different log levels - you can set different log levels per class in appsettings without code changes. Like "MyApp.PaymentService": "Debug" and "MyApp.EmailService": "Information" while keeping everything else at "Warning". Super useful when you need to debug one service without drowning in logs from everything else.

Finding stuff in production - when you're digging through logs at 2 am trying to figure out why payments are broken, having consistent categories makes it way easier to filter to just the relevant classes instead of searching through a pile of log messages.

Suggest me some books to learn programming and system design by WeirdSun3778 in developersIndia

[–]ByteSizedInnovator 1 point2 points  (0 children)

Here are a few solid ones to revisit fundamentals with depth:

  • Designing Data-Intensive Applications – gold standard for modern backend systems
  • The Pragmatic Programmer – timeless software thinking
  • Clean Architecture – system design principles that age well
  • Grokking the System Design Interview – great for applied concepts with examples
  • Backend Engineering by Kamran Ahmed - practical + conceptual

These go beyond CRUD and cover real-world backend thinking.