Shuttle’s Post

After a "major" success of Why Some Projects “Die” After a Programmer Leaves The Company, I decided to take a step further and write a new one with some personal tips backed by extensive research. Every time we work on our code, we’re doing some kind of maintenance whether is fixing some bugs, adding new features, or improving something. The little things we do can compound in the long term to determine the longevity and good performance of our projects. Find out more by reading the full article. If you don't have a Medium Partner Program, I'm more than happy to send you the 'Friendly Link' where you can read it for free on Medium. Happy reading.

Diving deep into the Fragile Test Problem: Ever tweaked your code slightly only to spend days fixing the tests? Understand why your tests are breaking and how to tackle this issue effectively. 👉 Learn more: Write Tests You Love, Not Hate #5 https://lnkd.in/dVWuwvfb

Avoiding 𝐮𝐧𝐧𝐞𝐞𝐝𝐞𝐝 context will 𝐩𝐮𝐬𝐡 𝐲𝐨𝐮 write clean and readable 𝐜𝐨𝐝𝐞! I do not like the first example. Why? Because it tells me the following. 𝑯𝒆𝒚, 𝑰'𝒎 𝒂 𝑷𝒓𝒐𝒅𝒖𝒄𝒕 𝑹𝒆𝒑𝒐𝒔𝒊𝒕𝒐𝒓𝒚. 𝑰𝒇 𝒚𝒐𝒖 𝒘𝒂𝒏𝒕 𝒔𝒐𝒎𝒆𝒕𝒉𝒊𝒏𝒈 𝒇𝒓𝒐𝒎 𝒎𝒆, 𝒂𝒔𝒌 𝒎𝒆 𝑷𝒓𝒐𝒅𝒖𝒄𝒕, 𝑷𝒓𝒐𝒅𝒖𝒄𝒕 𝒆𝒂𝒄𝒉 𝒕𝒊𝒎𝒆. And that approach leads to 𝐥𝐨𝐧𝐠𝐞𝐫 𝐦𝐞𝐭𝐡𝐨𝐝 𝐧𝐚𝐦𝐞𝐬. Which does not make sense to me. Check out the following situation: 𝐯𝐚𝐫 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐅𝐫𝐨𝐦𝐃𝐛 = _𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐑𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲.𝐆𝐞𝐭𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐛𝐲𝐈𝐝(5); I prefer the following 𝐢𝐧𝐬𝐭𝐞𝐚𝐝 of that. 𝐯𝐚𝐫 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐅𝐫𝐨𝐦𝐃𝐛 = _𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐑𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲.𝐆𝐞𝐭𝐁𝐲𝐈𝐝(5); 𝟭. 𝐌𝐮𝐜𝐡 𝐬𝐡𝐨𝐫𝐭𝐞𝐫 𝟐. 𝐋𝐞𝐬𝐬 𝐧𝐨𝐢𝐬𝐲 𝟥. 𝐌𝐮𝐜𝐡 𝐜𝐥𝐞𝐚𝐧𝐞𝐫 And every 𝐎𝐎𝐏 𝐮𝐬𝐞𝐫 𝐤𝐧𝐨𝐰𝐬 that if we refer to a 𝐜𝐥𝐚𝐬𝐬/𝐨𝐛𝐣𝐞𝐜𝐭 we know what we are expecting 𝐚𝐬 𝐥𝐨𝐧𝐠 𝐚𝐬 𝐲𝐨𝐮 𝐝𝐨 𝐧𝐨𝐭 𝐧𝐚𝐦𝐞 𝐲𝐨𝐮𝐫 𝐜𝐥𝐚𝐬𝐬/𝐨𝐛𝐣𝐞𝐜𝐭 𝐥𝐢𝐤𝐞 𝐃𝐚𝐭𝐚, 𝐈𝐧𝐟𝐨, 𝐨𝐫 𝐒𝐞𝐫𝐯𝐢𝐜𝐞. What about the 𝐜𝐥𝐢𝐞𝐧𝐭 𝐬𝐢𝐝𝐞? You will push your client to contain a 𝐫𝐞𝐚𝐝𝐚𝐛𝐥𝐞 𝐜𝐨𝐝𝐞. If you have more than 1 repositories, the client will not name all as _𝐫𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲. It will lead to 𝐜𝐨𝐧𝐟𝐮𝐬𝐢𝐨𝐧, 𝐮𝐧𝐫𝐞𝐚𝐝𝐚𝐛𝐥𝐞, 𝐚𝐧𝐝 𝐥𝐞𝐬𝐬 𝐦𝐚𝐢𝐧𝐭𝐚𝐢𝐧𝐚𝐛𝐥𝐞 code. Instead, it will contain the following: 𝟭. _𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐑𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲 𝟐. _𝐜𝐚𝐭𝐞𝐠𝐨𝐫𝐲𝐑𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲 and so on... What is your approach to this situation

