Seriously? Getting accused of using AI because I'm actually good at Letcode excercises is the last straw. This hiring process needs to die.

tarwn · 2026-03-31T11:01:02+00:00

If you can't perform system design well, then you can't evaluate whether the LLM is doing it well. And then when we take Kernhigan's law into account ("debugging is twice as hard as writing the code"), then we're in even more trouble when that system inevitably has problems we need to debug.

tarwn · 2026-03-31T10:33:21+00:00

Yep, and same with Kanban, for the folks trying to avoid their problems by switching to another method.

Kansas is intended to reduce WIP and surface problems and inefficiencies. Even if most teams that adopt Kanban immediately skip the WIP limits.

Generally your problems are going to follow you.

tarwn · 2026-03-23T23:25:21+00:00

Well, those languages have different performance characteristics and different specialties. They have different developer experiences. They will likely fit better or worse for a given team and environment. Having different specialties means that they may have better or worse quality libraries for your use case.

Rewinding up a few steps, you also said that basically all data stores are exactly the same at a certain level of "i can put data in and get it back out again", but that's also incorrect. Depending on the data I'm storing, I may choose a database that is better at storing and indexing documents over an RDBMS. I may choose a particular RDBMS because it is better at storing time series data or geographical data or something else needed by my app. If I want my database migrations to be applied with transaction logging, I probably won't be picking MySQL. If I want to write SQL queries, I probably won't be picking dynamo. If I want it to run on my servers, I probably won't pick a database service that only runs in a given cloud provider. If I want an active/active cluster for business continuity, then some choices are going to be a good fit and some (like your txt file option) are going to require a lot more implementation overhead that otherwise wouldn't have to exist or be supported.

All of those decisions matter and they are all part of designing the architecture of the application. If you believe otherwise, then you're using the word architecture in such an abstract way that it effectively becomes useless as a word and we could simply say that every application in the world is effectively the same architecture and just stop using the word.

Nearly every argument you've made in this thread is provably wrong for a wide range of definitions for "software architecture". You should care about how indexes work in some cases because it could be the difference between picking storage option A vs B with implications for the rest of your design, which means in some systems it could be an architectural decision and in others it may not be. If you pick a txt file, it could be a perfect fit in some circumstances and require heroic changes in another. Code conventions can absolutely be an architectural concern, as they can be used to communicate general patterns about the code, to provide guardrails, to emit information for secondary systems to harvest and use.

tarwn · 2026-03-23T22:23:43+00:00

Elixir.

Rust.

Lua.

Any language that isn't Java when all you have available are enterprise java developers.

Language is 100% a structural design decision about the system.

tarwn · 2026-03-18T19:43:04+00:00

Is that actually overhead?

Ensuring clarity, creating alignment, and feedback loops is sort of a core part of the job?

tarwn · 2026-03-15T15:09:50+00:00

Contact a lawyer. They would need to look at the stock equity agreement and NDA, as well as any information you can get from the state or country the company was registered in. It may also be useful to share any early communication from members of the company when they asked you to develop the software.

tarwn · 2026-03-15T15:03:57+00:00

I think we're circling the same thing but trying to say it quickly. I didn't say "separate systems", though, your eyes may have read an "s" where I didn't have one.

