Cat aficionado and author of Understanding the Four Rules of Simple Design, Corey Haines talks about co-creating the Coderetreat Workshop and spreading his coding knowledge and experience in exchange for a couch to crash on.

Chael: I’m like, at some point, you have to handle branching logic.

Corey: There are lots of ways to handle branching logic without if statements. However, should you use those techniques all the time? No. Sometimes the best way is just an if statement. I wrote one on Friday. I literally wrote an if statement. I don’t write a lot of if statements, to be fair.

Chael: [laughs] You’re like having to protect yourself. You’re like, “No, not the if statements. The if statements are coming for me.”

Corey: Yep. And it comes back to that idea that these are called the Four Rules of Simple Design. Why do we have simple design? Why do we care about making simple design? And it’s entirely because we want to make it easier to change. I like to say that you can’t have a good design. There’s no such thing as a good design. There’s only a better design in a given context because if you have two designs and in the context that you’re in, one of them is more easily changeable, that’s a better design.

Corey: Ruby never yelled at me.

Corey: And I would often tell people like, ‘I’ve been doing this a long time. I’ve seen the code that gets written, and there’s no reason to keep this code at all. The world is a better place because it’s deleted, believe me.’

On single vs double quotes: Corey: “And I would say if the performance of the string is your bottleneck, that’s a really great app!”

“Because your code is already good.” -ChaelCodes “Your code is good, it’s doing the job. Don’t make it feel bad.” -Corey Haines

Listen to the Podcast