Or why it's important to mentor others and not stay in your own bubble.

If there's one area where people should stay clear from LLMs, it's definitely when they want to learn a topic. That's one more study showing the knowledge you retain from LLMs briefs is shallower. The friction and the struggle to get to the information is a feature, our brain needs it to remember properly.

Unfortunately and as far as I can tell we're still not there. I'm trying to do my part in how I push for those topics when working with teams and organizations. So many things to help with on the practice level and making developer teams function properly.

This is definitely a skill which is hard to teach an learn. When it sticks it brings really nice results though...

An interesting way to approach the topic of GPU programming nowadays. It might indeed make more sense nowadays than reaching for putting pixels on screen as a first objective.

The approach is good, the results are encouraging as well. Not much effort and a very visible change. We need more such initiatives.

Indeed, is it that the language itself has a steep learning curve? Or that the emphasis is on the wrong things in the public discourse? I like the emphasis on the Aliasing Xor Mutability, it looks like a good way to approach the language.

This is one of those workshops I like to do with teams from time to time. Didn't do it for a while. I wish this resource was on a safer space than google docs.

This looks like a really fun workshop. Been wanting to run one for a long time now. Somehow I never had the chance.

This is I think the most worrying consequences of this current hype. What happens when you get a whole generation which didn't learn anything related to their culture? Is Idiocracy the next step? How close are we?
At least, it will have made very obvious the problems with how our education system evolved the past twenty years (if not more).

I like this attitude obviously... Go out and teach! Share what you learn!

Very interesting discussion weighting the main differences and disagreements between a Philosophy of Software Design, and Clean Code. I read and own both books and those differences were crystal clear, it's nice to see the authors debate them. I'm a bit disappointed at the section about TDD though, I think it could have been a bit more conclusive. It gives me food for thought about my TDD teaching though and confirms some of the messages I'm trying to push to reduce confusion.

Definitely this. It's important for an organization to create knowledge... and this requires both people willing to learn and to teach.

A good reminder that you should always bring several perspectives when teaching something. This a a simple framework which can be used widely in our field.

OK, this is advertisement to their PSL workshops. That being said the quote from Hoverstadt is important, this and the feedback of one of their attendees: "I can honestly say I learned at least as much from other participants". This is exactly what I'm trying to foster when I design learning experiences.

Definitely this. In a world where LLM would actually be accurate and would never spit outright crappy code, programmers would still be needed. It'd mean spending less time writing but more time investigating and debugging the produced code.

Well, maybe our profession will make a leap forward. If instead of drinking the generative AI cool aid, if we really get a whole cohort of programmers better at critical skills (ethical issues, being skeptical of their tools, testing, software design and debugging) it'll clearly be some progress. Let's hope we don't fall in the obvious pitfalls.

Funny experiment. This shows what you can achieve in terms of teaching and learning during pair programming setups. Shadowing someone is a powerful approach.

So, which team are you on when you think about commits in Git?

One of the toughest object-oriented programming principles to apply properly in my opinion. At least it looks like we found a better way to teach it now.