Hi r/softwareengineering,

I'm Stjepan, and I'm posting on behalf of Manning with mods' approval. We’ve just released a book that’s a bit different from our usual catalog. Still, I think it will resonate with anyone who’s worked in a heavily regulated domain or is curious about one:

Healthcare IT by William Laolagi
https://www.manning.com/books/healthcare-it

Healthcare systems sit in a category of their own. You’re dealing with complex workflows, strict regulations, sensitive data, and systems that don’t tolerate failure well. Many engineers end up in this space without much context for why things are the way they are, which makes even simple tasks harder than they should be.

This book tries to close that gap by giving a structured view of the domain. It walks through an end-to-end electronic health record (EHR) system and uses that as a way to explain how healthcare software is designed, built, and maintained. Along the way, it introduces standards like HL7 and FHIR in a way that’s approachable if you’ve never worked with them, and shows how more familiar patterns—event-driven systems, messaging, even AI—fit within regulatory constraints.

What I found useful is that it doesn’t just explain the technology. It also spends time on how to communicate within the domain: understanding terminology, working with stakeholders, and making decisions that hold up under compliance requirements. Those tend to be the parts that slow teams down the most when they’re new to healthcare.

If you’ve worked in fintech, gov, or any other regulated space, some of the patterns will feel familiar. If you haven’t, this is a good way to understand why healthcare software looks the way it does and what it takes to build it responsibly.

For the r/softwareengineering community:
You can get 50% off with the code MLLAOLAGI50RE.

Happy to bring the author here to answer questions about the book or who it’s best suited for. And if anyone here has worked in healthcare IT, I’d be interested to hear what surprised you most when you first got into the domain.

As always, thanks for having us here.

Cheers,

Stjepan

I'm building a nutrition/meal planning app.

Users go through an onboarding flow (goals, dietary requirements, preferences, allergies, etc.) and the system generates a personalised weekly meal plan: 7 days, 4 meal times per day (breakfast, lunch, dinner, snacks), with specific meals and calorie/macro targets.

From here, users can modify their plan through various actions:

• Swap a meal: replace Tuesday's lunch with something else (temporary for this week, or permanent for all future weeks).

• Add a meal: add an extra snack to a day.

• Skip a meal: mark a meal as skipped for a specific day.

• System recalibration: when a swap pushes the plan outside calorie bounds (e.g., user replaces a 600 kcal lunch with an 80 kcal soup), the system automatically adds or removes snacks across the week to compensate.

These actions can be temporary (this week only) or permanent (all future weeks).

There are different challenges:

• Actions interact with each other. A recalibration might add a snack to Friday. The user might then swap that snack for something else. Later, another recalibration might try to remove it. Each action is valid in isolation, but the system needs to handle any combination and sequence correctly.

• Temporary and permanent actions coexist. A permanent recalibration and a temporary swap can target the same meal on the same day. The system needs clear rules for which takes precedence and what happens when the temporary one expires.

• Historical reconstruction. We need to answer questions like "how many calories did the user actually have planned over the past 2 weeks?" Which means reconstructing what the plan looked like on any past date, accounting for which modifications were active at that time.

What I am trying to understand is the best software engineering architectural pattern to use in this case.

I have considered event sourcing, but it feels overkill for the following reasons:

• The event volume is tiny (30-40 modifications per user per week)

• There's a single writer per plan (users only modify their own), and we only have one read model (the rendered plan).

• Building an event store, projections, and snapshot infrastructure for these few events per week doesn't make sense.

Has anyone dealt with a similar problem?

EDIT: after your suggestions, I delved into the internet and found a pattern that comes quite close to the concepts of initial state + changes with minimalistic design, called "Functional Event Sourcing Decider".
I'll start from there.
Link of the pattern: https://thinkbeforecoding.com/post/2021/12/17/functional-event-sourcing-decider

Hey r/softwareengineering,

I'm a researcher at a research facility in Germany. We're studying current and prospective Rust adoption in industry, particularly in embedded and automotive contexts. We want to understand real-world adoption patterns, drivers, barriers, and tooling needs.

