Writing Better Code: Prioritizing Decisions Over Syntax

The top article from the "Medium Weekly Digest" email newsletter this week: "Junior Devs Use try-catch Everywhere. Senior Devs Use These 4 Exception Handling Patterns": https://lnkd.in/dh_H7i2p Even after all this time I still opened it to make sure I'm not doing it wrong, but let's not talk about that part. I'm happy to report ego intact. <Nervous laughter> First of all, "Senior devs never ___" - LOL of course they do. We all do. The framing is unnecessarily adversarial and reads like an aggressively-toned code review. But the intent feels well-meaning, and there are real nuggets in there worth knowing. I'd just rather see it presented as "here are some patterns for graceful error handling" than "my title says 'Senior' so I must be right". I mean, it could be worse. At least there is some attempt at error handling. If you've inherited enough legacy codebases, you learn to find the silver lining. Just don't swallow exceptions. Silent failures turn colleagues into ferocious enemies.

Day 17. I stopped using @Autowired. Not because it doesn’t work. Because it hides problems. I used to write this: @Autowired private UserService userService; Every tutorial does it. It works. Until you try to test it. Then you realize: → You can’t see dependencies clearly → You need Spring context just to run tests → Your class is tightly coupled That’s when it clicked. The issue isn’t @Autowired. The issue is hidden dependencies. So I switched to this: (see implementation below 👇) Constructor injection. Dependencies are explicit. Your class is honest. Testing becomes simple. The hard truth: → @Autowired works — that’s why everyone uses it → Constructor injection scales — that’s why senior devs prefer it → The difference shows up when your code grows Writing code that runs is easy. Writing code that is testable and maintainable is what makes you a backend developer. Are you still using @Autowired? 👇 Drop it below #SpringBoot #Java #BackendDevelopment #CleanCode #JavaDeveloper

The most underrated skill in software engineering: reading other people's code. When I joined my current company, I spent my first 1 weeks just reading Not writing. Reading. I traced how a button click traveled through: - React component → event handler - Event handler → API client - API client → backend endpoint - Backend → database → response - Response → state update → re-render Most junior developers want to write code immediately. They want to "contribute." But understanding the system is the contribution. After those 2 weeks of reading, my first bug fix took 30 minutes. Without that context, it would have taken 3 days. Read before you write. Every time. #SoftwareEngineering #JuniorDeveloper #CodingTips ♻️ 📌 🔔

Earlier today I asked our Year Up instructor Matthew C. a simple question. I told him I wanted explore into Fullstack and DevOps as a career. What should I be exploring? He pointed me toward exploring JavaFX as we are still in Week 2 of Java base on my previous experience working with React and the Next framework in web development and he gave me great insights into why companies may choose electron for their uses. But before I even got there, we had an assignment. A theater reservation system. The program takes a guest's name, a date, and a ticket count and outputs a formatted confirmation message. Simple enough on the surface. The name had to come out as Last, First. The date had to reformat from MM/DD/YYYY to YYYY-MM-DD etc". Small things but it forced me to actually think about how data flows and how you format it for real output in a real world application Once I had that working in the terminal I thought, what if I can turned this into something you could actually see and use. Like one of those kiosks at the airport or a point of sale machine like Toast. So after class I opened IntelliJ and just started experimenting with JavaFX. It did not go smoothly. Version mismatches, null pointers, wrong field names. Every time I thought I was done something else broke. The window opened once. Crashed. Opened again, figure out whats wrong with the code. Until finally it just worked. It looked like something a real business would use. That eureka moment was great honestly and felt satisfying after hours of figuring out "What the heck is wrong now" Thank you Matthew C. for answering my question in a way that sent me down a rabbit hole that taught me more in one day than I expected. #Java #YearUpUnited #SoftwareDevelopment #ApplicationDevelopment #BuildingInPublic

