What I wish I knew when I became CTO

Getting a team to write tests is change management 101:

People are resistant to change when they don't know how it benefits them directly and immediately.

My suggestions have been:

- By giving developers slight nudges every time they get frustrated with developing when tests aren't present is a good way to help them see the benefit. "Imagine how much easier it would be to write this piece of code if you had tests in places where this function calls other things".

- Enforcing it during commits (as you suggest, using PRs)

- Reminding your whole organization that while you migrate to implementing more testing that velocity of development will be impacted. This is really important, because it means people outside of the dev team also need to see the benefit.

- Eliminating "deadline cultures" first and then implementing unit testing

Characterization tests - Michael Feathers writes about strategies to build tests in "Working Effectively with Legacy Code".

If I wanted to be a consultant or contractor again, it would be walking into these situations and essentially building test systems for legacy code.

(And if anyone wants to pay me 8,000 a week for a few months...)

> I’ve found it a real struggle to get our team to adopt writing tests.

If you're struggling to judge the engineering culture of a company that you're considering joining, consider this indicative of a poor one. It isn't definitive, but it's something you should ask about and probe further. Ask to see their CI dashboard and PR comments over the last few days. When they talk about Agile, ask what _engineering_ techniques (not process!) they leverage. These things will tell you if you're joining a GM or a Toyota; a company that sees quality and efficiency as opposing forces, or one that sees them as inseparable.

When it comes to tests, there are two types of people: those who know how to write tests, and those who think they're inefficient. If I had to guess what happened here, I'd say: the company had a lack of people who knew how to write effective tests combined with a lack of mentoring.

That's why you ask to see recent PR comments and find out if they do pair programming. Because these two things are decisive factors in a good engineering culture.

The method I've found is to ask people I respect a lot, "Who is the best X that you know?" Then call/email them, saying, "I'm the CEO of Y, and I'm trying to find out what a good X looks like. So and so said you're the best she knows. Can I have 30 minutes of your time?"

Do 5 of these, and you'll have a good idea of what someone good looks like. (And those 5 may give you some candidates)

This is very difficult though because things like "organizes the team to hit quota every quarter" can come in many different manners.

Curious to hear if they were running SQL queries using some sort of ORM layer, or if they had people who were knowledgeable with SQL itself writing queries or creating Views to extract the data they needed, as well as tune the database and ensure proper INDEXES were in place.

In my past experience, the two methods above can produce wildly different impacts on database performance.