SOLID principles for clean code: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion

🚀 I built an open-source library of Claude Code rules & skills to keep AI-assisted development consistent across all my projects. The problem: every time I started a new project, I was re-explaining the same conventions to Claude — Clean Architecture, SOLID, idiomatic Go, PEP 8, React hooks rules… over and over. The solution: my-rules-skills — a single .claude/ folder you drop (or symlink) into any project. Claude Code automatically picks up the rules and skills from there. What's inside: 📐 Shared rules (apply to every language) Clean Code (Uncle Bob) SOLID principles enforcer Object Calisthenics ⚙️ .NET — Clean Architecture with Brighter/Darker, Minimal API, C# conventions 🐹 Go — Effective Go + Google Style Guide: naming, concurrency, error handling, project structure 🐍 Python — PEP 8/257/20, type hints, logging, src layout, pyproject.toml + uv ⚛️ React — Component purity, hooks rules, feature-slice architecture, React Query, TypeScript Each language also ships with a skill — a step-by-step workflow Claude follows when you say "add a new feature", automatically covering domain → service → repository → handler → tests. How it works: # Drop it into any project (or symlink to keep rules in sync) ln -s ~/my-rules-skills/.claude ./. claude Rules activate automatically based on file type. Skills are invoked by name or by describing what you want to do. It's agnostic, extensible, and completely free. Add your own rules in Markdown — no config, no build step. 👉 https://lnkd.in/d-3uNxaf Would love to hear how others are managing Claude Code conventions across projects. Are you doing something similar? #ClaudeCode #AI #DeveloperTools #SoftwareEngineering #CleanCode #SOLID #dotnet #golang #Python #React #OpenSource

𝐓𝐡𝐞 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 𝐰𝐡𝐨 𝐰𝐫𝐨𝐭𝐞 𝐭𝐡𝐢𝐬 𝐜𝐨𝐝𝐞 𝐥𝐞𝐟𝐭 8 𝐦𝐨𝐧𝐭𝐡𝐬 𝐚𝐠𝐨. 𝐍𝐨𝐰 𝐢𝐭’𝐬 𝐲𝐨𝐮𝐫 𝐩𝐫𝐨𝐛𝐥𝐞𝐦. 𝐍𝐨 𝐜𝐨𝐦𝐦𝐞𝐧𝐭𝐬. 𝐍𝐨 𝐝𝐨𝐜𝐬𝐭𝐫𝐢𝐧𝐠𝐬. 𝐍𝐨 𝐑𝐄𝐀𝐃𝐌𝐄. 𝐉𝐮𝐬𝐭 400 𝐥𝐢𝐧𝐞𝐬 𝐨𝐟 𝐥𝐨𝐠𝐢𝐜 𝐚𝐧𝐝 𝐚 𝐩𝐫𝐚𝐲𝐞𝐫. We talk about clean code. We talk about good architecture. Nobody talks about documentation. Here’s the truth: Code is written once. It’s read hundreds of times. By teammates. By future hires. By you, 6 months from now. Documentation isn’t for now. It’s for the moment someone has to touch your code at 11pm before a deployment. Will they understand it? Or will they guess? 𝐓𝐡𝐞 𝐦𝐢𝐧𝐢𝐦𝐮𝐦 𝐞𝐯𝐞𝐫𝐲 𝐜𝐨𝐝𝐞𝐛𝐚𝐬𝐞 𝐧𝐞𝐞𝐝𝐬: 1. README → What is this? How do I run it? 2. Docstrings → What does this function do? What does it return? 3. Inline comments → Why was this decision made? 4. Changelog → What changed and when? Not perfect docs. Just enough context to not be helpless. The best comment I ever read wasn’t explaining what the code did. It explained why a weird workaround existed. One line saved hours of confusion. 𝐔𝐧𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐞𝐝 𝐜𝐨𝐝𝐞 𝐢𝐬𝐧’𝐭 𝐣𝐮𝐬𝐭 𝐚 𝐭𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐝𝐞𝐛𝐭. It’s a people problem. Someone will inherit what you write today. Document like they’re a stranger. Because eventually they will be. #Django #Python #BackendDevelopment #SoftwareEngineering #CleanCode #WebDevelopment

