Every engineer has a “Mystery Case” story. 🔍

For a long time, mine was a service that would run perfectly for weeks, and then, always at the most unexpected times, would violently consume memory and die.

I didn’t just ignore it. I fought it.

I analyzed logs, optimized code to reduce allocation pressure, and even claimed a “False Victory” once, deploying a fix I swore was the root cause. The crash stopped for a week, then came back.

We kept restarting the system by hand to keep it running, but we didn’t know what was really causing the problem. We tried hard to find out why, but checking things manually wasn’t enough. There was just too much data to look through, which hid the important facts. Trying to piece it together ourselves took way too much time and effort. Because we didn’t have a better tool to help us, we got stuck.

Recently, I finally solved the case. Not by traditional debugging. I did it by using AI to connect a conversation between my varios “disconnected” tools.

Here is the breakdown of the investigation.

Phase 1: Evidence Gathering (Finding the Needle in the Telemetry Haystack)

I exported the raw metric data and treated the AI as a Pattern Matcher.

• My Prompt: “Analyze this dataset. Find the exact timestamps where memory allocation spikes > 20% in under 60 seconds.”
• The Result: It identified two specific seconds in time.

I took those timestamps and asked the AI to generate a targeted query for my log aggregator (which have its own agent). The logs lit up. Every single memory spike aligned perfectly with a specific “System Refresh Event.”

In hindsight, this looks obvious. But in a codebase with millions of lines, “obvious” is a luxury you only get after you know exactly where to look.

Phase 2: The Interrogation (The “Chat-to-Profiler” Bridge)

Knowing when it happened was half the battle. I needed to know what was exploding.

The crash was happening deep in our core infrastructure. This wasn’t “bad code”; it was battle-tested bedrock logic that has scaled with us for years, making any modification a high-stakes operation requiring surgical precision.

In previous attempts, analyzing a production dump meant a deep, manual dive into a memory profiler. While modern profilers are powerful, they still require you to do all the heavy lifting. This time, I used a Model Context Protocol (MCP) to turn my profiler into a conversational partner. Instead of hunting through heap snapshots myself, I had a dialogue:

AI: “I detect a high volume of duplicate objects on the heap.”

Me: “That’s impossible, those should be cached and reused.”

AI: “The cache references are unique. They are not being reused.”

It wasn’t magic. I had to guide the AI, filtering out hallucinations and refining the context, but it handled the syntax while I focused on the semantics. It pointed me to a race condition I had looked at a dozen times but never truly saw.

Phase 3: The Implementation (Architecting the Cure)

The root cause was a classic “Stampede”: clearing old data before the new data was ready.

I knew the concept of the fix (a “Relay Race” pattern), but implementing high-concurrency caching logic in a critical subsystem is risky.

I used the AI to implement the solution:

• The Prompt: “Refactor this cache logic to support a ‘Versioned Handoff’. Ensure thread safety during the swap between Version 1 and Version 2.”
• The Result: The AI generated the boilerplate for the atomic swapping mechanism.

But I didn’t just copy-paste. I established an “AI Tribunal” (Github Copilot ,running cluade, for logic, Gemini for architecture) and performed a rigorous human code review to ensure the locking mechanism was sound before it ever touched the staging enviroment.

The Takeaway

• Don’t replace yourself; multiply yourself. I used AI to handle the “grunt work” of parsing data and generating boilerplate.
• Orchestrate, don’t just chat. Connect your tools. Let the metrics talk to the logs, and let the profiler talk to the code.
• Respect the “Boring” Solution. The fix wasn’t a fancy new framework; it was a simple, boring Relay Race pattern.

The case is finally closed. The fires are out, and production is quiet again, exactly how a well-engineered system should feel

There is a common bias in our industry: the instinct to add.

As developers, when we face a problem, our default reaction is to write a new function or add a new library. It feels like progress. But while code drives value, it also carries a continuous maintenance cost.

Every line you write is a line that must be read by teammates, covered by tests, and secured against vulnerabilities. The most efficient system is the one that delivers maximum value with minimum code.

The “Just In Case” Hoarder

It is easy to spot the “Fear of Deletion” in a Code Review.

You see a method that isn’t referenced anymore, but it’s still there. Or maybe it’s commented out. The mindset is: “Better keep it. You know, just in case we need to revert.”

