An often forgotten feature of git. That said it is very convenient when we need to juggle several branches at the same time. This can save some time and space.

Very thorough overview of everything you can do with vim but also your IDE vim emulation.

Early days but could turn out useful when it gets more complete. Good way to easily have a CI pipeline targeting mobile platforms.

This is very very centralized. No good surprise here unfortunately... and still email is really tough to fully self-host.

The report is very US centric. Still it looks like the future standard for developer jobs will be more and more remote.

I find debuggers to be underused at quite a few places. A shame when you see what they can do nowadays, and they keep improving!

Neat way to think about array indices, if it was widespread it would simplify a few things in documentations I think.

Very interesting conversation between Uncle Bob and one of the recent critics of his work regarding performance. I like how he admits some faults in the way he presents things and try to improve for later rather than trying to be right. Some people should learn from that. There's clearly a tension between performance and what is described in Clean Code, it'd be pointless to deny it.

Fascinating old school way to manage cables. And indeed the result looks pretty as well.

People tend to be fixated on the "unsafe" keyword and assuming not using it will make their code devoid of memory safety bugs. Well, it's a bit more subtle than this. It helps you know where such bugs can hide but it can't completely prevent them all the way down the stack.

This is definitely a worthy advice with lots of interesting side effects. For me the main motive beyond cheer curiosity is developing more empathy towards others with different roles.

This is an excellent piece. Very nice portrait of Emily M. Bender a really gifted computational linguist and really bad ass if you ask me. She's out there asking all the difficult questions about the current moment regarding large language models and so far the answers are (I find) disappointing. We collectively seem to be way too fascinated by the shiny new toy and the business opportunities to pay really attention to the impact on the social fabric of all of this.

Hiring and interview isn't simple. There are good advises in this piece. In particular I strongly agree with the fact that leet coding is probably not it and that having something guided and scripted it necessary.

Early days for this type of research so a couple of limitations to keep in mind while reading this paper. Most notably: rather small sample explored (it's a qualitative study) and tends to conflate GitHub with "the Open Source community". The later especially matters since the vibe can be very different outside of GitHub.
That being said, very interesting findings in there. Some validate my experience with GitHub. It's clear that compared to other spaces there's much more entitlement behavior from some people. Interestingly the words seem on average less violent (although it does happen of course) than in other platforms... still this is important to keep in check since it could have implication toward prospective contributors.
The last point in their discussion section is promising. Some of the current manual interventions from maintainers seem to have good results (encouraging) and it seems possible to at least semi-automate the handling of toxic comments which could help with maintainers well-being.

The advice is sound. Having more written records of such things definitely help teams. It can have a benefit in other forms (notes or todo's) if you do it just for you.

Indeed, in some type of projects people tend to turn to Dependency Injection Frameworks a bit blindly (especially true in the Java world). Still there are other patterns which give similar benefits without less headaches. That's worth investigating if this fits your context before picking up a framework.

I tend to agree with this quite a lot. Git submodules tend to create lots of strange issues and rather bad developer experience. Even worse it's not necessarily spotted straight away, you notice the real pains only after having invested in it quite a bit. There are alternatives worth exploring though.

A bit of a rant so brace yourselves. Still, it's very much aligned with the current backslash against "everything must be an SPA" trend and makes very good points on how it happened. This indeed turned into a popularity contest based on false premises. Meanwhile... complexity increased dramatically on the web frontend side and the performances are bad for most users.

When they changed their statutes it was the first sign... now it's clear all ethics went through the window. It's about fueling the hype to drive money home.

Very interesting but long state of the art and evaluation of learning techniques. This is definitely something students should look at to pick better techniques. The way I design my trainings and coaching session seem to be mostly aligned with the findings, they tend to foster the right learning techniques... Still that's up to the students to pick up the opportunity instead of repeating usual inefficient patterns.