Eliminate Magic Numbers and Strings in Your Code

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

🚀 DAY 41/100 – Controller Design Best Practices & DTO vs Entity In backend development, writing APIs is not enough. How you structure your controllers and manage data flow defines the quality, scalability, and maintainability of your application. Two concepts that every Spring Boot developer must master early: 👉 Controller Design Best Practices 👉 DTO vs Entity separation A well-designed controller should act only as a request handler, not a business logic layer. Key principles: • Keep controllers thin (delegate logic to service layer) • Use proper HTTP methods & status codes • Validate requests using @Valid • Maintain consistent API structure (/api/v1/...) • Handle exceptions using global handlers (@RestControllerAdvice) 📘 DTO vs Entity (Critical Concept) One of the most common mistakes in early backend projects is exposing entities directly. Why this is a problem: • Security risks (sensitive fields exposed) • Tight coupling between API & database • Poor flexibility for future changes Solution: ✔ Use DTOs for request/response ✔ Keep entities internal to persistence layer ✔ Map between DTO ↔ Entity in service layer 📘 What’s Covered in the Document • Controller responsibilities & anti-patterns • DTO vs Entity deep comparison • Mapping strategies (manual + tools) • Layered architecture breakdown • Interview questions with detailed answers 📄 I’ve compiled everything into a clean, revision-friendly document with examples and code snippets. If you're preparing for Java / Spring Boot / Backend roles (0–3 YOE): 📌 Save this — these are core concepts asked in interviews 🔁 Repost — helps others learning backend fundamentals Follow Surya Mahesh Kolisetty and continue the journey with #100DaysOfBackend #Java #SpringBoot #BackendDevelopment #API #CFBR #Connections #SoftwareEngineering #InterviewPrep #Developers #Programming #LearningInPublic #CleanCode #SystemDesign

Let me share how I fixed a slow report loading issue in my application I had created the report APIs, and initially it worked fine. What I was doing: I fetched all users data from the backend and applied pagination on the frontend. This worked well in the beginning when the dataset was small. But as the number of users grew: Reports started taking longer to load API responses became heavy Overall user experience degraded After digging deeper, I realized: Paginating on the frontend after fetching all data is a bad practice for large datasets. The Fix: I moved pagination to the backend: Sent page and rowsPerPage as query params Used Spring Boot’s pagination (PageRequest) Returned only the required chunk of data Result: Much faster report loading Reduced payload size Better scalability Key takeaway: Always paginate at the backend when dealing with large datasets. Small design decisions early on can create big performance issues later. #SpringBoot #BackendDevelopment #Java #PerformanceOptimization #APIDesign

Database errors will humble you. No matter how confident you are. Today was one of those days. Everything looked correct: logic made sense API routes were fine schema was clean But nothing worked the way it should. Hours went into: Prisma validation errors weird TypeScript issues (never type…) data not updating even though queries looked right And the funniest part? The actual issue is always something small. One missing field. One wrong assumption. One mismatch between frontend and backend. That’s it. But it’ll cost you hours. What I’ve learned (again): Debugging databases is not just coding. It’s patience + clarity + brutal honesty with your own logic. You have to slow down and ask: “What is actually happening?” “What am I assuming?” “Where is the data breaking?” Finally fixed it. And yeah, that moment when it works? Worth it. But still… database errors are a pain in the ass. #webdev #programming #debugging #buildinpublic

𝗪𝗲 𝗿𝗲𝗽𝗹𝗮𝗰𝗲𝗱 𝗚𝘂𝗮𝘃𝗮 𝗜𝗺𝗺𝘂𝘁𝗮𝗯𝗹𝗲𝗠𝗮𝗽 𝘄𝗶𝘁𝗵 𝗝𝗮𝘃𝗮 𝗠𝗮𝗽.𝗼𝗳. 𝗔𝗻𝗱 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗯𝗿𝗼𝗸𝗲. 💥 The code still compiled ✅ Nothing looked suspicious 👀 It was a small refactor 🔧 But after the change, behavior was different. Tests started failing ❌ Output changed 📦 Part of the system behaved differently ⚠️ At first glance, this looked strange. We replaced one immutable map with another immutable map. So why did anything break? Because the system had a hidden dependency 🧠 It turned out part of our logic was relying on iteration order. Not explicitly. Not by design. Just implicitly, through how the map was being used. And that was the real problem. Nobody on the team expected that a map would become part of the behavior in that way 🤯 But it already had. So the issue was not just "Guava vs JDK". The issue was that we changed a piece of code without fully understanding what the surrounding system had started to depend on. The quick fix was simple: use LinkedHashMap and restore deterministic ordering ⚡ But the more interesting lesson was not about LinkedHashMap. The real lesson was this: When you replace something that looks equivalent, you may still be changing behavior. Same shape of API does not mean same semantics ❗ Same return type does not mean same guarantees ⚠️ And "it worked before" does not mean the dependency was valid. It may simply have been hidden. That is why before replacing a method, collection, or utility, it is worth understanding 2 things: 1️⃣ The behavior of the thing you are introducing 2️⃣ The behavior your system already depends on #java #springboot #backend #softwareengineering #refactoring #engineering #distributedsystems

