But the em-dash is a different character. I think even those that use a pause would just opt for - on their keyboard, whereas the em-dash — requires additional work on most (all?) keyboard layouts. It's _not_ more work for an AI though hence why it's a tell.
My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default.
Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.
Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.
Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history.
This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.
If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.
I know devs are a different market, but how many folks do we know daily drive Mac/Linux and use MS dev tools? VS Code, Typescript, .NET?
I think they'll do just fine if Windows dies on the vine. They'll keep selling all the same software; even for PC gaming they already have their titles on Steam.
Citation needed. For both the existence of said people (how do you develop said design sense without a ton of coding experience?) and that they are 100x more productive.
If you produced 1 line of code per hour before "AI" because you suck, and now produce 100 lines of code per hour with AI, you are now a 100x programmer.
I'm joking of course, but that's probably how some people see it.
No I think you're 100% correct. But these people also miss out on the irony that using "lines of code" as a metric is a literal meme amongst software developers.
In Instagram's case, they do not use the ORM or Admin, and have an internal fork of the request handling/middleware stack that is 100% async (before the recent async bits were added to Django)[1].
It's great that Django's API design allowed them to move this way easily, but they aren't actually using Django in the traditional sense because it can't handle their scale.
I've found that with the Django ORM and DRF especially, it's very easy to create a poorly performing app by following the established patterns (N+1 queries being a huge problem created by DRF serializers). You need to be extremely diligent to create something performant in this ecosystem. Not every dev team has Armin Ronacher :P
Where I work we found this exhausting, and moved on to FastAPI and ASP.NET. We make our queries much more explicit using tools like Dapper, and now a senior engineer can have a much better idea how a particular route will perform just by reading the code (obviously, we still do some profiling).
Also, I doubt solving Instagram-level scale issues is on the top ten list of concerns for this project. Just getting something out there and gaining users is way more important than solving far future scaling issues.
reply