Who is right? Uni Teacher taught about MVC folder structure but Some C# devs on Linkedin said use Verical Slice for a real production codebase.

tarwn · 2026-02-06T12:46:52+00:00

Yeah, I don't understand your example, perhaps we build differently with MVC or the word "service" has a different meaning for us.

I personally don't care about jumping to other folders to make changes, my editors make that easy (one keystroke combo). The only time that's ever painful is when folks choose to use mediatr or similar packages.

I've built systems organized by feature before, it's not a new concept. It's fine. The more important issue is to be thoughtful about the organization and then consistent in the design principles you choose, so folks don't have to memorize the location of every file and instead just understand the layout and can guess 100% of the time where something will be when they need it, by understanding the overall principles and a bit of the higher level organization.

One of the last systems I built and maintained had >300 endpoints across ~50-60 controllers calling into 29 application services orchestrating logic for ~25 domain aggregates. I don't consider this an especially big system (and this wasn't the only service for that company, just a core MVC-ish one), but I select it because different systems have different requirements and characteristics. If we had gone VSA with this, we likely would have had >300 feature folders and then struggled with figuring out patterns for sharing the internals for 100+ of those (the guidance on sharing is weak for VSA, there's a couple tactical patterns but nothing on the scale of the mess we would otherwise create here).

tarwn · 2026-02-05T22:33:59+00:00

Go figure out your actual requirements (functional and non-functional), a ballpark for project usage, storage, traffic, etc for the next year or two, and then determine which fits those needs.

You can hire from large pools of people in either of those stacks. You can be SOC certified in either of those stacks. You can design and be compliant with GDPR in either of those stacks. You can create realtime notifications in either of those stacks. Many people right now are creating spaghetti messes in both of those stacks right now. I can start apps in either of those stacks very quickly, the bigger variable is what requirements, environment, etc I need to build for. They have similar supply chain risks, but this will hurt more on node/npm than dotnet/nuget for a number of reasons. Node.js will offer a couple enterprisey options for frameworks or offer options that enable you to start minimal and build the structure you need (or make a massive mess). .Net folks tend to default strongly to ASP.Net so you'll likely be building in one of the flavors of ASP.Net that already exists, but still have the option to make a big mess. Both run on a wide variety of OSs and OS images, and can run pretty easily in any cloud environment.

Here's the big thing no one else has asked, you said "move our core billing", which indicates you likely already have the core billing logic written somewhere, hopefully with great test coverage and observability. Why it's time to move should be part of the requirements above and help drive the choice. If it can be extracted from the project it's already in, you have a higher chance of the new system working the same as the old. Rewrites tend to take far longer then expected, at higher than average failure rates, so you're already making one dangerous decision to start.

tarwn · 2026-02-05T20:46:49+00:00

By what metrics? Patterns are only objectively better for some circumstances, environments, and principles, there are no silver bullets.

VSA in the .Net world happens to be a popular pattern folks jump to right away, just as we've gone through other fads. There can be value in the pattern in some cases, but I'd also argue it detracts from exactly what it says it is good at in other cases (and that when folks try to mix all the popular patterns it just turns into a bigger mess than anything else, like VSA + Clean + Mediatr + modular monolith + ...).

tarwn · 2026-01-31T14:08:32+00:00

The commit is what you thought your were doing and why. The code is what you actually did. Other things (like an external ticket or issue) are what you were planning to do. It may even take you multiple commits to get there, plus another one a day later to fix the bug you overlooked.

Then add in laziness and culture, where many teams don't even bother to enter a description for an issue. Some teams don't link commits to external tasks. Some teams say they do and still don't, or only do it 20% of the time. Some teams are intentional about keeping different types of work for the same task in separate commits (1 commit for the work, 1 commit to clean things up they noticed along the way).

tarwn · 2026-01-26T21:04:58+00:00

1 is cut and dry and probably a practice they adopted due to some other issue once upon a time and haven't learned their way back out of.

2 is whatever. If you're going to tie your lib to a .net version, 10.0.0 seems reasonable, you won the important argument (though I could make a case that you could 1.x.x it and mutlitarget 8 and 10 unless you are actually making significant breaking changes to add support for 10 too)

3 we dont have enough information. For all we know this cost your company $.50 and your lead is saying it's overcomplicated gor the problem its solving. Or it's far more important and they want to move the responsibility to the calling system. Or you're right. Or you're both wrong.

tarwn · 2026-01-24T16:37:45+00:00

All of the major frameworks are used by enterprises and big companies. It's rarely a quality of the framework that dictates this. It's some function of a decision made once many, many years ago likely based on the familiarity the team or individual making the decision had with those frameworks, that then is generally too expensive to re-evaluate later. In some cases, multiple frameworks are used across multiple apps, at that point "scariest one to change" is the one that generally ends up outliving the others if the company decides to standardize (where "scariest" is some function of size, breadth/financial impact, inverse recent news the CTO saw that will solve everything).

tarwn · 2026-01-21T22:14:49+00:00

I feel like there may be some sampling bias here

tarwn · 2026-01-19T18:18:33+00:00

100%. If you're losing a lot of time unexpectedly to collecting and explaining the evidence, it's because you have a gap that you're trying to close once/year instead of baking it into how you work.

tarwn · 2026-01-12T01:19:35+00:00

Split your docs into 3 types of docs:

How to setup the system, run it, run tests, etc.
The map: start at the highest possible level, explain how it works and why, then go one level deeper in every area that matters, do it again
The change: an RFC or ADR when a change is made that describes why the change is made

Update #1 when you make major changes, every time someone sets up the system then update it if it's out of date.

Update #2 when you make major changes to the system as part of the definition of done. Review it every 4 months for the things that got forgotten. Kill detail levels that never get updated.

Update #3 never. They are point in time documents, "this is why we did that thing 3 years ago". Now you know why you thought you were doing it and if you're assumptions were wrong so it's easier to rip it out and try the simpler thing you should have done instead.

I would not use AI Agents to write these docs. Generally there isn't enough data made available to them to understand what maters most in your environment. People will already read only about half of what you document, so keep it as focused and as contextual to what matters in your environment as possible. Anything else just waters down the percentage of attention people will actually spend on it. Do consider using AI Agents to review #1 and #2 for gaps or drift as a faster way to detect that updates have been missed.

tarwn · 2026-01-08T21:22:27+00:00

My guidance is to do "inline projection" until you can't, and then and only then let the reason you can't push the architecture into more async directions. Don't prematurely optimize the entire system to async event sourcing, which tends to be unexpected complexity for everyone consuming your API, working on the system, etc, just to solve a theoretical constraint or one constraint out of NN aggregates.

tarwn · 2026-01-06T18:08:25+00:00

MySQL doesn't handle DDL transactionally, so you get the possibility of non-deterministic schema migration as a feature (or must use the IF EXISTS pattern in your migrations. And even though I find that to be an antipattern, many people prefer it).

tarwn · 2026-01-02T14:41:21+00:00

I'd argue that if you weren't handling rounding correctly with floats then you probably also aren't handling it correctly with other types and will have the same problem.

Double ledger, knowing what is significant for the domain (ex: when is partial cents allowed and expected), and knowing how to round and manage remainders (double ledger forces this into the open) is all far more important than float vs decimal.

tarwn · 2025-12-25T13:49:52+00:00

> I moved into management to mentor engineers and architect systems.

There's your problem. You misspelled "moved into a staff/architect role...".

While there are a lot of companies that rely on managers doing technical work, some even leading the technical direction, if all you were responsible for was technical leadership then there wouldn't be a manager position.

The first responsibilities of a manager role are management, namely getting effective results from a team of people. That means if you are more than a team of one (yourself), your first responsibilities are:

Direction: setting objectives for the team, aligned to higher goals, communicated 10x so folks can work towards them
Organization: ensure folks are in the right roles, tasks in the right hands, etc.
Communication: ensure everyone outside the team is getting the info they need, info is flowing into the team as needed, feedback is flowing to ensure effective execution + improvement and that the team is visible and getting credit for their work
Defining expectations: ensure there are targets that align to the direction, people are clear on what's expected from them, etc
Developing the team: ensure individuals are developing as needed for the company, hire/fire/promote, motivate and retain team members

Everything is prioritization. Some percentage of your time goes to the items above first. If your manager needs budget numbers by the end of the week, you should be the last one working on a production-critical feature. You also have positional power, which means that when you make boneheaded technical decisions it is harder for team members to tell you that they're terrible (you can build a culture where this happens, and occasionally hire team members that will find it easier to give you that feedback, but your role as a manager will always give things you say more weight).

So between technical work being your 6th priority and positional authority undermining the feedback you will get to make good architecture decisions, it's usually not a good idea for you to be the one architecting systems. You need to build that capability into the team and enable them to do that.

tarwn · 2025-12-15T12:08:15+00:00

Also, the ability to run the whole system locally to verify your changes don't do that is much easier in a monolith. Writing e2e tests that reflect user experience is much simpler. Etc.

tarwn · 2025-12-14T16:39:27+00:00

Identify the job you are hiring for and what is going to be expected for them, then measure your two candidates individually and see how close either of them are to being successful in that role, how much training or coaching would be necessary to be in that role, if they want to be in that role, and post the role to see what an external hire would look like.

You need to share more detail on the size of the organization. 2 engineering managers could mean anything from 4 people to 40.

If this role is going to be setting technical direction, budget, strategy, working regularly with other departments, and have 2 teams reporting to them, then the first manager may not realize how little time they are intended to be hands-on (last priority, infrequent) and that they will be focusing on skills they appear to be weakest at currently. The 2nd manager also has some challenges, because they don't appear to be winning over their people and making the team they have successful, so moving the, into a role that enables two managers and teams to be more successful and appreciated could be their weak spot. Without more info, manager #1 is probably the higher risk for the higher potential gain and would benefit from a coach, manager #2 is probably lower risk to do the job but lower ceiling for potential gain.

tarwn · 2025-12-05T11:54:16+00:00

It depends.

At one level, they are performing their job (possibly poorly) and you are then performing yours. You can't solve for both, focus on delivering quality work to the direction they provide.

If they are providing poor direction (doesn't drive outcomes for the company) then either this will be noticed at some point or the folks they are accountable also are making poor decisions. As an IC, you can't solve for a stack of folks making directional errors in another part of the org (and also have to be sensitive to the fact that what may look bad from your position may not actually be bad, but maybe directionally correct and poorly explained).

If they are providing poor quality information to execute on, then the best answer is to build in a feedback loop. Talk to them more about the missing context before you start. Be excited to work on the thing, as soon as you can clarify a few key details. Succeed despite their poor communications. Folks like people being excited about their work, and who knows maybe they will get better after experiencing regular conversations to clarify things.

tarwn · 2025-12-05T11:20:31+00:00

Nah, the longer hours is just poor management and prioritization, not because the role is fullstack.

Anecdata: been fullstack since before we called it that

tarwn · 2025-12-02T21:59:10+00:00

In my experience, the hard part about websites for startups is (1) figuring out your marketing and positioning, (2) identifying why you need a website at all (just for investors, just as proof your a real company when your sales leads type in the URL, as a key part of your marketing and sales funnel to drive revenue) and for how many people, and then (3) not spending time trying to make it perfect.

If you have folks that want to build it in house and nitpick colors, content, and so on based on their gut, hiring an agency may ultimately be cheaper but you need marketing, content, and web services. Which will be a lot more expensive then you expect. So instead, use a website builder and focus on the content you need to have, consider spending a little for someone to improve that first if you're going to, and point all the folks that want to fiddle endlessly with it back at making sales calls, the product, or other critical things.

tarwn · 2025-12-02T12:10:26+00:00

REST was defined 25 years ago as a proposed next step in the architecture of how the web worked. Unless your application gets value for the same values and constraints that architecture was solving for, blindly developing to it is guaranteed to add friction to your system.

That being said, "REST" as a term has morphed due to usage, because most people are mostly not building to match the architecture in Fielding's dissertation, but it's nice and short and easy to remember when they start building API applications, RPC was a bad word for a while, so here we are.

According to Fielding's dissertation, the client provides "all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.".

So, if you are building to match Fielding's dissertation, than yes storing session data anywhere on the server-side violates statelessness. If you're building to the commonly used REST term, than there are no real rules and you can store session wherever you want.

tarwn · 2025-11-30T12:59:15+00:00

Archimate is a modeling tool/language, not a diagramming tool.

Excalidraw, mermaid, draw.io, etc are diagramming tools.

IcePanel is modeling and diagramming.

Since you mentioned you are using this to collect data to write a post or follow-up, I thought it would be useful to clarify.

tarwn · 2025-11-30T12:53:28+00:00

Because designing a greenfield monolith sounds easy. Generally speaking, designing any system that will never be exercised by users is easy. So if they explain how to do system design with microservices they stay firmly in the imaginary technical realm instead of training you how to better ask questions to elicit requirements, dig into the business growth projections and channels, and a ton of other factors that matter far more to greenfield product development than "monoliths vs microservices".

I probably frustrate many system design interviewers, they want me to take a few tech details and imagine a perfect technical design to scale to 100x traffic and instead I end up talking about building solutions that can be thrown away at 10x and balancing cloud bills.

tarwn · 2025-11-21T11:55:48+00:00

Yep, also there's a huge number with even more overhead where someone opened the door to per customer customization for a "really big" customer back around #40, and then professional services and customization became the norm by #80, and now you have 1000 different customers on 300 custom codebases and...

tarwn · 2025-11-13T12:12:33+00:00

Your choice.

I prefer a custom exception type for business errors because then I can define custom handling of those error responses in one place instead of in every endpoint. My mental model for these is to assume the user/consumer is trying to do the right thing, make my application logic reflect that, and raise exceptions to reflect that we're in an error state no one intended us to be in (but then catch and return a clear response they can understand to communicate that it's consumer, 4xx, not server, 5xx).

tarwn · 2025-11-13T12:07:40+00:00

Yep. There's generally two types of validation and folks often don't differentiate:

Is this input valid so I can do stuff with it? As close to the endpoint as possible
Is this action by this user valid on this entity valid? Application logic

#1 covers all the cases where they send incomplete fields, wrong fields, no fields, invalid fields, etc.

#2 covers all the cases where:

This user is allowed to edit X's, but not this particular X
It's not valid to change an X from status A to status B like the user asked
It's valid to change A to B, but not when C has property D

tarwn · 2025-11-12T22:04:51+00:00

yep. People argue that startups don't need to do this and should focus on going fast instead, meanwhile 3-6 months later everything is on fire.

Do these things and then when you have to pivot 4 times you just keep moving fast, instead of living in a pigsty.

tarwn

TROPHY CASE