How to review a 500-line Pull Request in 15 minutes without missing the critical bugs. Most developers review code by reading top-to-bottom. That is the slowest, least effective way to spot architectural flaws. You get bogged down in syntax and miss the system impact. Here is the 4-step framework Senior Engineers use to review massive PRs: 1. The "Blast Radius" Check (2 Mins) Don't look at the logic yet. Look at the file tree. Did they touch the database schema? The routing layer? A core shared utility? If yes, that’s where 80% of your attention goes. 2. The Entry Point Read (5 Mins) Find the highest level of the execution path (the API controller or the main UI component). Read the intent of the code. If you can't understand what the feature does by reading the entry point, the code is too complex. 3. The Edge Case Hunt (5 Mins) Skip the happy path. Assume the happy path works. Look exclusively for: • Missing null checks. • Unhandled API timeouts. • Infinite loops in React useEffect. • Missing database indexes on new queries. 4. The "Nitpick" Rule (3 Mins) Formatting, variable names, and stylistic preferences do not matter. If your linter didn't catch it, let it go. Only leave a comment if it impacts performance, security, or readability. Great code reviews aren't about finding typos. They are about protecting the architecture. Community: https://t.me/kunalgargyt #SoftwareEngineering #Programming #CodeReview #TechCareers #Productivity #SystemDesign

One fine morning, a customer reported: “File upload sometimes fails…” Not always. Not consistently. Just sometimes. 😄 And of course, those are the best bugs. 👉 System handles 1000+ uploads daily 👉 Issue happens randomly (10–20 times) 👉 Chunk upload + merge logic (unchanged for years) 👉 Stateless architecture (or so I thought…) I jumped into debugging mode. After hours of checking: NFS configs ✅ Multi-server behavior ✅ Retry logic ✅ Logs (100 times) ✅ Observation: Chunks uploaded from Server A were not visible on Server B immediately (10–15 sec delay). Confusion level: 🔥🔥🔥 Then I did something simple (and often ignored)… 👉 Compared old vs new code Guess what changed? Just one line removed (thanks to Sonar cleanup 😅): HttpSession session = request.getSession(); And that innocent line was silently adding JSESSIONID, making requests sticky and hiding the real problem all along. 💡 So for years, reality was something like this: Stateless system... except when upload API enters the chat 😄 Or simply: stateless most of the time, secretly stateful during uploads 🎭 And the moment I removed an “unused variable”… 💥 Load balancing started behaving correctly 💥 NFS delays became visible 💥 Hidden dependency got exposed 💥 Bug said: Hello 👋 I was always here And the best realization: 👉 My application is perfectly stateless… 👉 Until the user hits the upload API and boom, it becomes emotional (stateful) 🤣🤣🤣 Lesson learned: Sometimes the bug is not in new code… It’s in removing the wrong old code 😄 And sometimes… Your system isn’t broken, your assumptions are. Still one mystery remains: 👉 Why exactly NFS behaved that way (never got a perfect answer 😅) #BackendStories #ProductionIssues #Java #NFS

Just shipped Phase 2 of json-schema ecosystem dashboard for the JSON Schema organization!  While previously focused on "who is using what," Phase 2 dives deep into Ecosystem Health & Momentum. We are now tracking 5 strategic metrics across 30+ implementations:  🔹 Adoption Velocity: Measuring how fast libraries add support for new spec drafts (Draft 2020-12 vs. legacy).  🔹 Maintenance Commitment: Real-time release frequency tracking to identify active vs. stagnant projects.  🔹 Community Vitality: Unique monthly contributor growth and momentum analysis.  🔹 Support Health: Maintainer responsiveness (PR/Issue turnaround times).  🔹 Language Diversity: Identifying tooling gaps across 15+ programming languages.  📈 Early Insights:   * Velocity Gap: 60% of core implementations now update within 3 months of a new spec release.   * Language Hubs: Strong dominance in Java/TypeScript, but identified a growing need for more spec-compliant Rust/Go tooling.  Check out the live dashboard: https://lnkd.in/gGcMrN86  Full Code & Analysis: https://lnkd.in/gE6Ne6Dc  Next up: Phase 3 — Ecosystem Maturity Index & Adoption Forecasting. Would love feedback from Ben Hutton  #GSoC2026 #OpenSource #JSONSchema #NextJS #BuildInPublic #Observability

🧠 LeetCode POTD — From TLE to Optimized Thinking 3488. Closest Equal Element Queries At first, the approach felt straightforward. For each query: 👉 Start from the given index 👉 Expand left and right (circularly) 👉 Find the closest same element ━━━━━━━━━━━━━━━━━━━ 💥 The problem? This works… but doesn't scale. If there are q queries and n elements: → Each query can take O(n) → Total = O(n × q) 👉 This leads to TLE for large inputs. ━━━━━━━━━━━━━━━━━━━ 💡 So what's the issue? We are repeating the same work again and again for every query. ━━━━━━━━━━━━━━━━━━━ 📌 Better Approach: Preprocess the array. 👉 Use a map: value → list of indices Example: nums = [1, 2, 1, 3, 1] → 1 → [0, 2, 4] Now for each query: Get all indices of that value If only one occurrence → answer = -1 Else: 👉 Use binary search to find the closest index 👉 Check neighbors (left & right) 📌 Since the array is circular: Distance = min(|i - j|, n - |i - j|) ━━━━━━━━━━━━━━━━━━━ 💡 Complexity now: → Preprocessing: O(n) → Each query: O(log n) 👉 Total: O(n + q log n) ━━━━━━━━━━━━━━━━━━━ 📌 What I liked about this problem: The solution isn't complicated. The key is realizing: 👉 "This is not a single query problem." Once you see that, the shift from brute force → optimized becomes obvious. ✅ Sometimes optimization is not about faster code ✅ It's about not repeating the same work Curious if someone solved it differently 👀 #LeetCode #DataStructures #ProblemSolving #SoftwareEngineering #DSA #C++ #Java #SDE