Reconsidering Five Common Software Engineering Practices

The CTO of a startup I worked at hated dependencies. We worked with some 3D calculations (software for drones), and he was writing tens of mathematical functions himself. He insisted that even though it's slower, he at least understands every part and can fix it.

TDD is great for some scenarios, but it's not a silver bullet. Sometimes you need to explore the problem space first, and writing tests can actually slow you down.

The 'code must be self-documenting' dogma often leads to code that's neither self-documenting nor properly documented. Good code should be readable, but complex logic still needs explanation.

Agile methodologies work well for many teams, but they're not universally applicable. Sometimes a more structured approach or even waterfall makes sense depending on the project and team.

I've worked with brilliant engineers who never finished college, and mediocre ones with PhDs. What matters is problem-solving ability, not a piece of paper.