Lukas Hartrumpf’s Post

Unpopular opinion: You're not a senior dev until you debug with breakpoints. Logging is based on assumptions. "I think I need to look at this." Whereas breakpoints allows tuning yourself to the application flow instead of the flow of your assumptions. But it's not that I go around shouting at people to use breakpoints. What I try to do instead of shouting: * Set up the local dev environment to support breakpoints (not always easy) * Lead by example; show how I use to find the problems quickly * Ask others if they want to try breakpoints when debugging together more as a "fun trick" than some heavy burden on their part Are there benefits to logging when debugging something that I'm not considering? Change my mind!

It's so easy to get caught up, pointing fingers at the past when working with legacy code. The thing is, you don't know the constraints and inputs to those decisions. Codebases tend to reflect the conditions they were created in, and maintained in, rather than necessarily the skills of their engineers at the time. Be curious, but not judgemental. Look forward, and recognise that the past is often what's given you the job you're in right now, even at the cost of some hard to maintain code.

🤔 "Do people really write tests or it's just elitism?" Actual Reddit thread from a junior dev (link in comments). There are a lot of strong opinions about software testing out there: - If you don't test your code you are unprofessional - Tests just slow you down. - TDD speeds you up - Tests are just maintenance burden A lot of this is heavily dependent on context. Building an MVP? Tests might not make sense. Building a long-lived library? You probably want tests. At Vendure I consider our suite of 1,500+ end-to-end tests to be the crown jewels of the entire project. It allows us to make significant changes to the code while still being confident that everything still works. Sure, writing tests for each new feature adds some time. But being able to refactor that feature as much as we need to with confidence from that point forward? Worth it.

Clean code means fewer bugs 🐞 When your code is clear, simple, and well-structured, it’s easier to spot potential problems and avoid technical debt. Take the time to refactor and simplify—it will save you countless hours down the road! What’s your #1 clean code principle?

Your codebase is both an asset and a liability. The more diverse the stack, the more challenging it is to keep tabs on the threads imposed by the dependencies. Despite my inherent nature to be drawn toward the beauty of high-code frameworks and the sheer empowerment they bring, some days, I appreciate the simplicity of low-code tools, where most errors fade before the dawn; in high-code, each error is yours to own, today and tomorrow.

I don’t consider myself superstitious but as an engineer my language has changed a bit over the years: Junior dev: “Building that feature will be easy.” “That fix will take me 2 seconds.” “That change will be simple.” “This is very straight forward.” Mid level dev: “I don’t think that change will be that complicated.” “It will probably go quickly.” “I think we can complete that feature quickly” “The fix should be simple.” Senior dev: “I don’t think it will be a heavy lift for us to build that feature.” “It seems like it won’t be much work to make that change.” “Probably, adding that feature will be relatively simple if everything works as expected.” “I expect this change to not take very long, hopefully… probably… knock on wood.” These days: “I don’t want to jinx it but it looks like probably, maybe, that won’t be too challenging, unless I’m missing something. But probably it will be fine.” And the funny thing about that is, I’m sure my estimates while still not awesome, are better than they’ve ever been. In any case, I don’t miss the days of being confidently wrong about the complexity of a project. ;)

19 rules every software engineer should know. Thank you to my friend Owain Lewis for putting together this list. Give him a follow. He's got some great insights into software engineering. 1. Every line of code you write is a liability 2. Customers don't care about your code 3. Document your decisions and designs 4. Everyone hates code they didn’t write 5. Don't use unnecessary dependencies 6. Coding standards prevent arguments 7. You’ll regret complexity when on-call 8. You’ll never stop learning new things 9. Don’t fall in love with your own code 10. Write meaningful commit messages 11. Fix root causes, not just symptoms 12. Code reviews spread knowledge 13. Ask for help when you’re stuck 14. Understand the problem first 15. Estimates are not promises 16. Software is never finished 17. Design for maintainability 18. Everything is a trade off 19. Ship early, iterate often — ♻️ Repost to help your network. 🦁 Follow Spring Labs for more content like this!

Clean code , clear mind. 🧹😌 Organize your thoughts like you organize your codebase.

You must refactor code or abandon code.

As software engineers, we often focus on writing clean, maintainable code. But here's the question: How do you balance speed of delivery with code quality when facing tight deadlines? What strategies have you found most effective to avoid technical debt while still delivering on time?