I Thought My Code Was Clean… Until I Read It Again 👀 Early in my career, I believed: 👉 “If the code works, it’s good code.” It compiled. It gave the right output. So I moved on. But a few weeks later, I opened the same code again… And struggled to understand it. That’s when it hit me: 👉 Code is not just written to run. 👉 It’s written to be read. From that moment, my focus shifted. Not just “Will this work?” But also “Will this be clear to someone else?” 💡 What Changed My Approach I stopped trying to be clever. And started trying to be clear. Instead of writing one big method… I started breaking it into smaller ones. Each function doing just one thing. Instead of short, confusing names… I began using names that actually explain the purpose. Because: 👉 Good naming reduces confusion more than comments ever can. Instead of repeating logic… I started reusing it. Because copy-paste code always comes back as a bug later. Instead of deeply nested conditions… I simplified the flow. Because if it’s hard to read… it’s hard to maintain. ⚠️ One Hard Truth Most code doesn’t fail in production because it doesn’t work. It fails because: • It’s hard to understand • Hard to modify • Easy to break 🧠 The Mindset That Helped Me Before writing code, I now ask: • Can this be simpler? • Can this be reused? • Will this confuse someone later? 💬 Final Thought Clean code is not about impressing others. It’s about making life easier for: • your teammates • your future self If you read your code after a month and understand it easily… 👉 That’s clean code. What’s one habit that helped you improve your code quality? 👇 #CleanCode #SoftwareEngineering #Java #BackendDevelopment #Programming #DeveloperGrowth #BestPractices

I used to write "clever" code. I thought it showed I was smart. It didn't. It showed I didn't respect the next person reading it. The turning point was a 2 AM production bug. The fix took 4 hours — not because the problem was complex, but because nobody (including me, 6 months later) could understand what the code was doing. Since then, I've followed one rule: write code for the engineer who's exhausted and oncall at 2 AM. That means: Obvious variable names over concise ones A clear if-else over a one-line ternary that needs a comment to explain Boring, predictable patterns over "elegant" abstractions The best engineers I've worked with write code that feels almost too simple. That's not a lack of skill — that's mastery. Clever code is a liability. Readable code is a gift to your team. What's the most "clever" piece of code you've had to untangle? #SoftwareEngineering #BackendEngineering #CleanCode #CareerGrowth #Java

🚀 Backend Learning | Mistakes I Made (And What They Taught Me) While working on backend systems, I realized that some of the best learnings come from mistakes. Here are a few that helped me grow: 🔹 1. Ignoring Edge Cases → Learned that real-world systems fail at edges, not happy paths 🔹 2. Not Thinking About Scalability Early → Refactored later when traffic increased 🔹 3. Overusing Synchronous APIs → Caused delays, later shifted to async processing 🔹 4. Poor Logging → Debugging production issues became difficult 🔹 5. Skipping Proper Error Handling → Led to unpredictable system behavior 🔹 What I Learned: • Think beyond just working code • Design for scale and failure • Logging & monitoring are as important as logic Mistakes are not failures — they are design lessons in disguise. 🚀 #Java #SpringBoot #BackendDevelopment #SystemDesign #LearningInPublic #SoftwareEngineering

⚡ Code is Easy. Thinking is Hard. Over time, I’ve realized that writing code is just one part of being a developer. The real challenge is how you think before you write it. Understanding the problem, designing the right approach, and considering scalability, performance, and edge cases—that’s where the real engineering happens. Lately, I’ve been focusing more on: 🔹 Breaking down complex problems 🔹 Writing code that’s easy to maintain 🔹 Thinking about long-term impact, not just quick fixes Because good code works. But great code lasts. Always learning, always improving 🚀 #SoftwareEngineering #FullStackDeveloper #Java #SystemDesign #CleanCode #GrowthMindset

Day 91 of My 9-Month Coding Challenge 🎯 Logging & Monitoring in Backend Systems 📊 Today, I focused on improving backend observability using structured logging and basic monitoring practices—because writing code is only half the job; understanding what happens in production is equally critical. 🛠️ What I Worked On: ✔ Implemented structured logging using tools like Winston / Morgan ✔ Logged incoming requests, responses, and error stacks ✔ Differentiated log levels (info, warn, error, debug) ✔ Stored logs in files for persistence and debugging ✔ Added environment-based logging (dev vs production) 📚 Key Learnings: ✅ Logs are the first line of defense when debugging production issues ✅ Structured logs make it easier to trace and analyze system behavior ✅ Excessive logging can impact performance—balance is important ✅ Never log sensitive data (passwords, tokens, etc.) ✅ Monitoring + logging together give full system visibility 🧠 Core Concept: Reliable Backend = Observability (Logging + Monitoring) + Error Tracking 💡 Insight: You can’t fix what you can’t see. Good logging turns unknown bugs into solvable problems. Still learning. Still improving. Still consistent. 💯 #Day91 #9MonthChallenge #NodeJS #ExpressJS #BackendDevelopment #Logging #Monitoring #WebDevelopment #MERN #BuildInPublic #Consistency