Forem: Dvir Segal

Connecting LLMs to my debugging flow to fix a memory crash

Dvir Segal — Sat, 10 Jan 2026 20:31:30 +0000

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

The Joy of Negative Code Lines

Dvir Segal — Fri, 28 Nov 2025 14:49:52 +0000

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:

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.
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.
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.
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.

Write boring code

Dvir Segal — Sun, 19 May 2024 11:57:14 +0000

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.

Simple code works better than complicated code.

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.

Building LEGO without instructions

Dvir Segal — Wed, 20 Mar 2024 11:34:54 +0000

Photo by Matt Hudson on Unsplash

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.

TIFU at work: Learn and move on!

Dvir Segal — Thu, 25 Jan 2024 22:03:28 +0000

Photo by Santa Barbara on Unsplash

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:

Start with the problem statement and ask why it happened
For each answer, ask why again until you reach the root cause
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:

The lonely developer. Remind myself how to solve (debug) any defect (bug) | Medium

Dvir Segal ・ Sep 29, 2020 ・
dvirsegal.Medium

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 Unit Tests: Unicorns and Software Harmony by Dvir Segal | Medium

Dvir Segal ・ Jun 14, 2023 ・
Medium

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.

(Agile) Retro: Look into the past, improve the future | by Dvir Segal | Medium

Dvir Segal ・ Oct 30, 2020 ・
dvirsegal.Medium

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:

danluu / post-mortems

A collection of postmortems. Sorry for the delay in merging PRs!

A List of Post-mortems!

Config Errors

Allegro. E-commerce site went down after a sudden traffic spike caused by a marketing campaign. The outage was caused by a configuration error in cluster resource management which prevented more service instances from starting even though hardware resources were available.

Cloudflare. A bad config (router rule) caused all of their edge routers to crash, taking down all of Cloudflare.

Cloudflare. During a maintenance of their private backbone network, an engineer made a typo in the Atlanta datacenter network configuration, causing all traffic coming from America and Europe flowing to this only datacenter, crushing it.

Cloudflare. An incorrect ordering of the disabled BGP advertised prefixes caused malfunction on 19 datacenters.

Cloudflare. A change to our Tiered Cache system caused some requests to fail…

View on GitHub

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.

The power of the unit tests

Dvir Segal — Wed, 14 Jun 2023 05:52:27 +0000

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.

Uni Tess — The personification of unit tests, a meticulously organized individual by stable diffusion

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!

The power of the unicorn by stable diffusion

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!

Navigating through the job search

Dvir Segal — Mon, 10 Apr 2023 19:19:04 +0000

Photo by Bjarke Rosenbeck on Unsplash

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

@dvir_segal

לפני שבוע וקצת צומצמתי ממקום העבודה כחלק מגל פיטורים גדול. זה הגיע משום מקום.סוג של הלם. אני מבין שפה זה לא לינקדאין (שם כתבתי פוסט חיפוש), אבל אם לרגע אפשר, אז תודה לכל מי שעזר/ה, אתם מהממים ואתם יודעים מי אתם/ן! #פידטק #דבירמחפשעבודה
(לא תייגתי, אני לא יודע אם זה מתאים להם/ן)

12:15 PM - 04 Feb 2023

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 - Learn Interactively

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 IftachBar’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!

Failing fast to increase feedback loops

Dvir Segal — Wed, 09 Nov 2022 13:38:47 +0000

Photo by Omar Flores on Unsplash

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.

test 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.

Head to testcontainers website to find out more.

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

Service A Design

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.

Find more information about Wiremock's flexible 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:

Service A integration tests

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.

A Jenkins run

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.

How to organize a drawer the right way

Dvir Segal — Sun, 30 Oct 2022 11:41:45 +0000

Photo by shawnanggg on Unsplash

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 🌻

@kentbeck

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.

14:25 PM - 31 Oct 2020

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:

Tight Coupling

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

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:

Loose Coupling

In this case, the output is :

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

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.

Low Cohesion

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.

High Cohesion

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.

Where do I get writing ideas from?

Dvir Segal — Sun, 28 Aug 2022 11:34:06 +0000

Photo by Zach Lucero on Unsplash

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.

My digital notebook of ideas

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.

forget about it

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).

Grammarly goals setting

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”.