This turns your codebase into a digital junk drawer.

“Zombie Code” — logic that is dead but still present, adds noise. It pollutes “Find Usages” results and confuses the next engineer trying to understand the domain. They waste time analyzing functions that provide no value to the user.

How to verify usages

The hardest part of deleting code is the fear of breaking something hidden. “Find All References” isn’t enough. Here is how to verify usage safely:

1. The Static Check: Start with the IDE. If a method is private, the compiler is usually right. If it’s public, be suspicious. Tools like NDepend or SonarQube can often spot "dead branches" that visual inspection misses.
2. The External Audit: Check the edges. Are frontend analytics still firing events for that feature? Are HTTP logs showing hits on the old API endpoint? Are cloud metrics showing activity on that specific storage? If the edges are silent, the core is likely dead.
3. The Database Audit: Sometimes the code looks valid, but the data is stale. Check your database statistics. If a table hasn’t had an INSERT or UPDATE in two years, the code managing that table is likely ghost-logic.
4. The “Scream” Test (Use Metrics): If you are unsure about a specific internal method, emit a custom metric: Metrics.Increment("deprecated_feature_x_usage"). If the counter stays at zero for a full business cycle, you have your answer.

Data beats intuition. If you can prove nobody calls it, you can delete it without sweating.

The AI Assistant (Your Cleanup Partner)

We are in the age of LLMs, and ignoring them would be a mistake. While you should never let an AI autonomously delete code in production, it is an incredible force multiplier for the verification and cleanup phases.

• The “Explain This” Test: Paste suspicious legacy code into an AI and ask: “Identify potential side effects if this were removed.” It often finds hidden dependencies.
• The “Safety Net” Tests: Before deleting complex logic, ask the AI to “Write comprehensive unit tests for this function.” Having tests that fail after you delete the code confirms you understand its impact.
• Generate the “Red PR”: Once you identify dead code, ask the AI to do the grunt work: “Refactor this file to remove the unused LegacyProcessor class and all references.”

Remember: AI is a tool for acceleration, not abdication. You are still the one clicking “Merge.”

The Sunset Strategy (Rollout Plan)

Verifying is one thing; deleting is another. You need a safety net.

• Phase 1: The Warning: Don’t rely on quiet runtime logs. Mark code @Obsolete to warn other developers in their IDE, and clearly communicate removal dates in your changelog and team channels.
• Phase 2: The “Soft Delete” (Feature Flag): Wrap the entry point in a Feature Flag and turn it off. This is your instant rollback mechanism if a critical user complains.
• Phase 3: The Observation: Keep the flag off for a safe period (e.g., 2 sprints). Ensure you have alerting on that disabled path. Silence is golden.
• Phase 4: The Code Delete Once the observation period has passed with zero alerts and no customer complaints, it is safe to delete the code, the flag, and the tests.
• Phase 5: The Data Cleanup: Deleting code often leaves behind orphaned data. Wait a few extra sprints to be absolutely sure, then archive the data to cold storage before finally dropping unused tables or columns. Your schema should reflect reality, not history.

The Bottom Line

There is a unique satisfaction in opening a Pull Request where the Lines Removed count is higher than the Lines Added — it means you have simplified the mental model without sacrificing functionality. If code isn’t running in production, it is just noise; trust your git history, verify with data, and hit delete.

Debuggability is highly underrated

In the words of Brian Kernighan, the famous computer scientist and author of the book “The C Programming Language”:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

This quote reflects a common experience many developers face while trying to write "smart" code. They often end up with complex solutions that are hard to maintain and debug. This is a common mistake, driven by the desire to demonstrate skills (and maybe to appear clever).

So… just write boring and straightforward code. Organize it into small, independent modules with clear interfaces and low coupling. This makes it easier to isolate and debug issues within specific components without being affected by the rest of the system.

How to organize a drawer the right way

Code is written once but read many times

Make your code readable and self-documented. This means code that follows good naming conventions, uses descriptive variables and function names, and includes clear comments (if needed).

When implementing your solution, you must think about how it will be executed. You probably focus on the happy trail, but you should also consider how it will fail and how you will debug it in production. Not doing so results in a mistake that can waste a lot of time and effort looking through complicated code to figure out and fix the problem.

To address this challenge, one must shift her mindset and prioritize debuggability from the start of the project.

