Day 31 Backend Dev Journey: LeetCode Breakthrough and System Design

🚨 I stopped loading all data at once today… and my API got smarter. Day 24 of my Backend Journey — and this is where things started feeling real-world 👇 🧠 LeetCode Learning Solved LeetCode 2515. Shortest Distance to Target String in a Circular Array 💡 What clicked: → Circular traversal thinking → Checking both directions (forward & backward) → No extra space needed ⚡ Smart iteration > complicated logic 🔗 My Submission:https://lnkd.in/gja7CGPS ☕ Spring Boot Realization Today I learned Pagination using Spring Data JPA 👉 Page = chunk of data 👉 Pageable = pagination config 👉 PageRequest = implementation Instead of loading everything: ✔ Fetch only what’s needed ✔ Add sorting + pagination ✔ Build scalable APIs 🧠 The Shift 👉 Backend is not just about working code 👉 It’s about efficient data handling Small changes like pagination = big impact in real apps 📘 Spring Boot Notes: https://lnkd.in/gRgxP7Th 📈 Day 24 Progress: ✅ Better API design understanding ✅ Improved problem-solving approach ✅ Thinking like a backend engineer 💬 Do you prefer writing optimized code first, or refining later? 👇 Let’s discuss #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney

I built something a bit unusual, and I’m not entirely sure how to introduce it without sounding like every other “AI will change everything” post… so I’ll just explain what I actually did. Over the past years working on business applications (especially in insurance), I noticed that a large part of the codebase is not really “logic” in the traditional sense. It’s forms. And behind those forms: endless rules, conditions, validations, and document generation. At some point, it starts to feel like we are just translating domain documents into code, line by line, with a lot of if/else along the way. So I built a small demo to explore a different approach. Instead of hardcoding the form, the application takes a description of a context, uses AI to generate relevant questions step by step, validates the input dynamically, and finally produces a document (report/contract) as a PDF. It’s not a product. It’s not production-ready. It’s just a proof of concept to test an idea: what if forms were generated from intent instead of code? For this project, I also stepped out of my usual stack (C#/.NET) and built it using Java and Spring, partly as a technical exercise, partly because I’m currently exploring opportunities in the Java ecosystem. The application is not fully public (API costs are real), but I’m happy to give access if you’re curious. If you’re interested in the idea, or just want to take a look: 👉 https://csohaib.dev/ And if nothing else, at least now I have one less excuse to complain about forms.

I hit a strange realization today. Not a new concept. Not a new framework. Just something I’ve already used in production. But still… *I couldn’t explain it cleanly. We often say “I know this.” But do we really? Today’s trigger was a simple API design scenario in Spring Framework: 👉 Upload a file + send structured JSON data in the same request Sounds basic, right? But when I tried to break it down clearly— the *why*, the *how*, the *right annotation*— there was hesitation. --- Then the clarity came back: * `@RequestParam` → key-value inputs * `@PathVariable` → resource identity * `@RequestBody` → pure JSON payload * `@RequestPart` → **multipart boundary where file + structured data meet That moment reminded me of something deeper: > “Exposure creates familiarity. > But only articulation proves understanding.” In real systems, this gap shows up everywhere: * You’ve seen the pattern, but can’t justify it * You’ve fixed the bug, but can’t explain root cause * You’ve used the annotation, but don’t know *why it exists* At scale, this matters. Because senior engineering is not about: ❌ Writing more code It’s about: ✔ Explaining decisions clearly ✔ Designing with intent ✔ Debugging with first-principles thinkin --- **Today wasn’t about learning something new. It was about realizing what I hadn’t fully understood.** And that’s a different kind of progress. #SoftwareEngineering #Java #SpringBoot #SystemDesign #Backend #EngineeringMindset

🚨 I thought this was just grouping… but prefix sums changed everything. Day 32 of my Backend Developer Journey — and today was about 👉 turning brute force into math 🧠 LeetCode Breakthrough Solved today’s Daily Challenge using HashMap + Prefix Sum logic 💡 What clicked: → Group indices of same values → Use prefix sums to calculate distances efficiently → Avoid recalculating distances again and again ⚡ The real trick: 👉 Don’t compute distances individually 👉 Precompute and reuse calculations 🔍 Key Insight Instead of O(n²): 👉 Split into left + right contribution 👉 Use running sums ⚡ Optimized to O(n) 🔗 My Submission: https://lnkd.in/g9Dar9cq ☕ Spring Boot Learning 🔄 Cascading in JPA (Game Changer for Projects) Working on my Hospital Management System, I explored cascading 👇 👉 CascadeType.PERSIST 👉 CascadeType.MERGE 👉 CascadeType.REMOVE 👉 CascadeType.ALL ⚡ Why this matters 💡 Instead of manually saving related entities: 👉 Save parent → child automatically saved 👉 Delete parent → child automatically handled 🔥 Real Example 👉 Saving Patient → Insurance also gets saved 👉 Deleting Patient → related records handled automatically 🧠 The Shift 👉 Optimization = math + observation 👉 Backend = relationships + lifecycle management 👉 Projects teach more than theory ever will 📘 Spring Boot Notes: https://lnkd.in/gpWQvkyK 🔗 GitHub Repo https://lnkd.in/gWb8ZPdv 📈 Day 32 Progress: ✅ Learned prefix sum optimization ✅ Understood cascading deeply ✅ Improved real-world backend thinking 💬 Do you prefer solving problems using logic or math-based optimization? 👇 #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney #SystemDesign

🚨 This problem looked too simple… and that’s exactly why it was tricky. Day 27 of my Backend Developer Journey — and today reminded me: 👉 Simple problems test clarity, not complexity. 🧠 LeetCode Insight Solved today’s Daily Challenge 💡 What clicked: → Reverse the number → Compute absolute difference → Keep logic minimal ⚡ The takeaway: 👉 No extra data structures 👉 No overthinking 👉 Just clean execution 🔍 Key Insight 👉 Sometimes the problem is already optimal 👉 Your job is to not ruin it with over-engineering 🔗 My Submission:https://lnkd.in/gSP92U_8 ☕ Spring Boot Learning 🔗 JPA Relationships (Game Changer for Backend Design) Today I explored how entities connect with each other in real-world systems 👇 👉 @OneToOne – One entity ↔ One entity 👉 @OneToMany – One → Multiple 👉 @ManyToOne – Multiple → One 👉 @ManyToMany – Many ↔ Many ⚡ Why this matters 💡 Backend is not just APIs… It’s about how data is connected internally 👉 Proper relationships = cleaner DB design 👉 Better performance & maintainability 🧠 The Shift 👉 Not every day is about hard problems 👉 Some days are about discipline & clarity 👉 Strong fundamentals = long-term consistency 📘 Spring Boot Notes: https://lnkd.in/gpWQvkyK 📈 Day 27 Progress: ✅ Improved clarity in problem-solving ✅ Learned core DB relationship mapping ✅ Strengthened backend fundamentals 💬 Do you also overthink simple problems sometimes? 😄 #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney

𝗧𝗵𝗲 𝗯𝘂𝗴 𝘄𝗮𝘀𝗻’𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗰𝗼𝗱𝗲… 𝗶𝘁 𝘄𝗮𝘀 𝗶𝗻 𝘁𝗵𝗲 𝘀𝗼𝘂𝗿𝗰𝗲 As a junior developer, I used to believe most problems lived in code. Syntax errors. Logic mistakes. Missed edge cases. Fixable. Traceable. Debuggable. But then I faced something different. A report was wrong. Numbers didn’t match. Everything looked correct in the code. Hours passed… then days. Until I realized the issue wasn’t in the code at all. It was in the source. Code-level issues are frustrating, yes. But they follow rules. You can debug them step by step. You know where to look. Source-level issues? They don’t play fair. * Data might be incomplete * Fields may silently change * Upstream systems might break without warning * Assumptions you trusted… stop being true And the hardest part? Nothing crashes. Nothing errors. Everything just looks fine. That’s what makes source-level issues harder. They test more than your coding skills. They test your thinking. You stop asking: 👉 “What’s wrong with my code?” And start asking: 👉 “Can I trust the data I’m using?” This shift changed how I work. Now I don’t just write code. I question inputs. I validate assumptions. I look beyond the surface. Because sometimes, the real bug isn’t what you built… …it’s what you built on top of. #Learning #Debugging #DataEngineering #SoftwareDevelopment

My biggest shift as a developer: from writing code → designing systems. When I started building projects, I focused on features: “Add login”, “Add cart”, “Add posts”… But while working on projects like ShopEase and Sociocon, I realized something important: 👉 Good applications are not built by features — they are built by systems. 💡 What changed in my approach: Earlier: • Writing code for individual features Now: • Designing how components interact • Structuring APIs before implementation • Thinking about data flow and scalability ⚙️ Example (ShopEase): Instead of just “placing an order”, I designed: → Order pipeline (request → validation → DB → response) → Role-based access → Modular API structure This shift helped me improve: • Backend architecture thinking • Code maintainability • Real-world system understanding Still learning and building — next step: deeper system design + AI-powered architectures #Java #BackendDevelopment #SystemDesign #SoftwareEngineering #APIs

🛠️ 𝐈𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧: 𝐏𝐚𝐠𝐢𝐧𝐚𝐭𝐢𝐨𝐧 & 𝐒𝐨𝐫𝐭𝐢𝐧𝐠 𝐢𝐧 𝐚 𝐒𝐩𝐫𝐢𝐧𝐠 𝐁𝐨𝐨𝐭 A𝐏𝐈 When working with large datasets, returning everything at once is never a good idea. It increases response time, impacts performance, and doesn’t scale well. 🔍 𝐏𝐫𝐨𝐛𝐥𝐞𝐦 My API was returning a huge dataset in a single response → leading to slow performance and inefficient data handling. 💡 𝐖𝐡𝐚𝐭 𝐭𝐡𝐢𝐬 𝐢𝐦𝐩𝐫𝐨𝐯𝐞𝐬 ✔️ Breaks large data into manageable pages ✔️ Reduces response payload ✔️ Improves API performance ✔️ Allows dynamic sorting ✔️ Supports field-based sorting ascending order 🧠 𝐊𝐞𝐲 𝐭𝐚𝐤𝐞𝐚𝐰𝐚𝐲 Backend development is not just about returning data it’s about returning it efficiently and responsibly. 📈 𝐑𝐞𝐚𝐥-𝐰𝐨𝐫𝐥𝐝 𝐢𝐦𝐩𝐚𝐜𝐭 Pagination combined with sorting is essential for building scalable APIs, especially when handling large datasets in production systems 🔽 Adding the implementation below for reference #SpringBoot #Java #BackendDevelopment #APIDesign #SoftwareEngineering

“Understanding definition ≠ ability to implement cleanly in real code.” This line hit me hard today. We often feel confident after: ✔️ Reading docs ✔️ Watching tutorials ✔️ Understanding concepts But the real test begins when you **write actual code**. 🔍 What I realized I knew `Optional`, `map`, `flatMap` — conceptually clear. But during a simple login implementation: → Fetch user → Extract email I ended up with: ```java Optional<Optional<String>> ``` That moment exposed the gap: 👉 I understood the *definition* 👉 But not the *application* --- ### ⚠️ The Hidden Trap ```java findUserById(id) .map(user -> Optional.ofNullable(user.getEmail())) ``` This creates nesting. Code works… but design becomes messy. ✅ The Clean Way ```java findUserById(id) .flatMap(user -> Optional.ofNullable(user.getEmail())) ``` Now it’s: ✔️ Clean ✔️ Composable ✔️ Readable 🧠 The Real Learning Concepts are just the starting point. Real growth happens when: * You hit confusion * You debug deeply * You refine your thinking 🚀 Takeaway Don’t stop at *“I understand this”* Push until you can say: 👉 *“I can apply this cleanly in production code.”* Because in engineering: Clarity in thinking → Simplicity in code #Java #SpringBoot #CleanCode #BackendDevelopment #LearningJourney

So I have been reading research papers and tech blogs, This time I came across “Software 2.0” by Andrej Karpathy , and it introduced a perspective I hadn’t fully considered before. What as a Developer working in Software 1.0, I think is that it’s not about one replacing the other. It’s more about how they coexist and complement each other. Two ways of solving problems: 1. Software 1.0 is what we’re most familiar with ⚙️ We write logic step by step in languages like Java or Python to define exactly how a system should behave. This is still the foundation of everything we build. It gives structure and reliability. 2. Software 2.0 feels like a shift in thinking ✨ Instead of writing every instruction, we define a goal and provide data. The model learns the behavior on its own. So in a way, the code isn’t explicitly written anymore, it’s learned through the weights of the model 🧠 A New Ecosystem of Tools 🧩 Because these two paradigms coexist, our toolkit is expanding to handle both. • Data Centric IDEs: Tools like Cleanlab or Galileo are becoming essential. Instead of just looking for syntax errors, they help us identify mislabeled data or spots where a model is feeling uncertain 🔍 • The Modern Stack: We still rely on managers like uv or Conda for our environments, but we are also using tools like DVC and Hugging Face. These allow us to version our datasets and model checkpoints with the same care and rigor we give to our traditional code. 📦 • A Different Kind of Debugging: Testing is no longer just about checking logic. It becomes about finding the biases and gaps in the information we provide to the system. This is still something I’m figuring out, but it definitely changed how I think about building systems 💭