What I Do
Development
With over 25 years of professional development experience, I've probably seen it all. From writing Solaris kernel drivers to writing software to detect bad cucumbers and everything in between. My passion is about finding out how things work by (re)creating them from scratch. One of the reasons my (uncompleted) projects consist of an RDBMS system, a multitasking operating system, and even a completely new programming language.
Nowadays, I spent most of the time on the web, developing both the infrastructure and designing the architecture of small and large scale applications. Even though I'm more comfortable with development on backend systems like APIs, microservices, high-performance toolsets, and CI/CD systems, I do dabble a bit frontend as well. Libraries like React and languages like JavaScript are no strangers.
System Administration
Not only development but also System Administration is part of my passion. Growing up with Linux, I've seen the transformation from physical hardware in data centers, to containerization on cloud providers.
I've come to realize that most of the significant happenings in system administration are about abstraction. While abstracting away the various layers can be a good thing (removal of the physical network, servers, and even the move from applications to lambda functions), it doesn't remove the need for knowledge. Far too often, I stumble upon incorrect VPC setups and insecure configurations because of the lack of understanding of the tooling used.
Consultancy & Training
Besides all this, I spend time on training and workshops on many different subjects ranging from single-day training on tooling to multi-day courses on programming and frameworks.
I've written a few books on PHP subjects like the "Mastering the SPL," the "Symfony Deep-dive" series, and "Python for PHP developers." Because of other priorities, I'm not in the process of writing new books.
I also spent time speaking at both small and large conferences all over the world, talking about a broad range of subjects. Even though I scaled back the number of conferences I speak at (again, priorities), I regularly speak on local meetups.
Dev/Ops
Ask ten persons what DevOps is, and you will get 20 different answers. For me, DevOps is a result: the fact that you don't separate building and deploying/maintaining software as two separate tasks done by two different teams, but collaboration between these two teams right from the start.
This means DevOps is not about tooling. You can't use Ansible and declare yourself doing "DevOps" (well, you could, but you shouldn't). It's also not about developers doing system administration (again, you could, but shouldn't). It's about communication and collaboration between teams, and quite possibly within the same team to achieve a single goal: generate business value for the client.
When done correctly from the start, it automatically results in using tooling, exchanging knowledge, better and more predictable deployments, and no more fear for the deploy-on-Fridays.