This means leaving breadcrumbs, also known as logs, storing data in machine-readable format to enable efficient parsing and analysis, capturing valuable information about the application’s state, execution flow, and any errors or exceptions. There are several error-handling mechanisms that catch and report issues as early as possible, making it easier to identify and fix bugs. The logs from the different components and services will be collected into a centralized system for easier aggregation and querying.

In some cases, logs alone don't give us the complete picture of how a system is doing. It's a good idea to use metrics, which help us understand the system's health, performance, and behavior more completely. I’m a big fan of metrics because they give us a clearer view. You can detect anomalies and track quantities over time. Based on the collected data, you will build monitoring dashboards that provide real-time visibility (and alerting system).

Another tool in the debugability arsenal is tracing, which tracks the flow of “requests” across different services and components, enabling us to visualize and analyze the end-to-end journey of a request and pinpoint bottlenecks or failures.

Furthermore, investing in administrative tooling that reflects the system's state by exposing APIs or CLIs can greatly enhance debuggability by allowing developers and administrators to interact with the system, query its state, and perform various tasks such as triggering debug modes, capturing snapshots, or executing diagnostic commands.

Lastly, live debugging tools like Rookout, Datadog, and Lightrun allow you to debug code in production without any code changes. This is quite amazing and it is done by incorporating their agent into your code that does dynamic instrumentation. This agent is a bridge between your code and their environment. It monitors the code’s execution and identifies points in the flow (such as function calls or variable assignments), and it does some optimization not to instrument everything based on the learned history of “hot” paths to minimize the performance hit.

To conclude, writing boring and straightforward code, combined with various observability techniques, which should be included as early as in the design stage, can significantly enhance your system's debuggability.

A few months ago, we had a hackathon at my work.
At the opening event, one of my colleagues said to me:

Hackathons are similar to building LEGO model without instructions.

It stuck with me. I pondered about it.

What crossed my mind is that hackathons are playgrounds for software engineers, where creativity is key. Imagine being handed a box of LEGO bricks, and the instructions are taken away; what would you build? Probably, whatever comes to your mind.

That’s the magic of hackathons — they push you to think beyond boundaries, innovate, and craft something extraordinary from seemingly random pieces. Just as LEGO bricks offer endless possibilities, hackathons provide a platform for boundless innovation.

There are no rules; your imagination is the only limit. Without a set path to follow, hackathons encourage participants to explore new territories, experiment with fresh ideas, devise effective and unique solutions, and, along the way, have FUN.

You start with an array of tools — technologies, APIs, datasets — and the goal is to create something innovative and functional. This process fosters creative problem-solving and rapid prototyping, crucial skills in the dynamic software development landscape.

To sum up, hackathons serve as platforms for software engineers to push boundaries, explore new ideas, and work together in diverse teams to create groundbreaking solutions. Ultimately, they encourage a culture of continuous learning and experimentation.

Everyone makes mistakes. If someone says otherwise, they’re probably not being straight with you. It’s bound to happen whether you’re new to a job or have been there for a while. You can find plenty of horror stories on Reddit and HackerNews. Take, for example, this post with a collection of those stories:

Ask HN: What's the worst you've ever screwed up at work? | Hacker News

I felt that gut-wrenching moment when you realize a mistake has been made. The sinking feeling in your stomach, the twinge of shame, or the self-critical thoughts might flood in.

But here’s the thing: mistakes are a natural part of the journey, and what matters most is how we navigate and learn from them. In this post, I’ll try to explain why.

Acknowledge and Own Up

The first step is crucial — acknowledge the mistake. It’s tempting to sweep it under the rug or pass the blame, but trust me, that only makes things worse. Take responsibility and be brutally honest about what went wrong. Embrace the uncomfortable truth; it’s the only way forward.

Show that you’re proactive and committed to resolving the issue. Follow up and keep your team updated on your progress. Communicate clearly and frequently until the problem is solved.

Moreover, in my experience, there’s a hidden gem amid chaos — a chance to observe how people react. It’s like a crash course in understanding your company’s DNA. The way individuals handle mistakes reveals volumes about the organization’s culture.

Uncover the Why

Once you’ve owned up to the mistake, dive into detective mode to understand why it happened. Was it a knowledge gap, lack of training, or a hurried decision? This isn’t about pointing fingers but gaining insights.

