Breaking Down Matrix Reshape with LeetCode

𝗗𝗮𝘆 𝟰 | 𝗦𝘁𝗮𝗿𝘁𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝗹𝗼𝗴𝗶𝗰 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 Today I moved into conditionals, which is where coding starts involving actual decision-making. 𝗧𝗼𝗽𝗶𝗰𝘀 𝗰𝗼𝘃𝗲𝗿𝗲𝗱: 💠 if statements 💠else statements 💠elif statements 💠 Writing simple condition-based programs Practicing small examples helped me understand how different conditions affect the output. It also made me realize that writing logic clearly is not as straightforward as it looks and requires consistent practice. #PythonLearning #Conditionals #LogicBuilding #DataAnalysis #CodingJourney

Ever wondered why some codebases scale smoothly… while others collapse under small changes? The difference is often SOLID principles not just theory, but practical habits that separate messy code from maintainable systems. Here’s a simple way to think about them S — Single Responsibility One class = One job E.g Like a chef who only cooks, not billing, not delivery. O — Open/Closed Open for extension, closed for modification E.g Add new features without breaking existing code. L — Liskov Substitution Subclasses should behave like their parent E.g If a “Bird” can’t fly (like a penguin), rethink your design. I — Interface Segregation Don’t force unnecessary methods E.g A printer shouldn’t be forced to “scan” or “fax”. D — Dependency Inversion Depend on abstractions, not concrete implementations E.g Your switch should work with any bulb, not just one type. In real projects, following SOLID means: Easier debugging Faster feature development Cleaner architecture Less fear of change Most developers know SOLID… but very few actually apply it consistently. Which SOLID principle do you struggle with the most in real projects? #SOLIDPrinciples #CleanCode #SoftwareEngineering #SystemDesign #CodingBestPractices

🚀 Day 18 of 100 Days LeetCode Challenge Problem: Count Submatrices with Top-Left Element and Sum ≤ k Today’s problem is a clean application of 2D Prefix Sum (Cumulative Sum) 🔥 💡 Key Insight: All valid submatrices must: Start from the top-left corner (0,0) Extend to any cell (i, j) 👉 So instead of checking all submatrices, we just: Compute sum from (0,0) to (i,j) Check if it’s ≤ k 🔍 Core Approach: 1️⃣ Build Prefix Sum Matrix prefix[i][j] = sum of all elements from (0,0) to (i,j) 2️⃣ Iterate Through Grid For every (i, j): If prefix[i][j] ≤ k → count it ✅ 👉 That’s it! No need for complex nested submatrix checks 🚀 🔥 What I Learned Today: Constraints simplify problems → use them wisely 2D prefix sum reduces O(n⁴) → O(n²) Always check if the problem has a fixed starting point 📈 Challenge Progress: Day 18/100 ✅ Almost 20 days consistency! LeetCode, Prefix Sum, Matrix, 2D Arrays, Optimization, Algorithms, DSA Practice, Coding Challenge, Problem Solving #100DaysOfCode #LeetCode #DSA #CodingChallenge #PrefixSum #Matrix #ProblemSolving #TechJourney #ProgrammerLife #SoftwareDeveloper #CodingLife #LearnToCode #Developers #Consistency #GrowthMindset #InterviewPrep

Building Software That Lasts: The SOLID Principles 🚀 Writing code is one thing; maintaining it for years is another. If you want to avoid "spaghetti code" and build scalable projects, the SOLID principles are your best friends. Here is a simple breakdown: 🔹 S – Single Responsibility One class, one job. A policeman shouldn't be your structural engineer. Keep your modules focused to keep them organized. 🔹 O – Open-Closed Your code should be open for extension but closed for modification. You should be able to add a new wheel to a car without cutting the entire body open. 🔹 L – Liskov Substitution Subclasses must be able to replace their parent classes without breaking anything. If a "Lion" eats meat, a "Lion Cub" should too—not suddenly switch to grass. 🔹 I – Interface Segregation Don't force a client to use methods they don't need. If someone just wants a coffee, don’t make them sign a contract for the entire bakery. 🔹 D – Dependency Inversion Depend on abstractions, not concretions. High-level logic shouldn't be "married" to a specific database or language. Stay flexible. 📌 The Takeaway: SOLID isn't just theory; it’s the art of building clean, elastic architecture that survives the test of time. #coding #programming #webdev #softwareengineering #solid #cleancode

