Chris Hartjes

Where do you work, what is your current role?

I have two jobs. Monday to Thursday I work for Mozilla as part of the Ecosystem QA group, helping to test tools and services used internally by Mozilla. On Fridays I work for Grumpy Learning doing OSS work, preparing conference talks, and doing product research for potential topics.

How do you use PHP professionally?

There is very little PHP in use at Mozilla (only Phabricator for doing code reviews of submissions to Firefox itself), but Grumpy Learning is PHP-centric at the moment.

How and when did you get involved speaking or writing in the community?

I don’t even remember when I gave my first conference talk! The earliest reference I find is CakeFest in 2008 but I am sure I spoke somewhere before that. I got into it because I found out I could get expenses paid to go and talk about things I wanted to talk about anyway so I figured I would give it a try.

What’s your best conference memory?

The last TrueNorthPHP in 2016.

What advice do you have for someone going to their first conference?

Go with the mindset of being there to take advantage of a rare opportunity to learn things. Close that laptop unless it’s to make notes, put your phone away, and pay attention. You never know what you might miss.

What’s your primary OS: Windows, Mac, or Linux?

Mac but moving to Windows.

Using tests effectively requires a different mindset than just typing out code. What helped testing “Click” for you?

A failed launch of an application full of bugs in an environment where nobody involved knew how to launch an application with minimal bugs that behaved as expected.

How do you make the case for testing?

Fixing bugs that make it all the way into production costs more in terms of time and money than if they were caught by a systematic approach to testing the code you write.

Adding tests to legacy code can be overwhelming. What advice would you give a team of developers looking to get started?

If the team already understands how to write tests, I suggest starting with tests that prove bug fixes are fixed and stay fixed. Then move onto tests that verify that new features behave as expected. This will hurt and will suck but so does staying late every night fixing things.