Bike Shedding
"Bike shedding" is a term that comes from the idea that while building a nuclear power plant, people may spend more time debating the design of a bike shed (a relatively simple decision) because it’s easier to grasp than the larger technical aspects of the project.
A great example of this is when raising a PR. Often a small PR containing a simple one-line change will result in lots of opinionated discussion but a massive PR with hundreds of lines of changes across many files will get a simple "LGTM 👍".
To prevent bike shedding, reviewers should make sure to take a step back to analyse the bigger picture (rather than getting bogged down on "low impact" features). Equally, developers should aim to publish small PRs with small changes to make it easy for people to grasp.
Dog Fooding
"Dog fooding" represents the idea of using your own product. The idea is that if you’re willing to “eat your own dog food,” you demonstrate confidence in the product’s quality and usability.
It's massively important for developers to use their own product as it boosts quality assurance, helps identify inefficencies, uncovers bugs, creates an incredibly short feedback loop and boosts empathy for users.
Boiling the Ocean
"Boiling the ocean" is the practise of taking on an impossibly large task. As developers we spend a lot of our time breaking big problems down into smaller, more manageable and "trackable" chunks. Failing to do this will result in lots of time wasted and a high likelihood of failing!
Rubber Ducking
Have you ever gone to ask for someone's help and realised the solution as you describe the problem to them? Well, "rubber ducking" is the practice of explaining a problem to an inanimate object (e.g. a rubber duck) to find a solution. Verbalising (and thinking about) the requirements, the context and the quirks of a problem is often enough to help us find a solution. If this fails, you can now go to a colleague having practised your explanation of the problem and can be confident that you'll definitely benefit from a second opinion!
Boy Scout Principle
"Leave everything a little bit better than you found it".
The Boy Scout Principle is meant to apply to campsites. If you leave your campsite a little bit better than you found it (tidy up a bit of someone else's rubbish, water the thirsty plants, clear the path that has become mucky) then the quality of the campsite will just improve over time!
If we translate this to code bases or infrastructure, leaving your application a little bit better than you found it (optimize any obvious inefficencies, improve the quality of a test, make something a little more thorough or robust) then the health of the app will just improve over time. This doesn't have to be done in your PR (make a separate PR that can be reviewed independently and doesn't block the work you are trying to accomplish) and it shouldn't be big (large work should form a dedicated work stream and shouldn't distract you from your work). Instead, just make a really small effort to leave something a little better than you found it.