I've been working with government entities for document management for 15 years now, writing software that does exactly what we are talking about - versioning, tracking, publishing legislative records both through the authoring and approval cycles and then to the public. I have not worked at the federal level, but with small government - school districts, small towns etc.
Those years tell me 2 things:
1) Yes, absolutely version control for legislation is critical.
2) That doesn't mean Git is the right answer.
Since I don't work at the federal level, I don't know what system they use, but I do know that their workflow is already based on specific changes - they will write up the changes to a document, then apply the changes and publish a new document. Those documents are posted on congress.gov. So they do have a versioning workflow and public accessibility, just not the same style as software devs are used to. I'm sure it could be improved, but I'm not sure forcing them into our working style is the right answer.
The real goal here is not "Use Git". That is an implementation detail, and one that has also been presented and discussed quite a bit in my niche of the industry. Mostly, it is unwanted. Or was unwanted the last time the discussion went around. Git makes sense to software engineers, but not to the general public, and not to any of the document authors I've worked with. Maybe we can add a UX layer to fix that, but that isn't the bigger point...
What we want is to work towards the actual goals: For the tracking to be more detailed, with more transparency including not only authorship of the change, but the source of the change. And presumably, some commentary as to why the change was made. Then all of that should be available to the public.
If git works as a data structure that supports a solution that meets those goals, fine. I'm not anti-git. But when designing solutions, we need to start from the goals of the system, not the data layer. And we need to design solutions that the document authors will actually use, not force them to work like us.
It is almost like LLMs have gotten over their initial tells and now the tell is that they write these walls of text. This article reads just like the walls of text that my coworkers at one of my gigs paste all over the place. Any single sentence looks OK, but the overall wall has no flow. No cadence. No difference in tone between stating facts and drawing conclusions. Headers, lists, and charts thrown in for variety.
I'm not sure - maybe humans can write like this, too. But it is the written equivalent of a monotone voice, and I find it very difficult to keep enough attention to read such articles, regardless of their authorship.
Scared of what, exactly? It looks to me like the site is primarily static content, so operational costs should be reasonable. He could scale down to just static content, and even if traffic decrease, it is not an existential crisis. Or am I missing something?
No, but is it a reasonable assumption to think it is Zero? Or that the upkeep is Zero too? No.
The blogpost literally says he's making this his full time job. What's reasonable is to ask how that will pan out. And to, after answering oneself, tell the relevant party to be weary of it.
I can only assume DO took a bath on this. Buying CSS Tricks from Coyier to largely sit on it silently before rolling it back off the books seems like a terrible investment strategy.
Attract an audience of people who make purchasing decisions, then attract sponsors who want to be put in front of those people. Quality of readers is more important than quantity.
You're saying that like it's straightforward hard work. But that strategy has been on the decline for years, with no sign of reversing. High-value technical audiences aren't Googling for educational articles, videos, and courses. They're just asking LLMs, and getting answers. Sometimes the LLMs are searching the web, but LLMs approximately never click on the ads.
I didn't say "easy" either, I said "straightforward hard work."
What you're doing is hard work, but it's way more straightforward than building out CSS Tricks.
You're a successful marathon runner. CSS Tricks will have to run a marathon with both legs tied together.
What makes your subject matter (LLMs) work is that it's a very fast moving topic, much faster moving than CSS, so people come to you for news.
Plus, it's difficult to test new models effectively, so people are looking for trusted names to do meta analysis, fast. Is the new OpenAI model better than Claude? Better how? Quality of output? Evaluated how? Even comparing prices can be difficult, as different models (at different settings) can generate different numbers of tokens (and different numbers of cached tokens) for the same tasks.
None of that applies to CSS Tricks.
CSS fundamentally can't move that fast, as long as changes in CSS require Apple, Google, and Mozilla to all agree on standards. Hardly anybody needs to know about the latest CSS news. Mostly you only need to know about Baseline Widely Available CSS features, which are at least 30 months old by definition. And when you do learn about new CSS features, it's usually pretty obvious (either to you or to an LLM) whether those new CSS features apply to something you're working on.
It's going to be very, very hard to keep CSS Tricks alive, even with a lot of hard work.
Something can be both simple to execute and extremely difficult to execute well. Simple and easy are not synonymous.
> High-value technical audiences aren't Googling for educational articles, videos, and courses. They're just asking LLMs, and getting answers.
You're right, but the high-value audiences are also looking at the sources the LLMs cite, guiding the LLMs to use specific source and exclude others (even if it's just "eschew blogspam and listicles" in the prompt). So being one of those sources is still valuable. Perhaps less so, but it's not without value.
I published a magazine for a few years. Off the top of my head:
- publishing is fucking hard. Early on, you need a constant stream of dependable writers who do not value their time. Later on, you have a constant stream of writers but have to figure out who will make you hate your life the least.
- good writers are flaky and they always have options. A little less than half of good pitches get published. 100% of good pitches take work.
- there is a difference between good and dependable writers. Early on, you need dependable even though each one eats a lot of time. Layer on, you need good. You won’t know when to switch until your readers tell you that you suck. Then it’s too late to save your publication.
- I published before generative AI was possible but at each stage of popularity, I dealt with more PR shit bags. Add in generative AI and I’m not sure my naïveté would have survived as long as it did.
- at its best, publishing is a very expensive way to harm yourself. Back in the day, Jim Rose would have paid me to fuck myself up in equivalent ways. Naïveté convinces you that you’re changing the world through self flagellation, but when that’s gone you’re just beating the shit out of yourself.
- my co-founder handled editorial and I handled publishing. The gap between them is so massive that we really needed double the headcount. Alas, publishing is totally fucked so our budget was so low that we needed slave labour yet couldn’t even afford the slave in the first place. Without the editorial/publication divide, I would have had a heart attack five years before I did.
- there’s this thing in publishing called the trough of zero ideas. You won’t believe it’s possible in the beginning but it will hit you hard. It’s not so much there aren’t ideas; it’s that you’re tired and ideas stop feeling good… they feel like work because they are.
- in publishing it’s really easy to come up with business models. Unfortunately, every single business model requires consistently exceptional content, a reality distortion field and a lot of hand holding.
- all those membership plans etc will be invaded by sales or PR fucks as soon as you launch them. $25 a month makes a lot of people feel entitled to explain your dreams to you.
Edit - This sounds very negative and it is… but I want to publish again.
I know 2. That is out of the 3 people that I live with. Sure, this household is probably an outlier, but I think people inside the tech bubble do not realize the depth of the anti-AI sentiment from outside the bubble.
I dislike that. IMO, if the content cannot stand on its own, it did not need to be posted. A comment that adds something to it, to initiate a discussion, is fine. But a comment that just says what that post is? That is neither interesting nor engaging.
Such comments also encourage the idea that people "own" the threads they start. I've seen people get mad when people take the conversation in a direction they did not want, or add instructions telling people what to talk about and putting constraints around discussion. Such things stifle interesting conversation.
So I land heavily the opposite direction. Just post, and leave it at that. If the community finds it interesting, discussion will ensue.
Now, Show HNs are their own thing. An initial explanation is absolutely appropriate for a show HN. But it should be part of the post, not a comment.
Intriguing concept, but I don't really trust the listings site.
You need to order a car, then email them what you want, then they'll find a car for you. wat? Why are there listings if you need to email them to have them do a separate search?
Then, if they do find one for you, you need to pay $2000 before any inspections happen, which they say is refundable... but I am not sure I trust that.
And then if you follow the process that far, you pay $85 dollars for inspections, which is not refundable. Sounds like an ideal loophole to let them collect that $85 many times on the same car by just telling people, "Sorry, it failed inspections... want me to search for another?"
It’s a vehicle finding service. I’ve used them before, they’re usually legit. You provide them the specs and your requirements, they go into the market and find you the vehicles to pick from. They charge a fee for facilitating the transaction as most brokers do.
This is a clever white glove tariffs hack around protectionist policies. If it works, it works.
The problem I'm seeing is not with vibe coding itself, although it is absolutely the LLMs that empower people to fall into the actual trap: Failing to do any research whatsoever into their market and subject area. They see one surface-level problem and instead of digging into the problem space to gain a deep understanding of what would make a solution good or bad... they just code. Vibe code, code by hand, somewhere in the middle, whatever - the current trend is to code first and ask questions later. Some people always did that, but these days it seems like everyone who has not built products before is doing it.
We're seeing it more and more. Someone whips out an app independently, launches it, then says, "How do I find users?", "Why does nobody use my app?" With the answer always being the same - they skipped the step of actually talking to potential users before coding.
So we see what is being described - lots of throwaway projects.
I bought a small forest. They are not actually expensive in my area. I love walking out of my door when work gets frustrating and walking through it. So yes, the answer to your question is definitely "Yes." But there are middle grounds between dedicating your life to the modern tech dystopia vs. completely walking away. Work remotely. Find a home that is in a natural setting. Go outside and enjoy it.
You might be surprised just how many homes run on a well and septic system. Day-to-day, walking into my house, you wouldn't even know the difference between my home and one in the city. We also don't need to chop firewood. My completely standard modern furnace runs on gas, just like ones in the city. Admittedly, I need to supply the gas, but that infrastructure is also well-solved. I just need to make sure to order more when my tank is near empty, and a truck shows up and fills my tank. I pay them instead of the utility companies.
What is more likely to throw you off is services like trash. There is no centralized trash service that just picks it up. You need to handle it. Most of the time, people still hire someone to do it, so it also ends up being the same as living in the city, but you need to actively seek out a solution. Or DIY - I know plenty of folks around here who don't mind taking their trash to the dump once a week or so.
And you cannot order food for delivery. That simply does not exist here.
Not that you are wrong that if we had to go back to living like we did hundreds of years ago, it would not be comfy. But the reality of living out in the country is not as different as you seem to imagine.
Oh that's for sure, I thought OP means literally living in a forest like people a few hundred years ago.
Actually, in the small towns that I described in my reply, people live in homes exactly like yours -- they don't have city sanitary pipelines so they use septic tanks.
I actually don't know about trash! Thanks for reminding me. And I agree with the food part, although I'll probably cook mine.
Those years tell me 2 things:
1) Yes, absolutely version control for legislation is critical.
2) That doesn't mean Git is the right answer.
Since I don't work at the federal level, I don't know what system they use, but I do know that their workflow is already based on specific changes - they will write up the changes to a document, then apply the changes and publish a new document. Those documents are posted on congress.gov. So they do have a versioning workflow and public accessibility, just not the same style as software devs are used to. I'm sure it could be improved, but I'm not sure forcing them into our working style is the right answer.
The real goal here is not "Use Git". That is an implementation detail, and one that has also been presented and discussed quite a bit in my niche of the industry. Mostly, it is unwanted. Or was unwanted the last time the discussion went around. Git makes sense to software engineers, but not to the general public, and not to any of the document authors I've worked with. Maybe we can add a UX layer to fix that, but that isn't the bigger point...
What we want is to work towards the actual goals: For the tracking to be more detailed, with more transparency including not only authorship of the change, but the source of the change. And presumably, some commentary as to why the change was made. Then all of that should be available to the public.
If git works as a data structure that supports a solution that meets those goals, fine. I'm not anti-git. But when designing solutions, we need to start from the goals of the system, not the data layer. And we need to design solutions that the document authors will actually use, not force them to work like us.
reply