Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

171–180 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#171

Post by mattbillenstein »

William_BB wrote: post #121
mattbillenstein wrote: post #108

Earlier quoted context omitted.

This - even 5 devs. Also rebasing is just so fraught with potential errors - every month or two, the devs who were rebasing would screw up some feature branch that they had work on they needed and would look to me to fix it for some reason. Such a time sink for so little benefit. I eventually banned rebasing, force pushes, and mandated squash merges to main - and we magically stopped having any of these problems.

We squash, but still rebase. For us, this works quite well. As you said, rebasing needs to be done carefully... But the main history does look nice this way.

Why bother with the rebase if you squash anyway? That history just gets destroyed?

Re: Everything as code: How we manage our company in one monorepo

#172

Post by RaftPeople »

eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

> including "no development branches"

Can you explain this comment? Are you saying to develop directly in the main branch?

How do you manage the various time scales and complexity scales of changes? Task/project length can vary from hours to years and dependencies can range from single systems to many different systems, internal and external.

Re: Everything as code: How we manage our company in one monorepo

#173

Post by 0xbadcafebee »

dinkleberg wrote: post #134
0xbadcafebee wrote: post #107

Earlier quoted context omitted.

What's exhausting is seeing people complain about AI writing. What exactly are you looking for instead? A poorly written article?

Yes, we're looking for some other human sharing something interesting. There is no requirement to put things out into the world. So when somebody shares something to a discussion board like HN the hope is that if I'm going to spend my time reading it, they spent the time to write it. If I wanted to read an AI response I could just ask it "Tell me about how you could organize an entire business in a monorepo".

If you ask an AI that question, it would tell you all the ways this is a bad idea, which isn't in this article (which is one of the reasons I think this wasn't written by AI, but just formatted by it)

Human articles on HN are largely shit. I would personally prefer to see either AI articles, or human articles by experts (which we get almost none of on HN)

Re: Everything as code: How we manage our company in one monorepo

#174

Post by hu3 »

fragmede wrote: post #14
radial_symmetry wrote: post #12

I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ for. We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks.…

So the insane thing I do is I don't use worktrees. I am using multiple Claude code instances on the same project doing different things at the same time like one is editing the CSS for the login screen while another one is changing up the settings section of the project.

yep. if the project is large enough, there are usually changes to be made that don't overlap, allowing multiple agents to work concurrently without work trees.

for example I can have a prompt writing playwright tests for happy paths while another prompt is fixing a bug of duplicated rows in a table because of a missing SQL JOIN condition.

Re: Everything as code: How we manage our company in one monorepo

#175

Post by hu3 »

Arainach wrote: post #75
Etheryte wrote: post #44

Earlier quoted context omitted.

So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.

Each layer of your stack should have different types. Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make. A UI-specific type means you can refactor the backend, make whatever change…

Usually you only share API functions signature and response types.

It's tempting to return a db table type but you don't have to.

Re: Everything as code: How we manage our company in one monorepo

#176

Post by ra_men »

dinkleberg wrote: post #134
0xbadcafebee wrote: post #107

Earlier quoted context omitted.

What's exhausting is seeing people complain about AI writing. What exactly are you looking for instead? A poorly written article?

Yes, we're looking for some other human sharing something interesting. There is no requirement to put things out into the world. So when somebody shares something to a discussion board like HN the hope is that if I'm going to spend my time reading it, they spent the time to write it. If I wanted to read an AI response I could just ask it "Tell me about how you could organize an entire business in a monorepo".

Or honesty about the author. If it's written by ChatGPT, say that. If I start to read an article with the expectation of it being written by a human, then see something like this, I instantly check out.

> Last week, I updated our pricing limits. One JSON file. The backend started enforcing the new caps, the frontend displayed them correctly, the marketing site showed them on the pricing page, and our docs reflected the change—all from a single commit.

Re: Everything as code: How we manage our company in one monorepo

#177

Post by ra_men »

johnfn wrote: post #70

This post is obviously (almost insultingly) written by AI. That being said, the idea behind the post is a good one (IaC taken to an extreme). This leaves me at a really weird spot in terms of how I feel about it.

It feels like intellectual dishonesty when it's not declared at the top of the article. I have no issues with AI, when the authors are honest about their usage. But if you stamp your name to an article without clear mention that LLMs wrote at least a significant piece of it, it feels dishonest and I disconnect from it.

Re: Everything as code: How we manage our company in one monorepo

#178

Post by ra_men »

codingdave wrote: post #39

> When you ask Claude to "update the pricing page to reflect the new limits," it can... wat. You are running the marketing page from the same repo, yet having an LLM make the updates? You have the data file available. Just read the pricing info from your config file and display it?

AI is turning in to an addiction and crutch for some people.

Re: Everything as code: How we manage our company in one monorepo

#180

Post by eddd-ddde »

RaftPeople wrote: post #172
eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

> including "no development branches" Can you explain this comment? Are you saying to develop directly in the main branch? How do you manage the various time scales and complexity scales of changes? Task/project length can vary from hours to years and dependencies can range from single systems to many different systems, internal and external.

Yeah, all new commits are merged to main.

The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it.

Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that aren't ready, so you just cherry pick the fix to your release.

It's branches in a way, but _only_ release branches. The only valid operations are creating new releases from head, or applying cherrypicks to existing releases.

Post reply on HN