Think of it as peeling an onion — layer by layer, get to the core of the issue. Was there a miscommunication or a systemic flaw? I can suggest using the 5 Whys technique. This is how it works:

1. Start with the problem statement and ask why it happened
2. For each answer, ask why again until you reach the root cause
3. Repeat the process for different aspects of the problem until you have a comprehensive picture of the situation.

Understanding the why isn’t just for personal growth; it’s about making your team and organization more resilient.

By figuring out the root cause, you not only learn from your own slip-ups but also contribute to a shared knowledge base. Keep it simple, grab your metaphorical magnifying glass, and unravel the mysteries behind your mistakes.

Fix It, Learn from It

Fixing the mistake is an obvious step, but don’t just gloss over it.

Don’t just patch the error; analyze it like a Git blame gone rogue. What went wrong? Was it a logic gap, a memory leak, or maybe a sneaky exception lurking in the shadows? Understanding the root cause is the key to unlocking points for future levels.

If you need a guide on how to start when it you against the issue, I once wrote a post about it:

A letter to the lonely developer

Provide a high-level overview of what you did to resolve the issue, and accompany it with your key takeaways. Turning the page without reflecting on the lesson learned is a missed opportunity for personal and professional growth.

Prevent Future Slip-Ups

Now armed with insights, take proactive steps to prevent a repeat performance.

Knowledge is the ultimate firewall. Invest in training, devour documentation like it’s your favorite Stack Overflow thread, and consider adding unit tests like shields against future regressions, allocating more time for tasks, implementing new processes, or adding logs and metrics for better visibility.

The power of the unit tests

Remember, prevention is the ultimate hack to keep bugs at bay.

Reflect and Share

Don’t let your hard-earned lessons be solo commits. Take a moment to reflect on the entire experience. Consider what could have been done differently and how you can improve professionally. Conduct a retrospective meeting with your team to discuss the mistake and the lessons learned. Use a structured format, such as the Start-Stop-Continue model, to identify what worked well, what didn’t work well, and what can be improved. Encourage everyone to participate and share their perspectives and suggestions.

Look into the past, improve the future

Document your reflections and share them internally as part of a post-mortem. Transform your learning into collective wisdom, turning it into “stronger” code (and fewer regressions).

Below is a collection of some examples from very respectful companies:

GitHub - danluu/post-mortems: A collection of postmortems. Sorry for the delay in merging PRs!

Lastly, embrace the “fail fast, iterate faster” mentality. Treat mistakes as experiments gone sideways, valuable data points in the grand algorithm of your career.

In Conclusion

Mistakes are an inevitable part of the developer’s journey, but they are also invaluable learning experiences. Acknowledge, understand, fix, prevent, and reflect — these steps can turn a negative situation into a positive opportunity for growth. Remember, it’s not about avoiding mistakes altogether; it’s about handling them with resilience and turning them into stepping stones on your path to success. After all, everyone makes mistakes — it’s the journey of learning from them that truly matters.

A humoristic post generated with the help of ChatGPT

Do you wanna see me test? U wanna see me unit test?

In the world of software development, unit testing is an essential process that ensures our code behaves precisely as we expect. But let’s be honest; unit testing is not the most glamorous part of coding. It’s the backstage crew, the hidden orchestrators behind a great performance. And just like the Eurovision Song Contest, our unit tests must be pitch-perfect to score the highest points in reliability and robustness.

Now, imagine unit tests as a song in the Eurovision contest, specifically, the 2023 Israeli entry, “Unicorn” by Noa Kirel. Why? Well, stick around, and you’ll see how unicorns and unit tests have more in common than you think!

Unit Tests: The Unsung Heroes

Think of your software as a competitor in the contest. The software, like the singer, is the face of the performance, taking center stage and getting the applause. But behind that successful performance, there’s a lot of practice and fine-tuning. That’s where our unit tests come in. These tests, the unsung heroes, ensure that each piece of the code (the lyrics, the melody, the rhythm) works correctly. If the tests pass, it’s time for our code to hit the stage!

Embracing the Power of the Unicorn

In “Unicorn,” Noa Kirel sings about harnessing the “power of a unicorn,” symbolizing strength and uniqueness. This can be seen as a metaphor for our unit tests. Each test is unique and powerful in its own way, checking a specific part of our code. Combined, they provide the strength and assurance that our software functions correctly.