Is Code freeze still relevant?

Dvir Segal — Thu, 26 May 2022 14:23:37 +0000

Photo by sydney Rae on Unsplash

When practicing CI/CD, does code freeze still matter?

Assuming you are familiar with the concept of code freeze, which is that dedicated time in a project when we (developers) are supposed to be more strict in making changes to the code or other resources for the good of moving the project towards a release or the end of an iteration.

I’ve recently wondered about that concept; I asked myself why do we need to stop everything when we have a full-scale CI\CD pipeline. Well, you can just pick one of the versions and set it as the release candidate.

I researched and asked around, below you can find my conclusions.

Code freeze? Aha?

code freeze bane

First thing, first, defining what code freeze is. Wikipedia defines it as:

a freeze is a point in time in the development process after which the rules for making changes to the source code or related resources become more strict

The page underlines 3 common types of freezes:

A specification freeze is when all parties agree that no new requirements, specifications, or features will be added, as well as stop coding.

In a feature freeze , all development of new features is suspended so that all effort is focused on finding and fixing bugs and improving the user experience. A feature freeze helps improve the program’s stability by preventing the introduction of new, untested source code, resources, and their interactions.

Lastly, a code freeze , where no changes are allowed to the source code, ensures that the code areas known to work correctly will continue to do so. Code freezes are more common in the final stages of development when a specific release or iteration is being evaluated.

Do we need it at all?

Code freeze?

Now that we all synced what it is, the question is whether it’s relevant nowadays, where most (I assume) organizations practice a sort of CI\CD pipeline? the answer is not so simple; it depends on the domain and the product’s needs.

Take for example what happens at Igentify (where I work), the product we develop is regulated as required in the health tech domain. We apply a feature freeze for that purpose, so all features will be stable, the code is shifted to a dedicated branch, and (manual and automated) tests are applied before release. If any bugs were found, we fix them ASAP. In the meantime, new features are being developed in the main (current) branch. So, newer development doesn’t stop; it gets lower priority, and the pace is slower.

Whereas this notion contradicts the concept of the CD (commit == new version) where you can just take whatever is ready (in terms of code, tests, etc.) from a specific branch and deliver it to production. For instance, if a bug was found, quickly fix it, push and deliver to that branch. In a way, It creates a buffer between developers and production. They can continue to do their work without knowing there is a freeze at all.

In some cases, it is worth “breaking” the CD concept to mitigate a release risk. For example, I’ve learned that Big Tech companies such as Google do code freeze on the holidays since most of the employees are with their families, which results in less workforce to overcome production issues.

A word of caution ⚠️

test, testing, and some more testing

We should stay on guard about the frequency of using a freeze, it may point to unreliable tests , hence strengthening the testing chain will reduce the need for it. Moreover, some might argue that your processes have problems since you say certain contributions can’t integrate. There are many possible reasons, such as:

No automated tests.
Slow and\or flaky tests.
Long feature branches.
Unagreed design changes.
Broken builds are not being immediately reverted.
Developers don’t work on the latest main trunk.

Whatever it is, you’re not doing CI if you cannot integrate without stopping the whole team.

Final words

The target is to release

The truth is that there are no absolutes here.

The point of continuous integration and tests is to shorten the feedback loops and give programmers more visibility. As a result, there are fewer problems in testing and builds, but this doesn’t mean you don’t do the other parts of your development cycle — they’re just more efficient and effective, as development-related issues are more likely to be caught earlier in the process.

Nevertheless, a high degree of confidence does not mean something should go into the release without passing through the same final stages, and the code freeze is a critical element of this. To ensure the baseline for what you ship is as expected, you will still need it (or at least a branch).

Note that, simpler cases probably don’t require freezing. The CI process should ensure that a development branch's state can be released. Though, there can be MANY reasons why some specific code cannot yet be released into production. It is possible that other dependencies are required to be released at the same time or for any business reasons.

In any of the cases, IMHO, the release risk has to be managed, in some cases on the account of reducing the CD rate, though we shall strive not to harm it and find other ways.

In the quest for growth material

Dvir Segal — Sat, 26 Mar 2022 17:50:38 +0000

Photo by William Bayreuther on Unsplash

Various methods I use to gain new knowledge