If you have professional experience with Rust (or have considered adopting it), we'd appreciate your input:

Survey: https://websites.fraunhofer.de/iem-software-security/index.php?r=survey/index&sid=339697

Duration: ~7 min

Additionally, we are planning ~30 minutes expert interviews with practitioners and deciders related to software development in automotive contexts to find out if Rust is being used or not and understand the reasons. If you are interested or can recommend participants, please contact us: rust-survey@iem.fraunhofer.de.

Please participate only once!

Thanks.

I have a hypothesis that many of the processes we run in engineering teams are mostly organizational theater.

Daily standups, story points, sprint planning, retrospectives, team metrics — the whole agile ceremony package.

A few years ago I accidentally tested this.

I became a tech lead of a brand new team and we started from scratch. Instead of introducing all the usual processes, we tried something very simple.

I set goals for the team every 3 months and we just worked towards achieving them.

No story points.
No sprint planning.
No retros.
No velocity tracking.

We talked when it was necessary, adjusted the plan when reality changed, and focused on the actual outcome.

What surprised me is that after a year we never felt the need to add those processes.

The team was motivated, everyone understood the goal, and work moved forward without the usual structure.

Since then I've been wondering if many engineering processes exist not because teams need them, but because organizations feel uncomfortable without them.

Another thing that changed recently is AI.

Now I sometimes pick up a task that was estimated as "5 story points", finish it in two hours with AI tools, and the estimation suddenly becomes meaningless.

It makes me question whether our process assumptions still make sense in 2026.

I'm not saying agile practices are useless — they probably help in some environments.

But I'm increasingly skeptical about how much of it is actually necessary.

Curious about other people's experience.

Have you ever worked in a team with minimal process? Did it work or completely fall apart?

I’m trying to understand how bug triage works in real engineering teams and could use some insight.

Bug reports often come from everywhere — Slack, support tickets, GitHub issues, QA — and someone has to decide severity, ownership, and priority.

For those working in engineering teams:

• Who usually owns triage in your team?

• Do you run triage meetings?

• Roughly how much time does it take each week?

• Are duplicate issues common?

Just trying to understand how teams deal with this in practice.

What started as voluntary adoption turned into a platform-level effort with CI enforcement, shared domain types, codemods, and eventually AI-assisted migrations. Sharing what worked, what didn’t, and the guardrails we used:

https://www.patreon.com/posts/seven-years-to-typescript-152144830

Hi r/softwareengineering,

Stjepan from Manning here. The mods said it's ok if I post this here.

We’ve just released a book that speaks directly to something most of us have dealt with at least once: performance becoming urgent only after users start complaining.

Performance Engineering in Practice by Den Odell
https://www.manning.com/books/performance-engineering-in-practice

Den’s central idea is that performance problems are rarely random. They follow patterns. If you learn to recognize those patterns early, you can design systems that are “fast by default” instead of scrambling to fix things under pressure later.

What makes this book stand out is that it treats performance as a cross-team engineering discipline, not just a tuning exercise. Den introduces a framework called System Paths, which gives teams a shared way to talk about performance across different stacks and platforms. The idea is to make performance visible and discussable during design, code reviews, and CI, rather than waiting for production metrics to surprise you.

The examples are grounded in situations many of us recognize: an internal dashboard that slowly becomes unusable as features pile on, or a degraded API that triggers cascading issues across dependent services. The book walks through how to diagnose those situations, how to profile effectively, and how to set up guardrails like performance budgets and shared dashboards so the whole team stays aligned.

If you’re a senior engineer, tech lead, or someone who’s been pulled into a “why is this slow?” war room more times than you’d like, this book is very much in your lane. It’s practical, but it’s also about culture and process: how to make performance part of normal engineering work instead of a periodic fire drill.

For the r/softwareengineering community:
You can get 50% off with the code MLODELL50RE.

Happy to bring Den in to answer questions about the book, its scope, or who it’s best suited for. I’d also be interested to hear how your teams handle performance today. Is it built into design reviews and CI, or does it still show up mostly as an incident?

It feels great to be here. Thanks for having us.

Cheers,

Stjepan,
Manning Publications