Much like Noa Kirel found her “horn” to embrace and used her experience as a young artist to promote strength and togetherness, we too, as developers, must embrace our unit tests. They may face criticism (usually from developers who think they’re not worth the time), but we know their true value. They promote “coexistence and togetherness” in our code, ensuring that each piece works together harmoniously.

Hitting the High Notes with Unit Tests

“Unicorn” made it to a 3rd-place, showing that a strong performance and a unique message can indeed score high points. The same applies to unit testing. High-quality, well-thought-out unit tests can help your software reach its highest potential and avoid any sour notes (bugs) during the performance (runtime).

A well-tested software is like a chart-topping hit; it’s reliable, it’s loved by users, and it’s less likely to crash in the middle of the performance. It may not be a unicorn, but in the software world, it’s pretty close!

The Encore

So, the next time you write unit tests, think of yourself as a Eurovision contestant preparing for a big performance. Each test you write is a line in your song, a step in your dance routine, or a note in your melody. Embrace its power, harness the strength of your tests, and get ready to take the stage.

And remember, in the grand Eurovision of software development, your unit tests could be the difference between a standing ovation and a silent auditorium. So, let’s hit those high notes, and may the best code win!

Essential tips and resources for a successful job hunt

I was laid off from my previous job. It came out of nowhere; I decided to take this change as an opportunity and make the best of it. Luckily, I received incredible support from my connections, and I want to give back by sharing some valuable lessons and resources I’ve gathered along my job search journey.

This blog post is based on a Twitter (Hebrew) thread I created, detailing my experience and offering practical advice to fellow software engineers (and not only) facing a similar situation.

Dvir Segal on Twitter: "בניסיון לעשות לימונדה מהלימון. אז שרשור #דבירמחפשעבודה יוצא לדרך עם דברים שלמדתי along the way , אם מישהו אשכרה יתעניין בזה.טוב, אז קודם כל לעדכן קורות חיים. לשבת לכתוב ולהיעזר במדריך ששתפה @ShaharAvigezer בשרשור חיפוש עבודה שלה שנכתב על ידי @esapir:https://t.co/oo94ZtHPXY / Twitter"

בניסיון לעשות לימונדה מהלימון. אז שרשור #דבירמחפשעבודה יוצא לדרך עם דברים שלמדתי along the way , אם מישהו אשכרה יתעניין בזה.טוב, אז קודם כל לעדכן קורות חיים. לשבת לכתוב ולהיעזר במדריך ששתפה @ShaharAvigezer בשרשור חיפוש עבודה שלה שנכתב על ידי @esapir:https://t.co/oo94ZtHPXY

Updating Your Resume

First and foremost, updating your resume is crucial. Use guides and resources like the one shared by Shahar Avigezer (written by Erik Sapir) and the one by Rina Artstain to help you craft a professional and polished resume showcasing your skills and experience. When you finish your resume, the optimal way to submit it is with a referral. But if it is not an option, just run your CV through the CV Compiler to see how it scores with applicant tracking systems and what needs to be improved (ATS robot)

Leveraging Your Online Presence

Consolidate your online activity into a “business card” with links to your LinkedIn, Twitter, and others. This way, you can showcase additional accomplishments and interests that may not fit your resume. It also demonstrates your professionalism and personal brand. A few years ago, I read a post written by Kshitij Singh on how he created such a landing page, and I followed his guidelines in his repo below:

GitHub - singhkshitij/My-Landing-Page: Minimal Portfolio Page Built with React

The result:

Preparing Your Pitch

Before applying for job positions, write a “tell me about yourself” document, as described in the book “Cracking the Coding Interview”. It should cover your current role and academic background (if applicable) and delves into the role’s details. Finally, hobbies — especially those related to the tech world or “unique”- could serve as conversation starters or perhaps break the ice.

Furthermore, the book suggested focusing on 2–3 challenging projects you’ve worked on. Write down a list of mistakes you’ve made (we all do them), what you had fun doing, and which conflicts you took part in. Eventually, it will assist you in writing phrases in the SAR (Situation, Action, Result) framework to tell a compelling story about your achievements.

Organizing Your Job Search

