Reflection Is an Underrated Engineering Skill

For a long time, I measured my weeks by commits and tickets closed. I was shipping, but when things went wrong, I couldn’t clearly explain why. Progress felt real, learning didn’t.

As engineers, we’re good at reflecting on systems: post-mortems, incidents, retros. But those are reactive. We rarely apply the same rigor to ourselves, our decisions, assumptions, and thinking patterns.

I started doing exactly that.

I kept a simple dev journal (initially just a Google Doc) where I wrote short reflections about decisions, frictions, and emotions tied to my work. Not what I shipped but how I thought. Over time, this changed how I worked. I caught patterns earlier, aligned my work more clearly with my goals, and communicated my impact better. This practice played a real role in my last promotion.

I now think of reflection as clearing mental debt, similar to refactoring technical debt. Small, regular passes compound.

This matters even more now with AI in our workflows. We increasingly let models summarize, suggest, and decide for us. That speed is powerful but it also weakens our feedback loop. We risk outsourcing judgment without reconstructing why a decision was made.

Reflection is a counter-balance. It forces questions like:

• Why did I accept this suggestion?
• What assumptions did I outsource?
• Where did I choose speed over judgment?

In an AI-heavy world, critical thinking isn’t optional it’s a competitive advantage.

How to start
Keep it simple. Once a week, write a short reflection about one decision, trade-off, or moment of friction. Consistency matters more than depth. If it sticks, make it daily.

Research backs this up too: a Harvard study showed that even ~15 minutes of structured reflection per day significantly improved performance in under two weeks.

Question for you
If you had to reflect on one question this week as a builder or engineer—what would it be?