I open-sourced 𝗱𝗲𝗰𝗸 — think docker-compose, but for your whole local dev stack, not just containers. It started as a Makefile + shell scripts I built for onboarding a Go+React monorepo — postgres, keypair generation, DB setup, migrations, services with log tailing and cleanup. One command to start everything. Worked well, totally hardcoded to one project. I looked at the result and thought: this should be a real tool. 𝗱𝗲𝗰𝗸 𝘂𝗽 — one YAML config, one command: • Deps with multi-strategy fallback (docker → brew → whatever) • Idempotent bootstrap with interactive prompts for first-time setup • Service dependencies with readiness checks (depends_on + ready) • Env vars from strings, shell scripts, or structured files (JSON/YAML/TOML/INI) • Colored log tailing, crash recovery with auto-restart • deck.local.yaml for personal overrides — you use docker, I use brew Also: deck doctor to diagnose your stack, deck run api -- goose up for one-off commands in a service's context, selective targeting (deck up api webapp), and stack-aware deck init that detects your project type. Single Go binary, ~2500 LOC, 7 releases. Available via Homebrew. Built with Claude Code handling implementation and Codex running execution and review passes on chunks of work. I focused on design and architecture. Honest take: the velocity is wild, but you still need to know what you're building and catch what it gets wrong. Named after the cyberdeck from Shadowrun 🤖 https://lnkd.in/dRhUvhg3

Claude Code's source code leaked yesterday. 512,000 lines of TypeScript, now public. I went through it and extracted the architectural patterns that show up consistently across the codebase — the engineering decisions behind how it works. A few examples: Every tool throws a typed error on failure — never returns { success: false }. The framework catches it and formats it for the LLM. The tool has one job: do the work or throw. One schema definition drives both TypeScript types and JSON validation. They share one source and can never drift. Concurrency safety is evaluated per invocation, not declared statically. Same tool, different answer depending on the input. Packaged all 16 as portable skill files that load automatically into Claude Code, Cursor, Gemini CLI, Codex, and OpenCode. Zero config. MIT license. → https://lnkd.in/d6nQvdGf #AIEngineering #ClaudeCode #DeveloperTools #OpenSource

🚀 Stop blindly using @Autowired on fields. It works… but it’s NOT the best way. Let’s understand why 👇 👉 There are 3 ways to inject dependencies in Spring: 1️⃣ Field Injection 2️⃣ Setter Injection 3️⃣ Constructor Injection ✅ (Recommended) --- 💡 Most beginners do this: @Service public class OrderService { @Autowired private PaymentService paymentService; } ❌ Problems: - Hard to test (no control over dependency) - Hidden dependencies - Breaks immutability --- ✅ Better approach → Constructor Injection: @Service public class OrderService { private final PaymentService paymentService; public OrderService(PaymentService paymentService) { this.paymentService = paymentService; } } ✔ Dependencies are explicit ✔ Easy to write unit tests ✔ Ensures immutability --- 🔥 Bonus (Spring Boot magic): If a class has ONLY ONE constructor → You don’t even need @Autowired 😮 Spring automatically injects it! --- ⚡ Real-world impact: In large projects: - Field injection → messy & hard to debug - Constructor injection → clean & maintainable --- ❌ Common mistake: Using @Autowired everywhere just because it’s easy --- 📌 Key Takeaway: “Convenience is not always best practice.” Always prefer Constructor Injection for clean and testable code. --- Follow for more real backend learnings 🚀 #SpringBoot #Java #CleanCode #BackendDevelopment #SoftwareEngineer