A few years ago, I started my journey; picture this, a recent undergraduate SW engineer on his first full-time day job. My team mainly consisted of seniors; I saw those “giants” that both have vast product knowledge and tons of it in software development. They even found the time to be up to date with general tech news. I thought to myself, how do they do that? How can I learn new stuff which is not directly learned on the job? What are their methods? How do they find the time for that?

As part of my search for growth material , I’ve tried various methods that work for me, and I still do improve them from time to time. In the following post, I’ll elaborate on them. I covered my time management methods in other posts:

newsletters -src

Newsletters

I’ve found newsletters as my preferred way of staying on top of new and relevant software engineering topics. Here are the ones I keep reading every week out of the many newsletters I have tried:

TLDR Newsletter by Dan Ni. TLDR is a daily newsletter with links and TLDRs of the most interesting stories in tech 📱, science 🚀, and coding 💻!
Level Up from Pat Kua. Level up is a weekly newsletter for tech leaders. A collection of ten (or more) interesting links on leadership, technology, organizations, and processes.
Software Lead Weekly by Oren Ellenbogen. A weekly email for busy people who care about people, culture, and leadership.
The Pointer. A reading club for software developers, curated by Suraj Kapoor. Emailed Tuesdays & Fridays with 6–7 links with a tl;dr for each article.
Programming Digest, curated by Jakub Chodounsky. A weekly newsletter with the five most interesting stories in programming 👩‍💻, data 💾, and technology 📱.
Console by David Mytton & Max Jennings. A weekly digest of the best developer tools and beta releases for developers.

The above is what works for me; if you’d like more, head to the awsome-weekly repo with an extensive list of weekly newsletters from the software world.

GitHub - jondot/awesome-weekly: An "awesome" type curated list of quality weekly subscription newsletters from the software world

Brain explodes —src

But.. but, how can you consume that much information?

Our goal is to make reading fun and ensure that the content is relevant to you. If it’s boring, procrastinate. With that in mind, skim before you read!

A learning technic that I’ve learned in my master’s degree for reading (lots of) academic articles and understanding what’s relevant or not.

First, read the headline up to the first paragraph. Then, jump to the conclusion and read it. Fluent recognition of words is the key which improves as you consume more content and your vocabulary is getting larger.

Now you’ll be able to decide if the article is interesting. If it does, go over it again, but this time, you are going to read it while you’ve already established the article’s contextual concept, the essence. Slow down on areas of interest and ignore irrelevant info.

Tech for the rescue

Usually, I collect more articles than I’m able to read in a week. I place them using the 1percentgrowth app by Shem Magnezi:

1% Growth

which I recently switched to from Pocket:

Pocket

Those apps not only gather your articles but also recommend based on your past readings other hidden gems which relevant for you. A significant benefit of the pocket app is that it allows listening to articles utilizing text to speech engine. This is a true productivity boost. If you decide to use a different service — you can always rely on audioread, which turns your reads into podcasts:

Turn Reads📖 into Podcasts🎧

Or if you read on your computer’s browser, the lovely ‘Read Aloud’ extension is helpful as well:

Read Aloud: A Text to Speech Voice Reader

And last but not least is wordtune, which creates a tl;dr version of the article to understand more and faster:

Wordtune Read

Podcasts everywhere -src

Podcasts

I frequently listen to (Hebrew) podcasts; I usually play them on x1.4 speed, though I try to play with it and see If I can make it to x2. TBH, this is hard. Below is my listening list:

Reversim by Ran Tavori and Ori Lahav. Probably one of the iconic podcasts for developers. It covers tech, software, and development culture.
Geekonomy co-hosted by Reem Sherman and Doron Nir. They interview a special guest in each episode, which brings an interesting subject to talk about.
NoTarbut by Avi Etzioni & Iftach Bar. A podcast about the day-to-day of developers’ teams.
CyberCyber by Ido Keinan and Noam Rotem. A great way to stay up to date on the recent hacks and cyber security concepts.
Hitech troubles by Arbel Zinger and Eran Yacobovitch, which, in their words, is about the people of the Israeli hi-tech.
The big picture co-hosted by Aviad Ben-Yehuda and Nir Sabato. In each episode, this unique podcast covers the business strategy of one tech company.
BarvazGumi hosted by Vicky Kalmanovich and Linoy Shkuri. Interesting guests that talk about what makes development fun!
Osim Tochna is hosted by Boaz Lavi, who brings subjects about code, programming languages, cursed bugs, and machine learning.

