1. Rationalizing Poor Code with YAGNI.

You've been contracted to write a UI library for a client. Your coworker is writing a basic button, and you take a look at the code.

CreateButton(bool isBuyNowButton, bool isFrontPageButton, bool isRedButton);

"Why are all these bools here? What's going on?"
"Good question, all these flags implement the customers spec perfectly. If you pass isBuyNowButton you get an orange button with the text 'Buy Now!'. If you pass isRedButton, the button color will be red."

You scratch your head, confused.

"Why not have a text parameter for the button text, a size parameter for the button size, and perhaps a hex string for the color?"

Your coworker looks at you taken aback.

"Because that's not YAGNI! The spec only calls for these things, anything else is a premature generalization and abstract gobbledygook."

"So when would you add a text parameter, a size parameter, or a color parameter?"

"There has to be at least 3 buttons! Don't you know the rule of 3? And even then, I think I'll just add more Boolean flags for all new use-cases."

You shrug and go get coffee.

You comeback and checkout your other coworkers code, they're writing a basic toggle.

AbstractToggleFactoryBaseClassDelegate.BuildBasicToggleWithParameters(...);

You shrug and go get even more coffee.

2. Misunderstanding DRY.

Your coworker has finished reading The Pragmatic Programmer, or maybe a blog about it, and is ready to unleash their knowledge on the codebase.

You take a look at some of their code.

function TryDoThing(function theFunction) {
  try {
     theFunction();
  } catch {
    // Do nothing.
  }
}

function IfTrueDoThis(function booleanCheck, function theFunction) {
  if (booleanCheck()) {
     theFunction();
  }
}

function StartServer(boolean isTestMode) {
  if (isTestMode) {
    // Do some stuff specifically for the test environment.
  }
  // ... init code here ...
}

"Why not inline these things?"

"Because I'm being DRY, by moving these into functions the codebase is 20 LOC shorter. Don't you know less LOC (lines of code) is a good thing? There's less surface area for things to go wrong. Don't you know about DRY?"

"Also I noticed our test code reuses a lot of the following steps as StartServer, so I put it into that method to be more DRY."

"Instead of merging the test code into StartServer did you consider moving it into its own function, and calling StartServer right after?"

"That's not as DRY. You'd have to call InitTestMode() and then StartServer() right after it. By putting it in StartServer you only need to call StartServer(true);. That's way less LOC."

You shrug and go get coffee.

3. Thinking Comments are Bad

Your coworker has finished the classic, Clean Code by Uncle Bob. As it is one of the most popular books on Stack Overflow, this has a high probability of happening at some point in time. If they prefer reading even older books, you can replace Clean Code with Chapter 15 of The Mythical Man Month.

If they're new to programming, they may swear off comments for years. This is unfortunate as many of the complaints about comments can be caught by code review. Namely, forgetting to update comments, or bad comments.

Good code is self documenting, but good comments are icing on the cake. Studies by IBM have empirically found that roughly one comment per 10 LOC increases peak understanding (Code Complete 2nd Edition). This does not mean you should have one comment per 10 LOC, merely that some comments are probably better than zero comments. And summary comments for a chunk of code are different than simply repeating what the next LOC does.

Conclusion

You may notice many of these examples share an underlying problem: using Booleans for code reuse. This is known as logical cohesion, and one of the biggest issues new devs (and even experienced devs) run into. Misunderstanding core principles is also another one, and is only rectified by time, experience, and critical thinking. It's easy to say "Write simple code", but truly understanding what that means takes years of time and effort. Unfortunately, there are no shortcuts.