In this episode, Donn and Kaushik talk about one of the age old bike shedding topics – code formatting, and how you can solve it with automation and tools.
Code formatting can turn into an endless debate amongst peers and teams, and what Kaushik and Donn have found is that this can be delegated to a tool and automated. Freeing you and your team of having to worry about proper indentation, bracket placement, etc. By relying on a well defined tool and some automation you can clean your code up, make it much more uniform and easier maintain.
We talk about ktfmt, a Kotlin code formatter that was released by Facebook. We dive into ktlint, detekt and more. We also dive into spotless which can help you by integrating ktfmt into your gradle build pipeline.
In this episode, Donn and Kaushik talk about the fear of shipping, some impostor syndrome and how it contributes to uncertainty and doubt in your capabilities as a software developer.
Recently Donn embarked on a mission to come up with an idea and ship it within 24 hours (which he did do). The end result was a net benefit of confidence, speed and skill acquisition. This helped reduce any doubt, uncertainty and ultimately fear of shipping a product faster.
That’s what this conversation is about … how to doing a project like the 24 hour MVP can remove fear, uncertainty and doubt and help you ship your side project/products faster.
In this short episode, Donn talks about the CODEOWNERS file and how it can help you ensure teams review the code that they are responsible for before merging.
The CODEOWNERS file is a file that you drop into the root of your project (or into the /docs or .github/ directory) that tells GitHub (or whatever git host you’re using) to require a review for any code changes that match the patterns as defined in the CODEOWNERS file. You’ll specify a matching pattern and users, or teams that own that pattern of files and they will be required to review the PR before it can be merged. This helps prevent unwanted changes to files that may or may not be owned by one team or another. This is useful as teams grow larger and need more control over the changes in their application codebase.