There’s been a lot of chatter recently about a coding agent #claude #sourcecode showing up publicly on GitHub and probably got cloned. Not going to speculate on whether it was accidental or intentional. That’s not really the point. What this highlights is something more fundamental.They are “probably” acting on goals. And that changes how we need to think about architecture. In a traditional system, if something goes wrong, you trace the logic and fix it. It’s mostly deterministic. In an agent-driven system, the system is interpreting intent. That interpretation can vary. That’s where things get interesting, and risky. A couple of things become very important here. First, you need a closed loop. You can’t just let an agent run and hope for the best.There has to be constant checking, feedback, and correction. The system needs to observe what it did, validate it, and adjust. Without that, small deviations can turn into big outcomes very quickly. Second, deterministic and non-deterministic layers need to work together. The reasoning part of the system can be flexible.That’s where the value comes from. But the boundaries cannot be flexible.Access control, policies, limits, what is allowed and what is not, all of that has to be very clearly defined and enforced. A lot of current implementations are strong on the reasoning side, but weak on the control side. That works in demos, not in real environments. Third, intent is not the same as execution anymore.You might ask for something in a certain way, but what the system actually does depends on how it interprets that intent. That gap is where most of the risk sits. If anything, this is a good reminder. We are no longer just building systems that do what we tell them. We are building systems that decide how to do what we tell them. And the real question is not just what the system can do. It is what it should never be allowed to do. https://lnkd.in/gGqPcD6e

🚀 #100DaysOfCode – Day 17 Consistency is turning into confidence. Showing up daily 🔥 ✅ What I accomplished today: 🧠 LeetCode Daily Challenge – XOR After Queries 📌 Problem Overview: You are given an array and a list of queries. Each query contains: left, right → range k → step increment value → multiplier 👉 For each query: ✔ Update elements from left to right with step k ✔ Multiply each selected element by value Finally, compute the XOR of the entire array 💡 My Approach (Simulation): 🔹 Iterated through each query 🔹 For every query: ✔ Started from left ✔ Jumped with step k until right ✔ Applied multiplication with modulo (10^9 + 7) 🔹 After processing all queries: ✔ Calculated final XOR of array ⚡ Time Complexity: 👉 O(Q * (N / K)) in worst case ⚡ Space Complexity: 👉 O(1) 🧩 Key Insights: ✔ Step-based traversal reduces unnecessary operations ✔ Careful handling of large numbers using modulo ✔ XOR aggregation at the end is straightforward but important ✔ Simulation works, but optimization scope exists (future improvement 🚀) 🔗 LeetCode Submission Link: https://lnkd.in/gZKCZf87 ☕ Spring Boot Learning – Lambda & Stream API Today I explored one of the most powerful features in modern Java 💡 📌 Key Concepts Covered: ✔ Introduction to Lambda Expressions ✔ Writing concise and readable functional code ✔ Using Stream API for data processing ✔ Performing operations like: filter() map() forEach() collect() ✔ Converting collections into streams for clean transformations 🌍 Why This Matters: ✔ Reduces boilerplate code ✔ Improves readability and maintainability ✔ Encourages functional programming style ✔ Makes data processing more expressive and efficient 🧠 Big Learning: Writing less code doesn’t mean doing less— it means writing smarter, cleaner, and more expressive code. 🔥 Learning Streak: Day 17/100 Discipline today → Results tomorrow 🚀 #100DaysOfCode #Java #SpringBoot #BackendDevelopment #LeetCode #DSA #ProblemSolving #CodingJourney #SoftwareDevelopment #LearningInPublic #Developers #Consistency #BuildInPublic

Coding agents generate code like there is no tomorrow. Soon enough, they struggle under the weight of what they created. AI writes a new helper instead of reusing an existing one. Old functions stay around because tests still call them, even though production does not. The codebase grows, but the agent's ability to reason about it does not. On bigger projects, especially ones that have been heavily vibe-coded, this turns into chaos. The problem is not just messy code. It is slower reviews, weaker trust in the codebase, and agents that get less reliable as the surface area grows. We have put a lot of energy into making code generation faster. I think the next thing to get right is safe code removal. There is a reason senior engineers get excited about deleting code. It is a bit like never throwing away clothes you no longer wear. It seems fine at first. Then one day, you have five versions of everything, and finding what you actually need means digging through closets you forgot existed. I built a Claude Code skill to help with this. It gives Claude a methodology for dead code removal: classify what you are looking at, verify the cases static tools miss, and avoid drifting into refactor territory while you are in there. It is tuned for Python and TypeScript, but should be easy to adapt. Clone it, fork it, open a PR if you improve it. https://lnkd.in/ds5AcC5U #CodingAgents #CodeQuality

