The Old Man Who Yells at Clouds in me is convinced that soon the true tell for AI will be things like "used punctuation", "didn't misspell or shorten words", and "used an Oxford comma."
The first time someone accused me of being a bot because I use em dashes for inserting parentheticals, I was flabbergasted and then pissed off. I have plenty of concerns about GenAI, but I honestly didn't expect one of the problems to be "using a wide variety of punctuation is frowned upon". What's next? "Only bots use the Oxford comma", maybe?
That said, this blog post does seem to use em dashes "incorrectly", at least according to what I've been taught. The way I've been taught to use them, they're not exactly the same thing as a comma and you cannot use them interchangeably. But perhaps I'm nitpicking.
(PS: If it's not clear, I'm not the author of the blog. I'm just someone who hates how the GenAI is contributing to the enshittification of communication.)
Their presence isn't enough on its own, but combined with the tone and style, it definitely "feels" like the way chatgpt talks. The blog owner seems obsessed with productivity hacks so I wouldn't be surprised. At least you can feel confident knowing that people who write like you make up a significant portion of its training.
As much as I greatly prefer context-based grouping when I can get it, I find it breaks down in a few significant ways:
Contexts are not always (or even usually?) hierarchical and distinct. This leads to constant variance on if your IAM code belongs in "users", "auth", "access", "api", or even "iam" (and is that nested under something else or not?). Or maybe it's "middleware"? Wait the identity team is called "Galactus"... Every team makes different decisions, and while all may be defensible they're still different and can take a lot of time to figure out. Assuming anyone even knows, and it isn't just rolling along vaguely on its own inertia.
"Directly mirrors stakeholder language" does not always have any bearing on how a thing works or is built. To take the house example, sure, houses have doors and windows. They also have stuff hidden in walls, paperwork that buyers never see, and massive supply chains that nobody actually fully knows - are you modeling those too? They're part of a house's existence. But obviously you're not because you obviously only care about X and not Y... but really, how many times have you run across a business that fully agrees on what X is and is completely consistent on it? Some, surely, but vague sections are often natural because otherwise your market would be a solved problem.
And last (OTOH) but not least: business needs and concepts often change with time. Do you restructure your code to match that? At this point you're knee deep in the first one above, again, and if you don't complete it you're left with confusing tech debt.
---
Type-based layouts benefit greatly from not needing to think about it. Almost everyone is almost immediately able to put things in the right place, and know where to go to find something. Sure, it's a bit of a mess in there, but you've still cut out like 75% of the codebase and the task is now smaller.
Though obviously ^ this can break down rather badly when the remaining 25% is still much too large to search quickly.
TBH I wish we didn't have to choose. There are a variety of ways folks might need to read the code, so why not have multiple views of the project, depending on how you want to look at it?
> If there’s one unshakable prophecy in software development, it’s this: Your code will change.
> Maybe tomorrow. Maybe in six months. But change is coming faster than your next caffeine crash from the coffee you had this morning. Smart developers accept this upfront and set up their projects to embrace it, not fight it.
...this does depend on the project. If you're developing a video game, for example--a single player game like Zelda, not a service game like Fortnite--there actually is a point where your code won't change. Similarly, I used to work at an agency that specialized in one-off static websites tied to particular moments in time. While we did sometimes modify these websites post launch, the edits were minor and generally meant something had gone wrong, either on our end or the client's.
This is kind of unfair to the author. I point this out only because I think it's important to acknowledge that some software really is one and done, and it's important to know what kind of project you're doing. YAGNI and all that.
At the risk of becoming that guy from the tabs vs. spaces meme: Why not both? Name folders by domain or topic and files by role, if you can.
Then any editor with file search can produce the type-based structure on demand.Blog has a unique voice, but also the clear outline structure of a ChatGPT response.
Could be a result of “clean up my post and fix the intro”
The checkbox tables really stood out to me.
Yep, has em dashes all over.
As someone who memorised the key combo for em dashes, curly quotes and guillemot's back in IRC days this notion depresses me.
The Old Man Who Yells at Clouds in me is convinced that soon the true tell for AI will be things like "used punctuation", "didn't misspell or shorten words", and "used an Oxford comma."
Maybe Ken was right: https://bsky.app/profile/kenchengceo.bsky.social/post/3llyr2...
The first time someone accused me of being a bot because I use em dashes for inserting parentheticals, I was flabbergasted and then pissed off. I have plenty of concerns about GenAI, but I honestly didn't expect one of the problems to be "using a wide variety of punctuation is frowned upon". What's next? "Only bots use the Oxford comma", maybe?
That said, this blog post does seem to use em dashes "incorrectly", at least according to what I've been taught. The way I've been taught to use them, they're not exactly the same thing as a comma and you cannot use them interchangeably. But perhaps I'm nitpicking.
(PS: If it's not clear, I'm not the author of the blog. I'm just someone who hates how the GenAI is contributing to the enshittification of communication.)
Their presence isn't enough on its own, but combined with the tone and style, it definitely "feels" like the way chatgpt talks. The blog owner seems obsessed with productivity hacks so I wouldn't be surprised. At least you can feel confident knowing that people who write like you make up a significant portion of its training.
As much as I greatly prefer context-based grouping when I can get it, I find it breaks down in a few significant ways:
Contexts are not always (or even usually?) hierarchical and distinct. This leads to constant variance on if your IAM code belongs in "users", "auth", "access", "api", or even "iam" (and is that nested under something else or not?). Or maybe it's "middleware"? Wait the identity team is called "Galactus"... Every team makes different decisions, and while all may be defensible they're still different and can take a lot of time to figure out. Assuming anyone even knows, and it isn't just rolling along vaguely on its own inertia.
"Directly mirrors stakeholder language" does not always have any bearing on how a thing works or is built. To take the house example, sure, houses have doors and windows. They also have stuff hidden in walls, paperwork that buyers never see, and massive supply chains that nobody actually fully knows - are you modeling those too? They're part of a house's existence. But obviously you're not because you obviously only care about X and not Y... but really, how many times have you run across a business that fully agrees on what X is and is completely consistent on it? Some, surely, but vague sections are often natural because otherwise your market would be a solved problem.
And last (OTOH) but not least: business needs and concepts often change with time. Do you restructure your code to match that? At this point you're knee deep in the first one above, again, and if you don't complete it you're left with confusing tech debt.
---
Type-based layouts benefit greatly from not needing to think about it. Almost everyone is almost immediately able to put things in the right place, and know where to go to find something. Sure, it's a bit of a mess in there, but you've still cut out like 75% of the codebase and the task is now smaller.
Though obviously ^ this can break down rather badly when the remaining 25% is still much too large to search quickly.
The article is essentially an instance of the debate about hierarchical folders vs. tags for organizing a collection of files.
TBH I wish we didn't have to choose. There are a variety of ways folks might need to read the code, so why not have multiple views of the project, depending on how you want to look at it?
It was never a question for me. If you consider visibility by package, domain grouping is clearly the right choice.
> If there’s one unshakable prophecy in software development, it’s this: Your code will change.
> Maybe tomorrow. Maybe in six months. But change is coming faster than your next caffeine crash from the coffee you had this morning. Smart developers accept this upfront and set up their projects to embrace it, not fight it.
...this does depend on the project. If you're developing a video game, for example--a single player game like Zelda, not a service game like Fortnite--there actually is a point where your code won't change. Similarly, I used to work at an agency that specialized in one-off static websites tied to particular moments in time. While we did sometimes modify these websites post launch, the edits were minor and generally meant something had gone wrong, either on our end or the client's.
This is kind of unfair to the author. I point this out only because I think it's important to acknowledge that some software really is one and done, and it's important to know what kind of project you're doing. YAGNI and all that.
this is part of what charmed me about svelte when i first learned about it a while back-- it really does seem like a better way in many ways.
...for PHP projects
tl;dr from the bottom of the blog post:
> Type-based grouping is great for tech-focused tasks, consistent naming, and large sweeping changes.
> Context/process-based grouping shines for domain clarity, team ownership, debugging, and mapping business problems directly to code.