Here are some best practices on how to apply common sense before micro-optimising, and before adding third-party libraries left and right. The key points: - identify optimisation opportunities - identify trade-offs of said optimisation - measure the benefits and costs! - a short list of questions we should always make sure to ask before adding dependencies.  Basically the same principles as in verification and validation: is it doing the thing right, and is it doing the right thing? Longer version:

Have you ever had one of those days where your code just wouldn't cooperate? Welcome to the life of a programmer! Sometimes the slightest error can disrupt your entire day, but here's a tip: treat debugging like detective work. Each error is a hint that leads you to the solution. Test in little bits, keep records everywhere, and remember to take pauses when you feel frustrated. A fresh perspective can often disclose information that hours of looking at code cannot. What's your go-to strategy for dealing with persistent bugs? Share your top debugging tips!

We've all had that moment—500 lines of shiny new code, and then you check... 0% coverage?! 😱 Sure, it's tempting to throw in a quick-and-dirty test to bump that number to 80%, but real software quality isn’t just about the numbers. Here are some tips for making your unit tests truly count: 1. Test the Right Thing: Focus on the core logic, edge cases, and error handling, not just the obvious happy paths. 2. Avoid Mocking Everything: While mocking can isolate the unit under test, over-mocking can lead to tests that don't reflect real-world usage. 3. Keep Tests Independent: Each test should be self-contained and not rely on the results of others to avoid cascading failures. 4. Write Readable Tests: Your tests should be easy to understand. Future you (and your teammates) will thank you when debugging. 5. Test-Driven Development (TDD): Try writing your tests before the code. It helps clarify what your code should do, leading to more thoughtful design and implementation. 6. Measure Coverage but Focus on Quality: Coverage metrics are useful, but the goal is to catch bugs and ensure your code behaves as expected. Remember, a high coverage percentage is great, but effective, meaningful tests are what truly keep our codebase strong. Let’s write tests that matter! 💪 #SoftwareDevelopment #UnitTesting #CodeQuality #ProgrammingTips #DeveloperHumor #tests #debugging #bugs #debugger

Great code not only works but is also clean, readable, and maintainable.

⚡ 𝐓𝐞𝐬𝐭𝐢𝐧𝐠 𝐚𝐬 𝐚 𝐊𝐞𝐲 𝐏𝐚𝐫𝐭 𝐨𝐟 𝐒𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 ⚡ In my latest article, I dive into: 👉 When to prioritize testing—and when not to 👉 How skipping tests early on can slow you down later 👉 Why tests serve as both bug protection and documentation 👉 How testing can be a signal of code quality https://lnkd.in/eGakW3D2

The secret to modular, maintainable, and scalable code for growing project? It’s all in the framework 🙂 Solid and simple framework I follow (btw saved me countless hours of headache and refactoring): 1. Keep it DRY Don’t Repeat Yourself: Write reusable components and functions. If you’re copying and pasting code, stop! Modularize it and cut down on redundancy. 2. Single Responsibility Principle (SRP) Every piece of your code should have one job, and one job only. This makes debugging, scaling, and extending your project way easier. 3. Loose Coupling Make sure your components are as independent as possible. The less they rely on each other, the more flexible and scalable your code becomes. 4. SOLID principles Follow SOLID design principles (like open/closed, Liskov substitution) to keep your code robust and scalable over time. Got a code structure that’s worked wonders for you?

The internal quality of a code base is the properties of the code base that make it "easier for humans changing the codebase correctly" (Geepaw Hill). It requires a consistent habit of editing and revision, and is something that is hard to learn by reading an existing code base. Showing that process is one of the reasons I wanted to write a dev journal, rather than a series dissecting an existing code base. And so here it is; our first internal quality review: https://lnkd.in/dW-jxhA7