Episode 13: Wait, you want to lint commit messages?!?
The importance of architecture.
Panelists
- Andrew Mason
- Nate Hopkins
- Ron Cooke
Guests
None this week.
Sponsor
Show Notes
[00:02:15] Ron talks about the importance of architecture, the way we architect our apps, since he started working at Kin, a home insurance company. He asks the guys what they think about architecture in that sense?
[00:05:25] Andrew brings up single responsibility pattern. Ron says patterns are dangerous, Nate likes them, and Andrew shares a story of patterns and a video that Chris Oliver did on refactoring that helped him.
[00:14:07] Nate brings up things that Sandi Metz’s teaches about extreme object orientation. She has so many great ideas and the way she forces you to think about your code differently.
[00:18:27] Nate brings up videos with DHH talking about Basecamp code. He had some interesting information about where software development gets interesting. Nate explains.
[00:20:32] Find out why Andrew starts thinking about the garden and the way the rows should be placed. Also, we learn code is magic! ☺
[00:21:35] The guys all discuss trade-offs and understanding that there’s a balance between the business needs and the needs of the developer or the engineering department as a whole. Nate says the trick is to find the right balance and Andrew shares a story about bad coding and extending grace to someone.
[00:26:51] Andrew asks Ron, if he was to tell him that he wanted to lint their commit messages before they could be merged to master, assuming that all commits are squashed into a single commit, how would that make you feel, without telling you why?
Ron answers.
Ron answers.
[00:32:30] Andrew mentions a plug-in called “Release Drafter” if you format your commit messages in a certain way. Nate wants to know how does this work with a continuous release environment where you’ve got multiple pushes to prod daily and what are the major parts that they believe need to live in a commit message? Andrew explains.
[00:37:16] Andrew brings up “Conventional Commits” which is a specification for adding human and machine readable meaning to commit messages.
[00:44:07] Nate talks about in his new company, they have a set format that they use for their commit messages. It’s not super structured but everybody does it.
[00:48:24] Ron asks Andrew and Nate if they should be using a Project Management Software and how would they feel about that?
[00:51:48] Ron has a question for Nate and Andrew, circling back around to that application that Nate wrote, that became the linchpin for the company, at some point did the structure form around the project? Did you guys implement a project management system and formal processes an all of that?
[00:54:26] Ron closes out the episode with some advice, “Read POODR and learn your patterns!”
Links
- Practical Object-Oriented Design (POODR) by Sandi Metz
- Sandi Metz
- DevIQ Single Responsibility Principle
- GoRails Refactoring Rubocop GitHub Action by Chris Oliver
- "On Writing Software (well?) #1- with DHH
- RailsConf 2020.2 Couch Edition "Tidy First? by Kent Beck
- Conventional Commits
- Release Drafter
Credits
- Produced by Justin Dorfman at CodeFund
- Edited by Paul M. Bahr at Peachtree Sound
- Show notes by DeAnn Bahr at Peachtree Sound
- Ad Sales by Eric Berry at CodeFund
★ Transistor.fm is now hosting an archive of the podcast for us. Learn how to start your own podcast!