Great talk, appreciate the focus on code. I think this was a little more of a Laravel-focused talk than a TDD-focused talk. But that's OK, you have to have a base to build on. One thing I like to mention whenever I talk about TDD is that it's just another tool in the toolbox, it's not the be-all-end-all strategy.
Extremely entertaining talk from a dynamic speaker — can definitely use some more detailed examples of good DX vs bad DX so we can start going down the correct paths.
Did a good job of showing us what options Laravel offers to help us get from no code to some skeletons but it really didn’t show us TDD — just how to write a test for code that already exists.
Way too short — the talk showed us just a glimpse of HTMX and then very few examples of how to integrate it into our applications.
Great real-world examples of how to organize your data better
I thought this talk would be entirely theoretical to me. I don't work in a company with an external-facing dev interface, so it doesn't apply to me, right? Right??
NOPE. As Rain so eloquently pointed out, the proper perspective for developer experience is like ... the experience of your developers? Whether they're internal or external. WHETHER THEY'RE EVEN DEVELOPERS (or just users) 🤯. And there's so much value to be cultivated and banked when you take care of your users – all of them, be they seated in front of PHPStorm or your SaaS screen or whatever "Python" is.
Bringing the full weight of their experience and expertise to bear, I got both philosophical and real-world takeaways. Just some fascinating content coupled with a compelling delivery. I wish there were more thumbs with which to up.
I owe my entire career as a PHP dev to getting involved in the community in 2003 and the random decision to focus on unit testing.
Real-world explanations of how to use event sourcing are great to help people decide if they should start using it.
The level of passion Rain brings to this subject was palpable in the room. Qualcomm is lucky to have them advocating for their software engineers. I don’t know if they implement PSR-8, but my paternal instincts were certainly to offer one at a few points early in the presentation before they got settled into a bit more of a groove.
I think the concepts they were espousing in the talk are spot on. This is the sort of environmental awareness around the development experience we need managers and leaders to be exposed to and thinking of as they develop processes and structure organizations.
A concrete addition to a point of discussion that came up at the end occurred to me as I was driving home: the fifth pillar also has some feedback loop aspects of it, the automated metrics coming out performance and reliability. Whether it’s load times, or crash counts, or sales metrics, or even the horrid daily active users, there are lots of things that can be used to prime a feedback loop and gets devs a dopamine hit… or conversely if not handled well by leadership can produce a solid dose or norepinephrine (or maybe cortisol is the better analogy here?).
I finally made it to one of Jeremy's talks, and I was not left wanting. Informative, entertaining, and oh so useful.
This is also one of the few talks I've ever seen that actually explains Staff + Principal engineers, a role I didn't know about until a year or so before moving into a staff-level role.