We analyzed 790 CLAUDE.md files from GitHub. Not hand-picked examples. Real files from real repos — C++, Go, Python, TypeScript, Terraform, Rust, and 4 non-English languages. Here's what the data actually says: Structure convergence is real. → 65% of multi-section files start with Identity then Commands → 92% use code blocks (the single most consistent pattern across all domains) → The canonical structure: Identity → Commands → Architecture Brevity correlates with quality. → Median file: 4,536 characters (~100 lines) → Files under 5K chars pass quality assessment at 2x the rate of files over 8K → 86% stay under 300 lines → The 14% that exceed it are project diaries or status trackers, not config files What surprised us most: → MUST/NEVER emphasis markers are rare — under 10% of files use them (our smaller sample had overestimated this) → Non-English files (11% of corpus) follow identical structure patterns — the template is language-agnostic → The highest-scoring file is just 63 lines and 2,502 characters (a Go CLI tool) What developers actually put in CLAUDE.md: → 54% lead with project identity → 30% put commands second → 18% include naming/style conventions → 14% have formal constraint sections The takeaway that surprised me: The best CLAUDE.md files look nothing like comprehensive documentation. They look like a one-page cheat sheet a senior dev would hand a new team member on their first day. Short. Specific. Structured. The worst files read like READMEs, project diaries, or wish lists of how they want AI to behave. What does your CLAUDE.md look like — a cheat sheet or a diary? #AIEngineering #DataDriven #ClaudeCode #DeveloperExperience #CodingAssistants

𝐘𝐨𝐮𝐫 𝐃𝐨𝐜𝐤𝐞𝐫 𝐁𝐮𝐢𝐥𝐝 𝐖𝐨𝐫𝐤𝐞𝐝 𝐘𝐞𝐬𝐭𝐞𝐫𝐝𝐚𝐲. 𝐓𝐨𝐝𝐚𝐲 𝐈𝐭 𝐅𝐚𝐢𝐥𝐬. [Docker Deep Dive — Day 3/5] It is a common question in interviews how you will approach this situation. You changed nothing. Same Dockerfile. Same code. But the build crashes. The culprit? Your cargo manifest has no quantities. Every Docker build fetches dependencies fresh. If you write RUN pip install requests, Docker grabs whatever the latest version is that day. Today that version conflicts with your other packages. Your ship sinks at the dock. A cargo ship loads hundreds of crates. The manifest says "50 boxes of bolts." Without a size specification, the port loads whatever bolt size arrives first. One wrong crate and the engine cannot be assembled. Version pinning is your exact specification. requests==2.28.2 means only that bolt, that size, every single time. dockerfile # Unpinned — dangerous RUN pip install requests numpy opencv # Pinned — safe, reproducible COPY requirements.txt . RUN pip install -r requirements.txt text # requirements.txt requests==2.28.2 numpy==1.24.0 opencv-python==4.7.0.72 𝐅𝐀𝐐: Q: How do you handle a dependency conflict? Check which package demands which version. Update the library that has flexibility, pin everything explicitly, rebuild. Q: What are Linux package issues inside containers? Base images like python:3.11-slim strip non-essential packages. If your app needs libpq or gcc, add RUN apt-get install explicitly — otherwise the crate simply does not exist on board. Q: Why redeploy after fixing a dependency? The image is already baked wrong. Fix the Dockerfile, rebuild the image, redeploy the container. No patch reaches a running ship mid-voyage. Tomorrow: Docker Swarm vs Kubernetes — why did the whole industry switch? #DevOps #Docker #Dependencies #Containers #DevOpsInterview #CloudEngineering #DockerDeepDive