What makes this pattern so elegant to me is the familiarity of its experience. I don't know about you, but I've been annotating books and taking notes with pencils and pens for almost my entire life, and this is often the most engaging and soul-lifting experience. There is a je ne sais quoi in this interaction that makes me feel closer to, if not part of, the thing I'm reading. This is a physical annotate-in-place, and it works beatifully.

I've been long searching for a cognitive bridge between the ergonomics of putting pen to source text with the infinite flexibility of a software solution. annotate-in-place is the pattern that provides that bridge, and org-remark in Emacs is one implementation of that pattern. With it, digital note taking feel as intuitive and ergonmic to me as note taking on a physical medium.

A practical backend engineering roadmap with interactive explainers and visualizations.

Topics include networking, HTTP, databases, queues, caching, distributed systems, and real-world outages.

Feedback welcome.

https://semicolony.dev/roadmap/

Hey guys, so I built an online wallet app in Go (for educational purposes), but I feel like the archiecture is a mess. Right now, I've just made it like any regular CRUD app. The thing is, I've found that it's got really tight coupling because one service usually needs to call multiple other services.

For example, to create and execute a transfer, the transfer svc has to call the wallet svc to get the wallet. Then, transfers svc has to call the transactions svc to create a tx then it has to call the wallet svc 3 times. then Finally, it calls the transactions svc to update thet tx.

https://preview.redd.it/djzow52fxi2h1.png?width=942&format=png&auto=webp&s=21b58733aeba43452ddd13865dcd689649c60832

The problem I'm dealing with is the orchestration. In the previous example, the Transfers svc is having to deal orchestrate multiple different services and it just gets really complicated handling errors (what and where to rollback db transactions for example)

The solution I'm thinking of is using an Event-driven archiecture. I think eventual consistency and handling retries would make it easier for me as well as decouple a lot of the services. I'm hesitant though when I looked into event driven, it's usually NOT recommended to systems where the logic is inherently synchronous and where you are returning a response to the user instantly. It is recommended however to fanout type of systems which it seems mine is.

Is event-driven the right call here or am I overcomplicating it?

EDIT: This got more attention than i thought... Here is the repo of you guys are interested: https://github.com/Youssef-codin/NexusPay

At first I treated payroll like something customers could connect separately and handle on their own and at the time it felt completely outside the scope of what we were building

Over time our platform became the place where customers manage most of their actual operations

Scheduling worker activity reporting and most of the data leading up to payroll already lives inside our product so now users constantly ask why they need to leave the platform to pay people

The weird part is anytime that experience feels disconnected or clunky they still associate it with our product anyway

It feels payroll becomes part of the product experience whether you intentionally build it or not

Curious if anyone else building workflow heavy software has hit this point yet

A useful agentic change does not end when the diff appears. It ends when the system is coherent again.

I watched this exact loop last month: we asked an agent to tighten signup validation. It updated the form, the server-side validator, even the e2e test. Green across the board. We shipped. Two minutes later realized the password reset was broken.

A software change is not merely code moving. It is a shift in the requirement set.
There's a gap between the physical system (code, tests, schemas, diffs) and the theoretical system (requirements, contracts, constraints). Agents edit the former. We care about the latter.

When those two layers drift apart, an agent can satisfy the explicit task while breaking an implicit requirement nobody named and no automated check protects.

This post is my attempt to reason about that gap, and how to structure an agentic engineering harness around requirements, contracts, and deterministic feedback loops instead of just writing longer instruction files.

If you're interested, give it a read. If not, maybe let me know what I could do better!

Appreciate any feedback, and happy to partake in discussions :)

I think that "coding" as it's morphing into will become an unsustainable long-term career choice if only because of the context switching. Mental-physical toll that it takes for a developer to maintain sustained attention in the midst of rapid context switching just plain sucks. I get headaches now!

