Engineering with intent: A mental checklist for clear thinking

I’ve learned that the most difficult problems — be they knotted in a codebase or in our daily lives — demand more than technical skills. They want genuine self-reflection, a thorough take a gander at what spurs us, and a cautious method of orchestrating and responding. I have developed a checklist over the years to help me sift through the jumble of personal and professional challenges. Here’s how I got there.

Checking In: The Psychological and Physical Self

Before I take on a new task, I pause and think: How am I actually feeling?

• Psychological Self-Evaluation: Am I feeling overly confident, too hopeful about my abilities, or struggling with doubts?
• Physical Brain: Is my mind clear, or is fatigue, stress, or other influences (like medication or recreational substances) clouding my judgment?
• Aging and External Influences: I take into account things like my age or past experiences that might be coloring my view.
• External Pressures: Am I driven by strong rewards or a fear of failure?
• Social Influence and Authority: Am I just repeating what others say or blindly following authority without thinking for myself?

If I notice anything off — if I’m not seeing things clearly — I allow myself to step back for an hour or even the whole day. This isn’t about putting things off; it’s about making sure my decisions are thoughtful and rooted.

The Checklist That grounds my work

Before I send a diff or tackle a tricky problem, I have a mental — and sometimes written — checklist that helps me think:

1. Planning:

• Why does this problem exist in the first place?
• What does “done” really mean?
• I create a clear plan with simple, one-idea steps. For each step, I ask: What do I need to reach the next point?
• I look into my research options and check if I have enough information before I start.

2. Trying an Idea:

• I often begin with the simplest approach — a quick proof of concept that lets me fail fast and learn quickly.
• If something doesn’t work, I clean up, note what I found, and try again with a clearer mind.

3. While Solving the Problem:

• I keep track of each change I make: what I did, why I did it, and what evidence backs my choices.
• I think about what’s impossible to narrow down the real issue.
• If I’m stuck for more than 30 minutes, I know it’s time to seek a fresh perspective.

4. Asking the Right Questions:

• What’s the problem in one simple sentence?
• Have I gathered all my research and reasons in one place, including sources and opposing views?
• This isn’t just about making a point — it’s about ensuring the solution is solid from all angles.

5. Choosing a Solution:

• I always ask: Why is this solution the best one out of the choices I have?
• I think about the trade-offs, look at what could go wrong, and ask if I can reduce any risks.
• I take my time making decisions. If I can wait without extra costs or risks, I do — keeping my options open is important.

6. Risk Evaluation:

• I walk through the “story” of the change. What’s the impact?
• I find any outliers and unseen risks, making sure that any new state I create is manageable.
• This helps me avoid creating bigger problems down the road.

7. Final Review Before Submission:

• I wait 24 hours before asking for feedback on my code. That cool-off time is important.
• I return to my diff as if I’m seeing it for the first time, checking for clarity and consistency.
• I note any unusual things or inconsistencies that might confuse someone else later.

Beyond the Code: Embracing mental models and life lessons

It’s not just about code reviews and technical tasks. These practices have also influenced my personal life. Recognizing biases — like thinking too highly of my skills or comparing myself to others — has helped me make better decisions away from the screen. I ask myself:

• Reason vs. Emotion: Does the reason behind my belief hold up? What are the counterarguments?
• Learning from Others: Have I looked at how my peers approached similar challenges? Sometimes, an outside view is what I need to balance my internal biases.
• Planning for Change: When I reuse tools or methods, I make sure I’m not complicating a solution for a problem it wasn’t meant to solve.

These questions aren’t just boxes to tick; they’re mental models that guide my actions. Whether I’m planning a new feature or just organizing my day, I lean on these principles to stay focused and effective.

The Outcome: A more thoughtful, resilient approach

I won’t say this checklist has eliminated all mistakes or guaranteed perfect decisions. But it has shown me the importance of taking a step back, reflecting, and planning with care. By checking in on my mental and physical state, I make sure my work isn’t swayed by temporary influences — like stress, overconfidence, or outside pressure.

This way of working is as much about taking care of myself as it is about doing a good job. It’s easy to ignore the human elements behind every line of code, but recognizing them can change how we work. More importantly, it helps us see that clear thinking, in both work and life, is rooted in honest self-reflection.

If you find yourself rushed by deadlines, influenced by others, or confused by your own mind, consider taking a break. Revisit your checklists — both the technical ones and the personal ones — and see if a thoughtful pause might lead you to your next breakthrough.