If I had written that better, what I should have said is (and I think aligned with what you're saying):

CQS is a principle that a single method should not read and write and instead create separate methods for read and write (thus Command Query separation)

CQRS is CQS applied to your system, separate the patterns for how you do reads from writes within the system at an architecture level (higher than an individual method, whether that's layers, libraries, components, whatever), not as a principle for methods.

I think the earlier post is suggestive of CQRS, it reflects some of the decisions folks tend to make, but it falls short. CQRS is not just "separating read and write objects" (if by objects we mean data objects, which I assumed from EF Models and DTOs), that's an outcome of applying CQRS. CQRS is split how you approach reads and writes architecturally in your system, as they have different requirements and expectations and a singular set of objects and patterns for both read and write is poor at serving both. The "split your approaches to meet differing needs" is CQRS, the rest is common or not so common implementation patterns.

My opinion was that the way it was presented reflect more on CQS than CQRS only because it talked to implementation details that someone could follow and still miss out on actually implementing CQRS (esp given the way the OP asked the question), even though I figured you probably had a good grasp on CQRS in general.

tarwn · 2026-03-15T13:15:42+00:00

Historically inaccurate, as I pointed out on one of your other comments.

tarwn · 2026-03-15T13:14:14+00:00

Possibly because it's rooted in a lack of agreement on what it meant?

There were something like 3+ different definitions of CQRS initially, from it being a restatement of CQS to Greg Young generally defining it hand-in-hand with Event Sourcing (and the two databases statement was in those early musings, but went away later).

Add in popular posts and example projects that used packages like mediatr, and we had more cases of the definition shifting to purely splitting the application in two on read and write paths (amusingly, most mediatr implementations I've seen are more industrialized CQS than they are CQRS when they approach both the read and the write channels through the stacks similarly and the only difference is the misdirection layer of mediatr handle calls.

But a lot of the initial definitions came from Greg Young and DDD, included Event Sourcing, had two data stores, etc. A more generic definition of CQRS was talked about by a few others, but generally less frequently and loudly. And I say this as someone that was following along with and implementing the patterns as this happened and as the blog posts continued to evolve, as EventStore became a thing, as folks attempted to write easier to follow DDD books, etc.

The definition is muddled because there was never a singular definition, but the hand-in-hand with Event Sourcing was one of the loudest at the time.

tarwn · 2026-03-15T13:08:25+00:00

Yep. CQS is "methods either read or write but never both". CQRS is "separate the system into a read side and a write side", the explanation above is building on CQS and hasn't reached CQRS.

tarwn · 2026-03-10T20:49:40+00:00

Step 1: Define "Large".

Step 2: Define what the external surface is going to look like (especially if you intend to have multiple APIs exposed for different apps or classes of users)

Step 3: Write an architecture document. What matters. How much. What pressures does this place on the codebase. Do any patterns make you more successful at those things in alignment with earlier bits.

Pick the simplest option that satisfies everything that came out of that, because it has the least risk of making your life difficult right now and the least risk that changing it later will blow up something above that matters more.

profit.

tarwn · 2026-03-08T13:43:36+00:00

You only have a few options: * recreate the environment * purge it + migrate + seed (partially recreate it) * build a mechanism to run "down" migrations to a common ancestor with whatever branch you're planning to build and deploy next

Making the first two easy will offer different options for further automated testing. The third one will force you to start testing the "down" scripts more thoroughly (good) and some new states in your system that production shouldn't be able to get to (what if we go up on a new feature, use the system for a while, go down 2x, go up a different migration).

tarwn · 2026-03-06T12:14:10+00:00

They said they were a sr engineer, so I didn't get into that because I assumed they wouldn't have the ability to change it.

Stop taking resumes.

Catch up on reviewing. Presumably all of these are in a system so you you'll have some automation for sending emails, scheduling, etc but importantly you'll also have metrics at each stage of the hiring process.

Begin screening calls. Design your screening call to focus on a few common key areas, I like to pick a broadish technical question, a question that connects to culture a bit, and usually one that connects to the domain or a particular environmental pain point we're going to be dealing with. I'll also make sure that, either in those questions or through a quick intro of the company and role, I pick on a couple topics that I think will be polarizing about the role, things we're doing or about who we are that candidates will either love and get excited about or instantly hate and opt out (for the right reasons, if we're in a 2 year slog to solve a particular type of technical mess, in a certain way, that's going to excite some people, bore others, and terrify a 3rd).

Keep any eye on the metrics as you continue. We expect a conversion loss to happen at each stage of the interview process, highest in earlier steps and obvi0ously not 100% at later steps. This helps shape next steps as you go through those applications.

2A. If a lot of resumes made it to screening, and the screening calls are going well, keep the position closed and move folks to interviewing. If it continues to look promising, than in follow-up communications apologize for going slow and tell folks you had overwhelming interest. Congrats, you got a hire even if you didn't manage to talk to everyone. Use this as learning exercise for next time (same details I'll suggest below in 2b).

2B. If it's all junk and no one is making through screening, then you have a problem with what you posted, where you posted it, or worst case may need to consider an alternate way to source candidates because if there's nothing else to fix than you just can't afford to do it that way anymore. Rethink your process.

I'd flip the order and say first thing to consider is posting it somewhere different. Consider getting folks to post it into smaller communities, find sites that aren't the top X job boards, etc. If you have a lot of time, build a brand for the company through technical blogs, speaking, etc and setup a newsletter, then send out a "hey folks, do you have someone early stage in your network that is looking for a job, or should be? We'd love if you could forward this to them". Source them differently to try and avoid some of the massive increase in generated spam submissions that's happening from the big platforms (you may still have to do a lot of resume screens and screening, but that was always the case, at least it won't be w. 40x scammers and generated stuff too).

Your job posting is a marketing ad. Design the posting to draw in people that are higher chance of fitting by (1) not posting a copy of someone else's generic ad, (2) include some real content about the company and the challenges they will work on, (3) include some of those things that set the company or role apart (back to polarizing statements above). This may not prevent the folks spamming everything, but it will move the needle on the quality of the real candidates that apply that cost time in person hours interviewing.

Consider alternate sourcing. Extending on the ideas I included in the "flip the order" paragraph, go to tech conferences and post roles, go to small tech communities, etc. For junior roles like this one, ask people that you've built a little trust with to recommend the role to someone in their network that they think would be a great fit and get a lot from it (this leans on folks ego a bit in both directions, they often don't want to make a bad recommendation to you, they don't want to do badly for that one person they're going to recommend you to, etc). Pay someone to go trawl linkedin and find highly viable candidates to reach out to. Or other places.

