

How we fully migrated github.com away from CSS-in-JS.
yay 🙌


How we fully migrated github.com away from CSS-in-JS.
yay 🙌


The Media Player Remote Interfacing Specification (MPRIS) is a standard D-Bus interface which aims to provide a common programmatic API for controlling media players.
This metadata is only for media streams, not something that would be embedded as metadata in a file?


My colleague who didn’t ask nor describe his changes now generates descriptions and code comments through AI and it doesn’t improve anything. It’s verbose, imprecise, confusing, and irritating.
I wonder if and how much communication reduced with my other colleagues. I guess probably a bit where they now ask AI (first). But not significantly, in my team, luckily. We still regularly talk. But maybe it’s on a path of reduction right now. I would find it sad and bad as well.


It really is a very visible demonstration of human faultiness.
A reasonable engineering approach would have been an interesting new technology with open discussion and assessment and expansion of exploration. Instead, we get hype cycles and hyperbole claims and lies primarily driven and publicized and repeated as market marketing and investor marketing and an industry driven by money and investment rather than technology and reasonably explorative and increasing usage.
It’s sad and tragic. But not surprising. It’s a consequence of human psyche, social constructs and market and society system structure.
When I hear my colleague does a presentation differently for internal towards developers with more reasonable AI takes and a different one for external which basically practically joins the AI hype instead of voicing boundaries, it’s pretty sad that it can’t be honest communication throughout and be understood as such.
I don’t see it as an isolated fault of “corporate leadership” as in of development factories/teams. It’s a broad issue, from the AI companies, press hype, industry hype, to then corporate and broader industry leadership eating it up and implementing and expecting marketing and hype claims.


Pretty cool, interesting, vibrant UI on the website.
Breaks the norm, but not necessarily in a bad way. Given they’re an accessibility expert I assume it remains accessible. :P


What kind of criteria or tests are you imagining?
A certificate after a test would only show capability, not continued practice. So my confidence in it wouldn’t be very high. Demonstrated practice seems more applicable than some cert some time ago. Some people chase certs to check boxes rather than prove or apply the practice.
Where can I find your blog? ;)
I hope my drive-by PRs don’t come off in the same way.
For example, as the simplest no-description, no-comment example, when I see typos or wording errors in text on a random blog I check if there’s a direct way to contribute - to GitHub edit and submit a PR, and when there is, I do that.
There’s nothing for me to say or describe, really, and it’s not like I interacted with their project or community before or even plan to after. (Sometimes I do look into the issue tracker etc depending on the project or website. But that’s beside the raised concern.)
I see it more of a collective and open collaboration. But that’s not necessarily visible on the receiving end.


Their first comment provided reasoning. This “because that’s the way it is” framing is unfair.


The decision to use a non-deterministic system is a decision you can attribute risk and risk assessment to.
The non-deterministic nature and risk is something we should consider and take into account just like any other attribute and property of algos, tools, systems, libraries, etc.


Now that Safari has random() (and Chrome has it behind the Experimental Web Features flag),
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/random
Chrome canary, Firefox nightly, experimental


I have a colleague where I get more confused when they explain things to me. I have others I can understand just fine, because their explanations make logical and structural sense.
Reasonable questions about surrounding context and environment and common understanding aside, having to do questions to “fix” bad communication and explanations sucks.


I think the title and this 30s framing sucks, but the other/later points they make are broadly good guidelines. A mindset of trying to understand context and environment surrounding the question or change at hand. It’s certainly necessary to maintain and improve long running projects.


As a software developer I’ve always been a product engineer as well. AI tools did not change that for me.
Coding, reviewing, and ops is certainly not gone nor disappearing fast for me.


Please don’t meat-proxy.
What is meat-proxying?
A meat proxy is a human who forwards questions to an AI and forwards the answers back — adding nothing but latency.


use something prebuilt and cloud-hosted
That’s what these platforms are marketed as, though.
They provide a platform and expertise that allows you to build your branded website.


Windows Terminal, default windowed, 160, maximized/fullscreen 280


The demo doesn’t seem to work on Firefox.


So my main point is to stop asking whether and how code review in its current form can be saved, but to have an open conversation about what we are trying to achieve here and the costs and benefits of alternative models.
What would these other models be? The article assumes LLM-generated code leads to the loss of current review processes, which they call ‘modern reviews’.
I feel like my team does and will continue to do reviews for the same reasons and with the same gains as before. LLM may generate code, but I expect my colleagues to take ownership of whatever they produce, to understand it, take responsibility, and describe it. (Which is an issue/gap for some, but that was an issue even before generating code.)
For me, the same rules apply, but as you say or hint, SQL as a language is different from higher, “structured” programming languages.
Adding comments on subqueries, applies, conditions, doing deliberate line breaks or oneliners, procedure comments and documentation where they make sense - most of the same things apply and are applicable. Structuring and commenting works quite well, until it doesn’t for performance and readability reasons where you don’t want to introduce additional procedures or functions or separate other aspects.
In those cases, it is what it is. Often comments can live on the lines where the aspect is.
I also like to use block comments with open and closing block indication like
-- \ Table or aspect something stuff \ […] -- / Table or aspect something stuff /The language doesn’t provide the structure for it, but I can still implement that structure through text comments alone.