A bit of background
I started with PHP almost two decades ago and picked up Laravel around the 4.2 release in 2014. Since then I've worked across a fair range of the industry: agencies, in-house teams, freelance, and now mostly independent through my own company. The work has changed, the framework has changed, and the parts of it I find interesting have changed. What's stayed constant is that I've kept getting deeper into how it actually works rather than just how it's used.
A lot of what I publish, both articles and open-source tools, comes from the same place. I write about Laravel's internals because most developers never get to see them, and that gap between what the docs cover and what the framework actually does is where a lot of the interesting decisions live. I build packages like Sprout and projects like The Game Panel because the tools that already existed didn't work the way I thought they should, and I'd rather build the thing properly than work around someone else's compromises.
I genuinely think this stuff should be more widely available than it is. If I didn't need to earn a living, I'd happily spend all my time writing and building tools for free. The earning-a-living part is real, so consulting and the occasional paid project sit alongside the open-source work, but the thing underneath all of it is that good tools and clear information should exist, and if I can be one of the people putting them out there, that's a use of my time I'm content with.
Some numbers
What I believe
Explicit over magical
The framework's job is to get out of your way, but that doesn't mean its behaviour should be invisible. I'd rather write three lines of code I can reason about than one line of magic I have to debug at 2 AM. Most of what I write about Laravel's internals comes back to this. The magic is fine, but only once you understand it.
Critique is part of mastery
You can't truly master something without being aware of its flaws and limitations. Pointing out where Laravel falls short isn't being negative; it's the only honest way to engage with a tool you use every day. If I write a commentary piece that pushes back on a common Laravel pattern, it's because I think the pattern deserves the pushback. That's not the opposite of liking the framework. It's part of it.
Tools and knowledge should be available
A lot of what I do comes back to a simple belief: the right tools and the right information should exist, and people should be able to get at them. Most of my open-source work fills a gap I noticed; most of my writing covers things I wish someone had explained to me earlier. I'm not trying to be the only person doing this. I'm just trying to make sure the things I think should exist actually do.
Honest feedback over flattery
If you ask me what I think of your code, your architecture, or your idea, you'll get an honest answer. I'd rather tell someone something they don't want to hear than waste their time agreeing with them. The same applies the other way: I'd rather hear that I'm wrong than be politely told I'm right.
If you've read this far, you probably have a sense of whether my writing is for you. The articles are the best place to start, particularly The Hidden Parts of Laravel if you want to see how I think about the framework. If you've got something you want to talk to me about, get in touch.