Lagging editors. Messy syntax. Slow builds. We built something better. Introducing Grind's Pro-Grade Coding Editor — write clean data structures with intelligent syntax highlighting and zero lag. Code faster. Think clearer. Build better. Try it at grind.org.in

Ever read code that's technically "clean" but still hard to follow? Sometimes the issue isn't correctness or style. It's clarity of intent. How the code communicates what it's doing, and why. That's the idea behind narrative code: writing software that doesn't just function well, but reads like a coherent story — clear roles, meaningful flow, and structure that makes reasoning easier. At MiXiT on April 17th, Sandrine Banas will explore how this works in practice, from recurring narrative patterns and "characters" inside methods, to writing techniques that make code more expressive, and even how to think about a proper epilogue in software design. Learn more about the talk: https://hubs.la/Q04ccHV20 Can't make it? The Art of Code goes deeper into these ideas. Get it at 45% off with code mixit26 through May 2nd: https://hubs.la/Q04ccQKS0

𝗧𝗵𝗲 𝗣𝗼𝘄𝗲𝗿 𝗢𝗳 𝗔𝗕𝗦𝗧𝗥𝗔𝗖𝗧 𝗦𝗬𝗡𝗧𝗔𝗫 𝗧𝗥𝗘𝗘𝗦 You write code. But what happens next? You write a line of code like this: a = 2 + 3 \* 4. It looks simple. But machines see it differently. They convert your code into an Abstract Syntax Tree \(AST\). This is a structured representation that defines how your program runs. - Each node in the AST represents an operation or value. - Relationships define the execution order. For example, the code a = 2 + 3 \* 4 becomes a tree-like structure: = / \ a + / \

A lot of advice on code readability focuses on style. I think the deeper issue is simpler: when you open a piece of code, can you understand the scenario before you run into the implementation details? I’ve read plenty of code that technically worked, but still made simple things harder to follow than they should be. Over time, I realized the problem is often not the complexity itself. It’s that the code leads with low level mechanics instead of intent. I wrote a short piece about this idea: code should expose meaning first and implementation second. Here: https://lnkd.in/d4B7hpgp #SoftwareArchitecture #CleanCode #SoftwareDesign #DomainDrivenDesign

I started a GitHub repo to document my Low-Level Design journey, and I'm building it in public. So far I've built: → Document Editor, designed from scratch with OOP principles → GenAI Document Summarizer, LLD for an AI-powered summarization system Each design focuses on clean class structures, design patterns, and the trade-offs behind every decision. The goal? Build a solid reference for anyone preparing for LLD interviews or wanting to write better, more scalable code. https://lnkd.in/gzY_4bJ6 I'm just getting started, and this is where you come in 👇 What should I design next? Drop a suggestion in the comments. I'll pick the most upvoted one and publish it this week. #LowLevelDesign #SystemDesign #ObjectOrientedDesign #SoftwareEngineering #BuildingInPublic

How can you improve the quality of your code? Start with the SOLID. The acronym stands for: 1️⃣ Single Responsibility Principle: A class should have only one reason to change. 2️⃣ Open/Closed Principle: Code should be open for extension but closed for modification. 3️⃣ Liskov Substitution Principle: Subtypes must be substitutable for their base types. 4️⃣ Interface Segregation Principle: Clients should not be forced to depend on methods they do not use. 5️⃣ Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions. I revisit these principles once a month, just to stay in the loop. And during my career, they have helped me write clean code. I also broke them countless times because of pragmatism. But the key takeaway here is to strive to write code that is: - Easy to understand - Easy to maintain - Easy to improve