Sitting and reading a spec before approving? Not bad. Maybe 2 or 3 in a day so you have time to verify the models work before you send it off to your perfectly-tuned, highly context-scoped, former-{... meta, FB, Netflix} Principal of Principal Engineers Mega-Agent (I've seen .mds \w 1000+ lines). Right?

How are you all handling this? I imagine this would be on someone's radar to solve. Hell, I'm trying to figure anything out to stop the pain! Lol

All I keep reading is "lightning speed" this and "swarm of whatever-theyre-naming-them-now" will fix all your problems.

Is anyone being intentional anymore? Is taking one's time (with the help of models) to build something well designed suddenly a liability in the workforce?

That would be insane.

Hey everyone,

So hear me out. Document Rot is real.
We have all seen it.

The techniques of the past (for non Devs) relied on people documenting in office, slides, confluence, wikis or whatever and keep that up to date.

I never saw that working. Quickly it became a massive junk of unmaintained stuff.

AI changes the game.
In one repo, you can now keep a consistent documentation where all relevant changes can be added.

The issue? For Developers, especially in OpenSource: zero.

For non-Devs, this is a pain.
How are they now supposed to read and comment? Using GitHub and PRs is naturally a really good system, however for people that are used to WYSIWYG it feels off… plus having to use a coding environment if at all.

I am personally adding GitHub Pages to make the repo visible as a page with a comment system, and even then you get that friction.

Any better 2026 and beyond practices out there? (Note. One project docs are easy. This impacts multi -repo projects)

Howdy there,

As images are worth a thousand words, here's a quick demo of that it does.

https://reddit.com/link/1tikbqz/video/shjbg3voya2h1/player

A few months ago I decided I should step up on my system design game. As a frontend engineer working for a big company, I rarely have an opportunity to work on systems and it sucks. All the more so because system design is becoming increasingly important in the days of AI. And they're all over job interviews processes too.

So I went for the classics and started studying hard. And I've been loving it to the point I thought it'd be a good idea to create a small, very simple web app entirely dedicated to diagrams / system designing.

And it worked, somehow. I mean, working on a DDD project with systems at its core really forced/helped me wrap my head around what was what.

You might have noticed I'm a frontend guy as I've put a lot of effort on the UX and UI, I just can't help it haha.

I'm close to launching and the tool will be entirely free, with an optional premium access for agent use/db use (these cost dearly). Right now, I'm looking for testers, feedback, anything that'd allow me to provide a better experience.

UPDATE DISCLAIMER: just chatted with moderation whom I got a green light from to share my tool so sharing some more.

Questions, comments, feedback... anything welcome.

Cheers

Been going in circles on this at work for weeks. Our monorepo started clean but builds are crawling now and one bad commit takes down four devs. Multi-repo isn't better, we've got version drift everywhere and nobody can agree which shared lib is the source of truth.

What keeps annoying me is that the whole debate assumes dependencies have to live inside a repo. If shared code was just a reference the system resolved and pulled in on its own, the mono vs multi question kind of dissolves. You'd get isolation without the drift, sharing without the coupling.

Anyone actually working this way in production?

Hey all. I’m building a client-facing portal + an admin dashboard for a wealth/education platform. I currently have an Admin dashboard with customer management, course library, settings, analytics. On the other hand, i have a client portal with courses, announcements, course player, profile/settings.

Should I use a shared backend API for both apps, or split into separate APIs (client API + admin API)?

More questions:

- Should i essentially build two separate frontend + backend projects that share data?

I just need general advice with regard to how you would architect such a project (with scale in mind and actual clients)

Look, I’m not gonna lie. I look at these studios with their 50-person Slack channels, dedicated UI/UX designers, and people whose only job is to animate grass, and I get violently jealous. I'm over here writing the backend, crying over the frontend, doing the marketing, and playing the role of my own abusive QA tester.

The final stretch of development is pure agony. It feels like you're running a marathon, but the last mile is entirely uphill and covered in Legos.

But then I remember why we do this. When this thing finally crosses the finish line, I don't have to split the pie with a board of directors or a useless middle manager. The intellectual property? Mine. The credit? Mine. The money? 100% mine. I carried the entire unforgiving load, so I get the whole damn reward. And once I've officially made it, I'm going to aggressively give back to everyone who helped me stay sane along the way.

I wrote a little poem to cope with the burnout. Roast me, agree with me, or just tell me to get back to coding.

I stare at my screen, at the bug of the week, While AAA studios play hide and go seek. They have teams for their teams, and a guy just for doors, I have a cold cup of coffee and sleep on the floors.

I’m jealous, I’m tired, I’m losing my hair, Writing backend and frontend, which hardly seems fair. But I push through the burnout, the tears, and the sweat, Because quitting right now is my only regret.

When I finally ship it, and the nightmare is done, I won’t split the profits with anyone. One hundred percent of the rights and the cash, (Assuming it sells and my servers don't crash).

I did all the work, from the art to the code, I carried the whole unforgiving damn load. And once I am rich (or at least breaking even), I'll give back to the folks who kept me believing.

https://reddit.com/link/1tgpcu2/video/ccott5yvvw1h1/player

I have db per tenant software. One DB for each Tenant, and one Master DB for universal stuff. All of users are stored in MasterUsers table (in Master DB). They have Username, Password, TenantId, TenantEmpId. TenantEmpId is connection to TenantUsers table which exist in every TenantDb. So i know for example user joe has masterempid 5 and tenantempid 3 for example. This way i can write documents and always put his tenantempd as foreign key in TenantTables. Since DB Context Service in .Net is Scoped per HTTP request i can form connection string dynamicaly. Only one thing that scares me here is what if someone accidentaly logs with credentials of user from other tenant...
I have one instance of application and one universal domain that everyone uses. I don't think my clients will have static servers that i could use to forward them to right channel. Did anyone have this use case and how to overcome this? Thanks in advance.