Use tools like Notion to keep track of your job applications and interviews. This will help you stay organized and focused during your search, ensuring you’re on top of each opportunity. I’ve used the following templates:

• Track down the list of job applications:

Notion Template Gallery - Job applications

• A personal CRM to keep all your leads:

Simple CRM | Notion Everything

Researching Potential Employers

Before applying for a job, research the company by checking its location, reading investment analysis, and searching for articles on sites like Geektime and Crunchbase. Search review-based websites like Glassdoor to get an idea of what it’s like to work there. Prepare a list of questions (🙏 Shahar Avigezer) to ask the recruiter to refine your job search better:

• What will my day-to-day look like?
• How will I receive tasks? What percentage of meetings will I have per week?
• What is the percentage split between front-end and back-end work? And from whom?

Also, do some work with yourself to understand better what you’re looking for by asking the following:

• What does Work-Life Balance (WLB) mean for me?
• What hybrid work model works best for me, and how?
• What next role do I aspire to take on in the coming years?
• Which programming language or framework do I prefer for front-end and back-end development?

Being well-informed will help you make better decisions and impress potential employers.

Preparing for Interviews

I recommend the following two websites to help you study for code interviews:

• The interview school by Adilet Zhaxybay:

Home

• The tech interview handbook:

Technical Interview Guide for Busy Engineers | Tech Interview Handbook

They offer guides, practice LeetCode questions, and tips on various aspects of the interview process. Preparation is key to standing out and performing well during interviews.

System Design Interviews

Brush up on key topics and watch the system design interviews video series by Sheeran:

Followed by the introductory video on the importance of this type of interview, what they’re looking for in a candidate, breaking down the problem into details, and how to improve in this area by Jackson Gabbard (Synthace):

Practice solving problems using resources like the Grokking Modern System Design course by The Educative Team and tools like excalidraw. The more practice you get, the more confident you’ll showcase your skills.

Grokking Modern System Design Interview for Engineers & Managers - AI-Powered Learning for Developers

Note someone uploaded an old version of the course to GitHub, which is enough for practicing, though some recent concepts are probably missing:

Ducvoccer.github.io/system-design/docs/grokking-system-design at main · Ducvoccer/Ducvoccer.github.io

Negotiating Your Offer

If you receive a job offer, use resources like the document by Aviad Herman, The Salary and Offer Negotiation Preparation section in the Tech Interview Handbook, and Iftach Bar’s lecture on salary expectations to help you negotiate a fair package.