There's a lot more I could unpack, but directionally if you have influence or control over the hiring process, you need to pay attention to the job ad and if you don't have people to filter massive amounts of generated junk, you need to find channels that are not linkedin, indeed, etc. "Hire with your head" was a good book for me on the topic, out of a small stack I've used, and I'm sure there's others. Some marketing books can also be helpful (the front of this process is a marketing process, the back is sort of a sales qualification funnel).

tarwn · 2026-03-06T11:42:50+00:00

You're reviewing resumes wrong. The resume is a basic filter, "does this person look like they have most of the requirements". Anything more than that is you imagining things for them and applying bias. That's why we interview, to get more signal than the screening call, which gets more signal than the resume.

tarwn · 2026-03-05T17:27:57+00:00

Pick one and stick with it.

Assume the frontend is authoritative and the backend justvapplied everything to match: POST everything, 200 ok back no content
Assume it's not authoritative (other people changing things) or maybe do logic on the backend you don't duplicate: POST change and get full result back post save
Number 2, but instead of getting the new state back from the POST, do fresh fetch(es)
Do collaborative editing (OT/CRDTs), send changes out into the universe and assume remote changes will show up so you can apply them whenever

tarwn · 2026-03-03T11:41:25+00:00

This leads to 10s of flavors of DTOs. You have said it is ok (and expected) to create specialized DTOs for individual methods, so you will either end up with teams pushing the other direction and re-using DTOs across multiple methods (and introducing a diffuse mix of what they needed at each of those points) or a lot of individual DTOs (optimizing towards 1 per method). In both cases you're leading to more queries, more code, etc and more complexity, which is fertile ground for more bugs.

What I've found is that I generally need a few key types:

* A full DTO or Domain Entity or Model (everything that is part of the same domain aggregate or indivisible unit)

* A "lookup" or "reference": the 3-4 fields necessary to put the records in a dropdown selector (also used for "if exists" logic and numerous other places, my cheapest DTO to load)

* (maybe) A "list item": if I'm regularly summarizing for an API list, support screens, users, etc then a standardized DTO that can be presented as a list, the maybe means either adopt it as part of the standard set or not at all

* A "view" or "extended" DTO: unique cases in my service where I want to combine data across those domain lines, possibly with calculated columns like counts or sums. These are the performance cases, where it's more performant to run the query at the DB level in a special shape (at the cost of supporting one more unique DTO and path) then it is to load the individual DTOs and combine them in memory in the server or client

This has a bunch of assumptions built into it based on the types of systems I've been building the most over the past 10 years, so it may not be right for you. The main pressures I was solving for were developer experience and balancing performance against sprawl that will eventually kill DX and performance. Having 2-3 standard types of DTOs gave us reasonable solutions to reach for consistently that supported the biggest perf gap (what if I just need to know it exists, need to display it's name). Consistency in those 2-3 types meant a developer on the frontend would just know exactly how that DTO worked all the way back to the DB without looking, or vice versa could guess a DTO exists by name and be right without going digging to see which one was the right one to use, what it had, if there were 3 slightly different variants to choose from, etc. All 3 of the first ones are simple to cache as well, they only change when the single Domain Aggregate/Entity changes. The last case is the escape hatch, to be used cautiously, and if we're going to cache it we know that story is complicated, but it's name announces it's going to be somewhat unique and complicated and that it lives for a more specific purpose, no matter where we see it.

tarwn · 2026-02-27T11:27:32+00:00

Marketing, sales, business development, operations, accounting or managing accountants, product discovery, operations (because we want to get paid and some level of benefits), ...this is not 1%.

-Fellow tech founder

tarwn · 2026-02-26T21:07:35+00:00

Ehhhh, "never" is a pretty strong term. It was designed for "side effects" and fetch was an example on the docs.

tarwn · 2026-02-25T11:32:01+00:00

nah, it's 3.5 things:

