Architecture diagrams have two failure modes. Three boxes that say nothing, or a hairball of two thousand nodes that says everything at once, which is also nothing. Both get screenshotted for a deck and never opened again.

Neiither answers the question you actually have in a new repo, which is not "what connects to what". It is "where am I, and does this matter".

So I built the other thing. A map you zoom into

The whole repo is one card. Zoom in and it opens into layers, then folders, then files, then functions. It is continuous, like a map app going from country to street. No level dropdown, no reload, no re-layout between steps, so you never lose your place.

The key thing: you never look at the whole repo at once. At any level you see a handful of cards, and you dig deeper only where it matters. It is something you navigate, not one dense picture you stare at. And it is not drawn by hand. It is generated from the code and git history and stays current as you commit, so it cannot hallucinate a module or drift from reality.

What makes it readable:

Cards are sized by how the system runs, not by line count. Entry points, what everything routes through, what churns. The code you should look at first is physically the biggest thing on screen.

Each card carries a health dot, rolled up so a folder reflects everything inside it. You find the bad neighbourhood from orbit and then dive.

Edges only appear when you hover a box, and only that box's edges, curved around the other cards rather than through them. That single decision is most of the difference between a map and a hairball.

The performance answer, for anyone who assumes this dies at scale: you never draw the whole repo. Anything off screen or smaller than a couple of pixels is skipped, so a frame draws a few dozen cards whether the tree has 2,000 nodes or 10,000. Cost stops scaling with repo size, which was the point.

It is part of an open source tool I maintain called Repowise, AGPL, runs fully local. Gif is it mapping its own repo.

Link: https://github.com/repowise-dev/repowise

Edit: no, it's not just C4. C4 is four static diagrams you draw and maintain by hand. This is generated from code and git history, one continuous zoom, with card size from centrality and churn, plus co-change and health that C4 has no concept of

Edit 2: Thanks for all the feedback, the Structurizr DSL point came up enough that I am adding it as an export format, emitted as a model file you include from your own workspace so your views and styles stay yours and never get overwritten on re-index

I have a theory about how HirePro handles proctoring and wanted to know if anyone has looked into this before.

Does HirePro's screen-sharing feed capture screenshots only when JavaScript raises a flag (tab switch, focus loss, fullscreen exit, etc.), or does it capture screenshots continuously at around 1–2 FPS and analyze them for abnormalities?

Handling both webcam feeds and screen-recording feeds for 300+ students over a 1–2 hour assessment seems computationally expensive, so I'm curious how they scale this in practice.

I also inspected the HirePro browser extension and found that its code appears to primarily disable other extensions, re-enable them after the assessment, and report if any extensions are forcefully turned back on. I didn't find any webcam or screen-monitoring logic in the extension itself.

Has anyone analyzed HirePro's architecture or worked on a similar proctoring system? What is the most likely approach being used here?

Hello,

I have usually seen people recommend not creating foreign keys to partitioned tables and instead relying on application-level validation.

Personally, I think that's a horrible idea.
Once invalid references start leaking into the database, they're difficult to detect and even some system it is impossible to clean up.
No matter how many safeguards exist in the application, a future code change, migration, or overlooked edge case can still introduce inconsistent data.

My preferred approach is to keep an unpartitioned table that owns the IDs replica and use that as the foreign key target for related tables, while the partitioned table stores the actual data.

Has anyone else used this pattern? Are there other approaches that preserve referential integrity without introducing too much complexity?

I'm building a permissions matrix where:

• Rows = permissions (organized as a hierarchical tree)
• Columns = user roles
• Each cell indicates whether a role has a given permission.

The UI requires the entire hierarchy to be visible at once (expanded by default), so traditional pagination isn't really an option. The frontend uses virtualization, so rendering performance is not the issue.

Let's say I have around 40 roles and 400 permissions, which means the UI needs to represent about 16,000 possible role/permission combinations

Is it considered acceptable for the backend to return the complete dataset in a single request if the client genuinely needs the whole matrix?

Or is this generally considered an anti-pattern?

I'm mainly interested in backend scalability:

• Memory usage
• Serialization costs
• Network transfer
• Response size
• Overall scalability as the number of roles and permissions grows

I'm curious what patterns you've seen in production systems for this type of UI.

What is your go-to setup for instrumenting analytics/telemetry?

At what point into a project is proper telemetry implemented?

Does observability tend to be implemented too soon, or too late? What are the side effects of mis-timing its implementation?

Engineer for years but always felt a gap. I build things that work but I want to properly understand design and architecture, not just do it by instinct. Also feel a degree never hurts and will help professionally too.

Got accepted into a part-time online MSc in Software Architecture & Design while working full time. Anyone done something similar? Worth it?

Context:

Lately, I've been thinking a lot about how to improve as a developer. Because of this, I started talking to coworkers, book authors, highly experienced devs on Reddit, professors, and more. I reached the following conclusions, but I'd love to hear your thoughts. Keep in mind that the goal of this post is to see if I'm on the right track to level up as a professional.

What I learned from talking to others:

Every developer I spoke with followed a different learning path, and I never heard the same opinion twice. However, there is one thing everyone agrees on: practice is what matters most, far more than any theoretical resource. You need to actually work, question the "why" behind every decision, compare different solutions across different scenarios, and even put in extra hours of practice by building long-term personal projects. This is why I started working at quite a young age. Thanks to that, now that I'm almost graduated with a Computer Science degree, I already have several years of experience in the industry, where I've learned a lot.

This doesn't mean you shouldn't study, though. Personally, I'm just two courses away from graduating and I'm far from done studying, as I deeply believe that having a solid knowledge base helps you get much more out of your working hours.

My final conclusion:

While there doesn't seem to be an "ideal" learning path, I lean toward finishing my degree and supplementing it with extra knowledge in the area I'm currently most interested in: Software Architecture. That's why I look to get a high-level overview of different architectural patterns, software design patterns, solutions to common problems, etc., using resources that are easy to digest (like roadmap.sh, YouTube, courses, or books). The goal is to get familiar with the concepts, even if just superficially, so I know they exist.

If I ever need to apply a new architectural pattern that I haven't used before, I'll likely have to dive deeper into it at that moment—and that's totally fine, because that's the right time to do it. But I don't think it's important to read deeply into every existing pattern and concept from the start, because knowledge only sticks when you take it out of the theoretical framework and apply it to a project with real clients.

My question regarding this conclusion:

Does this approach of getting a high-level overview of concepts in my area of interest, and then diving deep only when I need to apply them, sound right to you? Or is it better to further strengthen my fundamentals first, keeping in mind that I've almost completed 5 years of university and have a couple of years of industry experience as a full-stack dev?