If you receive stock options, consult threads(#1, #2) by @beersehva and Boaz Berman and use tools like EquityBee’s calculator to estimate their value.

Option Grant Benchmark Tool | EquityBee

Conclusion

I hope these tips and resources will be helpful to you on your job search journey. Remember that finding a new job can be challenging, but you can turn it into a new opportunity with perseverance, a strong network, and the right tools. Good luck!

How we used integration tests to improve confidence in our code

Picture this: your product owner brings you a set of new requirements, and together you review them. After some preparation and initial work, you get your design reviewed and approved by relevant stakeholders. Then, you enter your focus zone and start implementing it. While doing so, you want to gain confidence, so you add tons of unit tests to cover it, manually test it, and refactor your code based on your tests' results until you feel comfortable with the outcome.

But still, you're left wondering, "how do I get to a strong level of confidence in this code?"

In this post, I'll discuss what I did when faced with the above situation and how my team and I improved the quality of (and our confidence in) our code.

Integration tests: what are they, and why do them? 🤔

There is a straightforward answer to the second part of the above question: integration tests help ensure happy customers.

Developers take several approaches to test their code to ensure its integrity. Choosing the suitable testing method depends on your context. Nevertheless, some tests are required for every software. These tests are represented as a layer-based model, known as the testing pyramid proposed by Mike Cohn.

Personally, I think the image below (by Atlassian) emphasizes what we would like to achieve when choosing a specific testing approach by following each of the layers of the pyramid.

Hence, we chose to implement integration tests to answer the question, "Are we building the system right?"

Why did we choose integration tests? These tests determine whether the parts of the solution work together as expected. Integration tests implementation is relatively easy and can prevent errors that are hard to catch later on. In addition, integration tests help to validate builds faster, reduce the time to ship, avoid human error, adhere to continuous integration (CI) practices, and minimize cost. As a result, everyone is happier in the long run because bugs are detected earlier, and larger problems are avoided. This increases our confidence and results in higher-quality code.

How did we build them? 👷🏻‍♀️👷🏻‍♂️

At Igentify, our services are deployed as Docker containers. In a nutshell, containers isolate apps from their environment, solving the "it works on my machine" problem. Docker has a powerful API, which makes it easy to automate its setup and deployment.

We use the famous Testcontainers library that provides lightweight, throwaway instances of anything that can run in a container. The Testcontainers library is test-friendly, open-source, and supports multiple programming languages. Since Igentify's services are being deployed as containers, we already have a Dockerfile, and Testcontainers simply create a new temporary image for it on-the-fly.

Testcontainers

If you've read this far, you're likely interested in diving into more technical details 🤓

As an example, if the design of your system is:

• Service A is a container that talks to the "world" using a message broker in the form of RabbitMQ
• It gets a message from the RQ_Queue , processes it, requests a pre-signed s3 URL, and stores its result in the bucket using that URL
• When finished, it responds to RS_Queue with the output

At a high level, the RabbitMQ container is being replaced by TestContainers' RabbitMQ module, and its configuration is being filled by Service A context, which is being initiated by @SpringBootTest annotation. The blob service is essentially a web server that gets requests via REST calls. As part of its API, the blob service generates pre-signed URLs for uploading to cloud storage, which in our case, is an AWS S3 bucket.

So, how can a web server be controlled in a test environment? API mocking. In practice, it means you replace the real implementation with a local web server for your testing purposes. We use a well-known library named WireMock, where you simply mock the various requests and responses, and you are able to instruct storing files directly to your local drive, bypassing the cloud storage. Two birds with one stone.

WireMock - flexible, open source API mocking

The final piece of the puzzle is to add a consumer for the RS_Queue to get the response and use JUnit5 to assert the expected output, resulting in a self-contained environment for testing. The input should be meticulously selected to cover success and\or failure scenarios.

Eventually, the integration test diagram looks like this:

The last step was incorporating the integration tests into our continuous integration in the Jenkins server. Currently, we run it every build, but in the future, we will trigger it once a branch is merged into the main (current) branch. That will help us gain certainty that we didn't break anything.

Final Thoughts

In this post, we reviewed how we've designed integration tests for our Java Spring Boot application with the help of TestContainers and WireMock libraries. We showed how we could easily interact with actual data while being as close as possible to the product, giving us confidence in our code.

I believe these libraries bring a lot of immediate value with a rich set of functionalities. I encourage you to give them a try. Overall, integration tests are a crucial part of any software development, as they help to ensure a more robust product, resulting in happier customers.

We used integration tests while building version 7 of our Igentify digital genetic platform, which we released last month. We plan to expand the capabilities of these tests in future releases of our software. If you're interested in learning more, please let us know here.

Or let’s talk about cohesion

TL;DR To make a system cohesive, you must ensure that the parts that go together are close to one another.

I sometimes find that the cohesion (and coupling) concept is often considered way too academic, and developers tend to talk about other well-known concepts, such as DRY, YAGNI, KISS, and SRP. The list is long, and I can continue with more acronyms all day 😂 So, I’ve chosen to challenge myself and simplify it.

I hope I succeeded.

Have you decided to continue reading?
Let’s talk about why it’s crucial or, in Kent Beck’s words:

Kent Beck 🌻 on Twitter: "Coupling vs cohesion. Coupling: * Can be hard to find * Can be really hard &/| expensive to eliminate. Cohesive sub-elements are: * Usually easy to find * Cheap to achieve, & * Help you find de-coupling. / Twitter"

Coupling vs cohesion. Coupling: * Can be hard to find * Can be really hard &/| expensive to eliminate. Cohesive sub-elements are: * Usually easy to find * Cheap to achieve, & * Help you find de-coupling.

You wanna strive for higher cohesion which reduces the coupling and complexity of the systems. What 😱? Let’s be formal for a moment:

Cohesion is the degree to which the elements inside a module belong together.

Coupling is the degree of interdependence between software modules.

Now it’s time for an analogy. Imagine you’re in the kitchen, it’s cold outside, and you wanna make a hot choco, so you open the silverware drawer, and it’s a total mess. Not only will it be hard to organize, but it’s not clear what belongs where and how to find it.

On the contrary, when everything is in its place, you can easily find a knife if needed or store a new spoon. In my eyes, that’s cohesion, lowering the general mess.

The terms cohesion and coupling are tightly related. They are often considered opposites, which isn’t accurate. Coupling is about connections; cohesion is about belonging together. The challenge is that cohesion is discovered in a context and cannot be created initially, meaning — you keep refactoring your code to keep objects in context.

The ideal scenario (also visible in the picture above) is when objects are arranged by functionality, or in other words, in a domain-driven context. When done correctly, it will result in loose coupling (there is no direct connection between a fork and knife besides the fact they are kitchenware).

Now… if you’ve reached this point, some code examples can be helpful. Let’s start with coupling:

When running the snippet above, the output is ID is null. You can run it yourself:

TightCoupling - Java Repl

So what’s going on? Each of the validity checks is being bypassed since Student and School classes are tightly coupled in such a way that School has intimate knowledge of Student’s internals and can set its data members. This design could be better. A quick solution will be declaring studentId with private access, forcing other classes to call the public getter and setter methods to access it, as follows:

In this case, the output is :

You can't initialize studentId to a null
ID is not initialized

LooseCoupling - Java Repl

But how does all of that relate to cohesion 🤷🏻‍♂️ ?

Let’s get back to the Student and School example. If a class does all the work at once (God object), it results from high cohesion (and high coupling). Basically, there is a strong connection between the object in the same context.

While trying to adhere to the single responsibility (or separation of concerns) principle, the interface should be broken into several classes, each targeting different functionality (domain-driven), making it easier to maintain and update.

Conclusion

Simply put, cohesion means that a class should represent a single concept. However, remember that achieving full decoupling is only possible with damaging cohesion and vice versa.

A system architecture that is easy to understand, easy to change, easy to maintain, and to test, is characterized by high cohesion and loose coupling. This combination contributes to the reduction of accidental complexity and enables the creation of well-defined modules.

Ultimately, I want readers to take away that following those principles leads to a system that is easier to maintain and refactor in the future. This is where the actual value lies, and that’s why you should care about cohesion.

I’m stuck; I’ve no muse about what to write. I can’t find any idea.
Aha… the famous writer’s block.

What do I do in those cases? From where does the inspiration to write about stuff come from? Where do I find ideas? How do I find the time?

Regarding the second, you make time — it is all a matter of prioritization. I’ve written about time management in the past, and those methods help me to focus.

Arrange your time and your mind will follow

The ideas? come from various sources. I keep an extensive list of podcasts, newsletters, blogs, etc., which I follow to gain more knowledge or, as I call it, the quest for growth, more on that:

In the quest for growth material

Besides that, I found ideas in unique places. I look for questions on Q&A-based websites such softwareengineering.stackexchange, workplace.stackexchange or quora.

Sometimes I get ideas from my colleagues or people I follow on Twitter. Actually, Twitter is an interesting place to collect them; I tend to tweet my thoughts, and occasionally a debate might evolve; this can be a trigger to blog about.

Anyhow, whether it’s a blog, podcast, or any other source. First, I collect the subjects I think I’d like to write about on a dedicated Notion page, a sort of ideas log. Afterward, I follow the method I wrote about here to sort it out:

Digital Notes are your life dashboard

This means that whenever I feel like writing or creating, I already have an arsenal of ideas.

So now I have a prioritized list, the fun part can begin. I pick the first item and start to research it online and collect the info on the subject’s page.

Once I feel ready I start writing, which is about the time I feel I consumed enough sources to write about the subject and express my opinion on it. Don’t get me wrong: research is critical, but sometimes, you just have to stop and start writing and see what happens.

The draft is ready? I read the whole thing repeatedly and then again 😂 and fix whatever doesn’t get along with my main narrative.

Finally, I use Grammarly to find any typos and grammar mistakes and if the sentences don’t fit the defined Grammarly goals. I usually pick an informal general audience with a casual domain. My writing style (intent) usually tells a story (as you might have noticed).

Lastly, the reviewers, a bunch of close friends, and colleagues happily read my drafts and share their inputs, and based on their feedback (loops), I’ll rewrite the final draft.

Basically, writing is all about reading and then more writing. As the old saying goes, “the only kind of writing is rewriting”.