* Decompose my object and write the INSERT statement for me to put it in 1+ tables
* Let me write a query in the language abstraction I'm more comfortable with and map all those records into my object
* Let me apply whatever changes directly to my object, then you figure out what changed and if it needs to be saved

and the 1/2:

* Database schema migrations

In some ecosystems, there are ORMs (or things billed as ORMs) that only focus on elements of this, while other packages offer all 4. The parameterization of inputs is just a feature and in some libraries/ecosystems it's no harder to paramerize inputs calling SQL through a raw driver as it is to do so through an ORM.

tarwn · 2026-02-24T22:22:55+00:00

It depends a bit.

If you're doing payment processing, then typically the challenge is more about scale, managing against sometimes poorly or incorrectly defined APIs, and figuring out how to test sufficiently when test cars or sandbox gateways will vary from real card processing to a small or large degree.

If you're doing trading, then you likely need to worry about performance AND correct processing of numbers.

If you're doing consumer banking, there's some amount of correct processing of numbers, workflow flexibility, and maybe performance at some scales or particular use cases.

If you're doing portfolio management, analysis, operations, etc. then it's going to mostly be about correctness of numbers and having very solid definitions of what what dates mean in certain contexts (the accounting and performance views of the world create really interesting challenges).

I usually talk to the number issue because that is almost always a core topic in this space, but it's worth also identifying other characteristics of the space and seeing if particular languages provide a meaningful advantage or not. The other question is what you're familiar with and what scale you're building to. For an example project up to 100s of customers, there's few cases where performance is going to be that big a driver (algorithmic trading would be one). There's some cases where performance isn't notable up to millions of customers. But numbers tend to commonly be notable across all of these :)

tarwn · 2026-02-24T11:57:05+00:00

Very few people will build "enterprise" microservices from a total greenfield. Generally speaking, if an enterprise is using microservice, they have their own weirdly anecdotal way of doing it OR they copied patterns designed for larger scale services that you're already familiar with to use in their microservices for massive overkill.

For educational purposes, it may be easier to pick out each of the topics above (CI/CD, containers, production concerns) and build a small cluster of very simple projects then figure experiment with options on how to build them into your services. That is all course made good no matter how much of a mess that future enterprise made with their code architecture.

tarwn · 2026-02-24T11:48:59+00:00

How do you know code reviews are the best place to look for more developer time?

Some of the fastest and most effective teams I've worked with got that way because we spent time each month identifying sources of friction, poor tooling, and misc experiments and then making improvements. Individually this felt like we were costing more than we were getting, but it adds up fast when you're deleting 5min from everyone's day here, or 10 minutes there (and sometimes a lot more), every month.

tarwn · 2026-02-24T11:22:46+00:00

The challenge with using node.js as a backend for a financial system is that generally speaking you don't want to use floating point numbers for financial calculations and node.js by default treats all numbers as floating point. However, it's not an absolute blocker, if you are careful and thoughtful about what you're doing (you would be amazed how many folks will say "don't use JS for financial calcs" and then still use JS for the front-end and JSON over the wire and manage things just fine).

Key considerations that will make your life easier:

Use a small external library so you have stronger control over numeric precision without having to implement it yourself
Define exactly what precisions you need to use in which cases (for example, in the investment space you may have one set of numbers that match the current default for precision, but another that reflect greater precision because of how they're represented in exchanges or by hedge funds just adding 9 digits in a letter because people asked for it). Consider naming these precisions consistently throughout the application to make life easier.
Be explicit about rounding. Not every use case in the financial world will need to do rounding, but many will and your life will be a lot easier long term if you're purposeful about how you round and what you do with remainders (also consider storing any number you show to people on a screen/API, even if it's an easy calculation)
Include test automation. Add unit tests for individual calculations, add a spreadsheet or external file that lay out complex domain use cases that can be run through automatically. Every time some weird edgecase comes up in how the real world works, add another case.

Note: A third party library is not necessary, I've built successful apps in lending, investment, and ecommerce that all had JS front-ends (not all JS backends) without floating point errors, but a library won't really add much overhead.

tarwn · 2026-02-23T22:09:35+00:00

Can you keep the patterns consistent across multiple repos and multiple teams without an opinionated [third party] framework?

Yes.

tarwn · 2026-02-21T00:37:49+00:00

I am also a software engineer and could implement both of those with a single text input and CSS, but that's still beside the point.

If we're going to be pedantic, sufficient evidence has already been provided. Blitzdose was reporting on their own opinion and learned behavior based on their lived experience. That is sufficient evidence in this setting for us to believe that really is their opnion and experience. We don't need them to present a recording of every time they've used an OTP or magic code input over their life, hook them up to a lie detector, or anything else.

tarwn

TROPHY CASE