There are more to listen to, and I try to review the list to keep it relevant for my interests (like the Root Cause, which stopped recording new episodes).

plain old RSS feed —src

RSS feed

Yeah, I’m aware of the fact this is quite an old concept but still relevant. There are plenty of RSS clients. I’ve found the Feedly free version more than enough for my needs:

Feedly - More signal, less noise

I apply the same skimming method. However, since it's about tech news, reading the headlines will give you the gist of it.

What’s in my RSS list? This is where I get up to date with recent tech news, in English and as well Hebrew sites — here are my favorites:

Also, it is helpful to follow groups of interest on Reddit, Quora, or Facebook, but that created an information overload for me, so I’ve decided to stop using them, and nowadays, I mainly follow the Tech Twitter hashtag and focus on reading content by interesting influencers such as Rina Artstain, Ran Bar-Zik, Oren Ellenbogen, etc. The list can go on and on, head to my profile for more.

To conclude

Calm down, don’t stretch your limits. You can go nuts from FOMO ( I didn’t cover Books as a learning source…).

Make sure to ask yourself what’s in it for me or what am I looking to learn here? Protect your time before you start consuming it. Ensure the information fits your expected growth and be hyper-aware of biases (be judgmental).

Explain the content in your own words (I usually tweet about my takeaways). Ask yourself questions after you’re done. Did it remind me of something else? Did it change the way I think? What did I learn from it that I didn’t know before? etc. That way, you can increase the chances it sticks with you, and later, you’ll be able to pull it out.

if you liked it…

Forem: Dvir Segal

Connecting LLMs to my debugging flow to fix a memory crash

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

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

Phase 3: The Implementation (Architecting the Cure)

The Takeaway

The Joy of Negative Code Lines

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

The “Just In Case” Hoarder

How to verify usages

The AI Assistant (Your Cleanup Partner)

The Sunset Strategy (Rollout Plan)

The Bottom Line

Write boring code

Debuggability is highly underrated

Building LEGO without instructions

TIFU at work: Learn and move on!

Acknowledge and Own Up

Uncover the Why

Fix It, Learn from It

The lonely developer. Remind myself how to solve (debug) any defect (bug) | Medium

Dvir Segal ・ Sep 29, 2020 ・ dvirsegal.Medium

Prevent Future Slip-Ups

The Power of Unit Tests: Unicorns and Software Harmony by Dvir Segal | Medium

Dvir Segal ・ Jun 14, 2023 ・ Medium

Reflect and Share

(Agile) Retro: Look into the past, improve the future | by Dvir Segal | Medium

Dvir Segal ・ Oct 30, 2020 ・ dvirsegal.Medium

danluu / post-mortems

A collection of postmortems. Sorry for the delay in merging PRs!

A List of Post-mortems!

Table of Contents

Config Errors

In Conclusion

The power of the unit tests

A humoristic post generated with the help of ChatGPT

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

Unit Tests: The Unsung Heroes

Embracing the Power of the Unicorn

Hitting the High Notes with Unit Tests

The Encore

Navigating through the job search

Essential tips and resources for a successful job hunt

Updating Your Resume

Leveraging Your Online Presence

Preparing Your Pitch

Organizing Your Job Search

Researching Potential Employers

Preparing for Interviews

System Design Interviews

Negotiating Your Offer

Conclusion

Failing fast to increase feedback loops

How we used integration tests to improve confidence in our code

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

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

Final Thoughts

How to organize a drawer the right way

Or let’s talk about cohesion

Conclusion

Where do I get writing ideas from?

Is Code freeze still relevant?

When practicing CI/CD, does code freeze still matter?

Code freeze? Aha?

Do we need it at all?

A word of caution ⚠️

Final words

In the quest for growth material

Various methods I use to gain new knowledge

Newsletters

But.. but, how can you consume that much information?

Tech for the rescue

Podcasts

RSS feed

To conclude

Dvir Segal ・ Sep 29, 2020 ・
dvirsegal.Medium

Dvir Segal ・ Jun 14, 2023 ・
Medium

Dvir Segal ・ Oct 30, 2020 ・
dvirsegal.Medium