
# How to Proceed When Stuck on an Engineering Problem

Every engineer gets stuck sometimes—whether it's a tricky bug, an unclear requirement, or a system failure with no obvious cause. The difference between struggling endlessly and solving problems efficiently often comes down to process.

This guide provides a structured approach to breaking down problems, gathering useful data, and working toward solutions systematically. Whether you’re debugging a stubborn issue, optimizing performance, or solving an unexpected failure, these strategies will help you stay productive and avoid frustration.

## 1. Clearly Define the Problem

Before diving into a solution, ensure you fully understand the problem. To gain clarity, ask yourself: Many issues arise from incorrect assumptions or a lack of clarity on what’s actually wrong. Ask yourself:

- What am I trying to achieve?
- What are the expected vs. actual outcomes?
- What assumptions am I making?

### Example: Avoiding Wild Goose Chases

Engineers often spend hours debugging an API call, convinced the problem was in their code. After clearly defining the issue, they realized the API itself had changed its response format. Simply clarifying the problem upfront saved hours of frustration.

## 2. Break It Down Into Smaller Pieces

Big problems feel overwhelming because they seem too large to tackle at once. Breaking them down makes them easier to understand and debug. By focusing on smaller, manageable parts, you can isolate the issue more effectively and avoid getting stuck.

Instead of trying to solve everything at once:

- Isolate the failing part of the system.
- Test each component individually.
- Find the simplest version of the problem to solve first.

### Example: Debugging a Mobile App Crash

A mobile app crashed on form submission. Instead of tweaking everything, engineers broke it down: Was it a UI validation issue? An API request failure? A database write error?

By isolating each step, they discovered the crash was caused by an unhandled null reference in form validation—an edge case where required input wasn’t properly checked. Adding a safeguard fixed the issue.

## 3. Gather More Data

Many issues aren’t what they seem at first glance, and guessing leads to wasted time.

If you’re making assumptions instead of verifying facts, you may be debugging the wrong thing. Gather concrete data:

- Add logs to verify assumptions.
- Step through the code with a debugger.
- Compare working vs. broken cases.

### **Example: Fixing a Memory Leak in C++**

An application’s memory footprint kept growing unexpectedly, leading to slowdowns. Engineers suspected a memory leak but needed data to confirm it.

Using a memory analysis tool, they found an object that wasn’t being deallocated due to a missing `delete` call. Once they added proper cleanup, the memory issue disappeared, improving stability.

## 4. Take a Break and Let Your Brain Work

Sometimes, you’re too close to the problem, making it harder to see the solution. Taking a break helps because it allows your brain to process the problem subconsciously, often leading to fresh insights. Instead of forcing a solution, try stepping away:

- Take a short walk or work on something else.
- Explain the problem to someone—even if they don’t understand it.
- Sleep on it—many breakthroughs come after resting your mind.

### Example: Solving a UI Bug After a Break

A team was investigating an issue where a UI component occasionally displayed incorrect data. After hours of checking API responses and frontend logic, nothing seemed wrong.

Frustrated, they took a short break. When they returned, they noticed a race condition—the component was rendering before the data finished loading. Adding a simple loading state resolved the issue.

## 5. Look for Similar Patterns

Most engineering problems aren’t new—they often follow familiar patterns. Recognizing these patterns helps you solve issues faster by applying known solutions instead of reinventing the wheel.

Look for existing solutions:

- Have you solved something similar before?
- Has someone else documented this problem?
- Are there known patterns or best practices that apply?

### Example: Borrowing a Pattern for Queues

A team needed a queuing system for processing background tasks. Instead of designing from scratch, they reused a rate-limiting pattern they had previously built for API requests. The same logic applied with minor adjustments, saving them days of work.

## 6. Ask for Help the Right Way

Asking for help isn’t just about getting an answer—it’s about getting the right answer efficiently. A well-structured question increases the chances of useful responses and prevents wasted back-and-forth.

If you’re stuck, asking for help is the next step—but do it effectively:

- Show what you’ve already tried.
- Provide relevant context (error messages, logs, snippets).
- Be specific about where you need help.

### Example: The Rubber Duck Debugging Effect

A developer struggling with a tricky bug explained the problem to a colleague. Midway through, they realized their own mistake before the colleague even responded. **Verbalizing the issue forced them to organize their thoughts and spot the problem.**

## 7. Experiment and Iterate

Great engineering solutions rarely come from a single attempt—most problems are solved through trial, refinement, and learning. Iterating allows you to improve step by step without making risky, large-scale changes.

Instead of searching for a perfect answer upfront, break the problem down, test ideas quickly, and adjust as needed. If one approach isn’t working:

- Try a different angle.
- Simplify the problem and solve a smaller version first.
- Prototype quick solutions to validate ideas.

### Example: Refining a Slow Query Through Iteration

A team faced a database query that performed well with small datasets but slowed down as data grew.

Instead of a full rewrite, they tested quick optimizations:

- First, they added an index, but it provided only minor gains.
- Then, they rewrote the query with a better JOIN strategy, improving performance.
- Finally, they denormalized part of the data, which significantly reduced query complexity.

Through small, focused iterations, they improved performance 10x without a risky overhaul.

## 8. Reflect on the Solution

Fixing a bug is good, but learning from it ensures you won’t run into the same issue again. Reflection helps you refine your problem-solving skills, making you a better engineer over time.

Once you get things working, take a minute to step back and ask yourself:

- **What actually caused this?** Was it a bad assumption, missing data, or a deeper issue?
- **What helped fix it?** Did a specific debugging trick, tool, or approach work well?
- **How can I avoid this next time?** Would better logs or alerts have caught this earlier?

### Example: Scaling Lessons in Microservices

A team kept facing random outages in their microservices. Each time, they applied quick fixes, but failures kept returning.

After stepping back, they found the system struggled during peak traffic. They first implemented circuit breakers to prevent cascading failures. Then, they set up monitoring and automated scaling, allowing the system to adjust before overloads.

## Summary: A Quick Checklist to Get Unstuck

1. **Clearly define the problem** – Make sure you understand what’s wrong before diving in.
2. **Break it down** – Solve one piece at a time to isolate the issue.
3. **Gather more data** – Use logs, debugging tools, and comparisons.
4. **Step away** – Take breaks, explain the problem, and get fresh perspective.
5. **Look for patterns** – Leverage prior experience and existing solutions.
6. **Ask for help effectively** – Provide context and structure your questions well.
7. **Experiment and iterate** – Try different approaches and prototype solutions.
8. **Reflect on the solution** – Learn from the experience to improve next time.

## Final Thoughts

Getting stuck is normal—but staying stuck isn’t. The best engineers aren’t the ones who never struggle; they’re the ones who figure out how to work through problems efficiently. Every tough bug or tricky design problem teaches you something.

Next time you hit a wall, don’t just push harder—step back, rethink, and work smarter.

How to Proceed When Stuck on an Engineering Problem


## *Understanding Technical Debt as a Junior Developer*

### *The Job-Hunting Dilemma: Experience vs. Real-World Code*
You've landed your first job as a junior developer. Exciting, right? But soon, you're working on what seems like a simple feature—until you realize the code is anything but simple. Functions stretch thousands of lines, variable names make no sense, and a minor change unexpectedly breaks unrelated parts of the app. You ask a teammate why things are this way, and they just shrug: 'Deadlines, quick fixes, and old workarounds.' What once helped ship features faster is now slowing everyone down. 

This isn’t just messy code—it’s technical debt in action. And while you might not have created it, you’ll definitely have to deal with it. Technical debt is something every developer encounters sooner or later. It’s frustrating, but manageable once you know how to approach it. But what exactly is it, and how do you handle it without getting overwhelmed?

### *What is Technical Debt?*
Technical debt refers to the trade-offs made in software development—often for speed over quality—that lead to future maintenance costs. It can be caused by tight deadlines, rushed features, or lack of expertise. Like financial debt, it accrues "interest" in the form of bug fixes, performance issues, and refactoring time.

#### *Is Technical Debt Always Bad?*
Not necessarily. Sometimes, teams take on technical debt strategically, knowing they'll address it later. Startups, for example, may prioritize rapid feature development to test the market. However, ignoring it for too long leads to expensive maintenance and scalability issues.

### *Common Causes of Technical Debt*
#### *1. Quick Fixes Over Long-Term Solutions*
- Tight deadlines often lead to shortcuts in code.
- Lack of testing or documentation creates future headaches.

#### *2. Legacy Code and Outdated Technology*
- Working in older systems means dealing with outdated patterns.
- Poorly maintained codebases often lack consistency.

#### *3. Poor Communication and Lack of Documentation*
- Without proper documentation, developers struggle to understand past decisions.
- Knowledge silos lead to repeated mistakes.

#### *4. Business Pressures and Rapid Growth*
- Fast-growing teams often prioritize speed over maintainability.
- Pressure from stakeholders can lead to rushed development cycles.

### *Real-World Example: The Hidden Costs of Technical Debt*
Imagine you're working on a project where a key feature was built in a rush. At first, everything seems fine, but as the product scales, performance drops, and debugging becomes a nightmare. The team now spends *twice the expected time* fixing issues instead of innovating. 

Now, imagine an alternative scenario: the team invests an extra week upfront to structure the code properly, write tests, and document key decisions. The feature still ships relatively fast, but now it’s easier to maintain and expand. This proactive approach reduces the long-term impact of technical debt.

### *How Junior Developers Can Navigate Technical Debt*
#### *1. Learn to Recognize It*
- Ask: *Does this code feel unnecessarily complex?*
- Look for TODO comments, inconsistencies, or lack of test coverage.
- Pay attention to bug frequency—recurring issues often indicate deeper debt.

#### *2. Prioritize Fixing Over Patching*
- Understand when to *refactor vs. rewrite*—not all old code needs replacement.
- Suggest small, incremental improvements instead of large rewrites.
- Collaborate with senior engineers to learn best practices.

#### *3. Improve Documentation and Testing*
- Add comments and explanations to tricky sections.
- Write or update test cases to catch hidden issues.
- Advocate for better team processes, such as code reviews.

### *How Technical Debt Affects Your Career Growth*
Ignoring technical debt leads to frustration, slow development, and project failures. However, handling it well builds your reputation as a thoughtful engineer. Demonstrating your ability to manage debt:
- Makes you a strong candidate for promotions by showing that you care about long-term code quality.
- Strengthens your debugging and problem-solving skills, which are essential for technical interviews and leadership roles.
- Helps you contribute more effectively in code reviews, mentorship, and collaborative projects.

### *Australian Job Market Insights: Employers Value Maintainable Code*
Whether you're looking at a fast-paced Sydney startup or a structured Melbourne finance firm, one thing remains the same—employers want developers who can write clean, maintainable code without sacrificing speed. Job postings on [Seek](https://www.seek.com.au) and [Indeed Australia](https://au.indeed.com) frequently highlight the importance of clean code, showing that companies actively seek developers who prioritise maintainable coding practices. Scanning job listings on [Seek](https://www.seek.com.au) reveals that clean code is a recurring requirement, particularly in roles focused on scalable applications and high-performing engineering teams.

### *Final Thoughts: Your Challenge*
Technical debt isn’t just a senior developer’s problem. As a junior, your ability to recognize, communicate, and gradually improve technical debt will make you stand out. 

*Your challenge:* Find an area in your current codebase where technical debt exists. Document why it happened and propose a small, manageable fix. Take note of how it improves the code quality and how future developers might benefit from the change.

Start building good habits now, and you’ll find yourself writing cleaner, more maintainable code in no time.



Understanding Technical Debt as a Junior Developer


# The Best Mental Models for Engineers to Improve Decision-Making

## Engineers and the Challenge of Decision-Making

Engineers make decisions every day—debugging issues, optimising code, designing scalable systems—but the best ones don’t rely on intuition alone. They use mental models—structured ways of thinking that help break down problems, anticipate consequences, and make smarter choices.

Whether it’s rethinking system architecture, prioritising tasks, or avoiding common pitfalls, the right mental model helps engineers find better solutions faster. Let’s explore some of the best mental models that engineers can use to improve decision-making and problem-solving in their work.

## 1. First Principles Thinking: Deconstructing Problems Like an Engineer

### What It Is

First Principles Thinking is a problem-solving approach that breaks complex problems into their most fundamental elements. It is based on reasoning from first principles rather than relying on assumptions, analogies, or conventional wisdom. Instead of taking existing solutions at face value, engineers break down a problem to its core truths and reconstruct a solution from the ground up. 

### Why It Matters

Just because something worked before doesn’t mean it’s the best solution now. Engineering problems evolve, and so should the way we solve them. Don’t just accept how things have always been done. First Principles Thinking helps you strip a problem down to its core truths, cut through complexity, and build solutions that actually make sense—rather than just improving what already exists.

### A Scenario: Applying First Principles to Engineering

Imagine you're optimising a database query that runs too slowly. Instead of assuming indexing is the issue, you break the problem down:

- What is the query doing at a low level? Execution plans reveal a full table scan.
- What is causing the slowdown? The query retrieves unnecessary columns and applies multiple inefficient filters.
- How do you fix it? Instead of just adding an index, you restructure the query to fetch only needed data and apply more effective filtering logic.

By questioning assumptions and rebuilding from the ground up, engineers can find optimal solutions rather than relying on surface-level fixes.

### Applying It to Engineering

- Instead of assuming common fixes, analyse the root cause of technical problems.
- When debugging, question assumptions and verify data before applying solutions.
- In system design, break problems down and build solutions suited to the actual requirements.

## 2. The 80/20 Rule: Focus on High-Impact Actions

### What It Is

The 80/20 Rule, also known as the Pareto Principle, states that 80% of outcomes come from just 20% of efforts. This mental model highlights the unequal distribution of impact—meaning that a small portion of work, decisions, or optimisations drive most of the results. Engineers can use this principle to identify the most valuable actions instead of wasting effort on low-impact tasks. 

### Why It Matters

Trying to fix everything at once is a recipe for burnout. The 80/20 Rule shifts your focus to what truly moves the needle—helping you work smarter, not just harder.

### A Scenario: Optimising Code Performance with the 80/20 Rule

A tech startup faced slow API response times. Instead of optimising everything, they applied the 80/20 Rule and found that 80% of the latency came from just 20% of their database queries. By focusing on those queries—rewriting inefficient joins, adding indexes, and caching frequent requests—they reduced response times by 70% with minimal effort.

### Applying It to Engineering

- Identify the 20% of code causing 80% of performance issues and optimise that first.
- Instead of learning every new technology, focus on skills that provide the most career leverage.
- In debugging, prioritise high-frequency errors instead of fixing every minor issue.

## 3. Inversion: Thinking Backwards to Avoid Mistakes

### What It Is

Inversion is a counterintuitive problem-solving technique where instead of asking, *How do I succeed?*, you ask, *How could I fail?* It is based on the idea that avoiding failure is often easier than achieving success. By identifying the worst-case scenarios before they happen, engineers can build more resilient systems and make smarter decisions.

### Why It Matters

Engineers often focus on what should work, but failures happen because people overlook what could go wrong. By thinking in reverse, engineers can proactively identify weaknesses before they become real problems, leading to more robust systems, fewer bugs, and better decision-making.

### A Scenario: Preventing System Failures with Inversion

A cloud team was preparing for a major product launch. Instead of asking, *How do we ensure the system runs smoothly?*, they asked, *What could cause a catastrophic failure?* By listing failure points—like overloaded servers and security vulnerabilities—they implemented preventive measures such as auto-scaling and penetration testing, reducing the risk of outages.

### Applying It to Engineering

- Before launching a system, ask: *What are the worst-case failure scenarios?*
- Identify architectural weak points (scalability, security, reliability) and reinforce them.
- When debugging, think backward from failure—ask *What went wrong?* instead of *What should work?*.

## 4. Second-Order Thinking: Anticipating Long-Term Consequences

### What It Is

Second-Order Thinking is a decision-making framework that goes beyond immediate results and considers long-term consequences. Many decisions that seem beneficial in the short term have unintended negative effects over time. Engineers use Second-Order Thinking to anticipate these effects and make choices that are sustainable in the long run.

### A Scenario: Choosing the Right Tech Stack

A development team needed to select a front-end framework. While one allowed them to move quickly, Second-Order Thinking revealed that it had a small community, few libraries, and would be difficult to maintain. Instead, they chose a more established framework that ensured long-term support and easier hiring.

### Applying It to Engineering

- Before choosing a tool, ask: *How will this decision affect scalability, maintainability, and hiring in 3-5 years?*
- When making architectural decisions, think beyond short-term benefits to avoid technical debt.
- Apply Second-Order Thinking to security—quick fixes may introduce risks down the line.

## Final Success Story: Putting It All Together

A software engineering team at a fast-growing startup needed to scale their infrastructure for increasing traffic. Instead of following conventional scaling methods, they applied mental models to find the best solution:

- First Principles Thinking – They broke down system bottlenecks and found that database slowdowns—not server limits—were the main issue. By optimising queries and implementing read replicas, they improved performance by 60%.
- The 80/20 Rule – Instead of optimising everything, they focused on the 20% of processes causing 80% of slowdowns, dramatically improving system efficiency.
- Inversion – They didn’t just assume everything would scale—they asked, *Where could failure happen first?* By running load tests, simulating failures, and strengthening security measures, they prevented outages and potential breaches before deployment.
- Second-Order Thinking – Instead of choosing a trendy but unproven tool, they considered long-term consequences—how easy it would be to maintain, whether it would cause technical debt, and how well it would integrate with future needs. This helped them avoid costly rewrites and hiring struggles down the road.

By applying these mental models, the team didn’t just scale their infrastructure—they improved system reliability, reduced downtime, and set the foundation for future growth.

## Conclusion

Engineering is more than just writing code—it’s about thinking critically and making smarter decisions. The best engineers don’t rely on intuition alone; they apply mental models to navigate challenges and design better solutions.

Which of these mental models do you already use—and which one will you test out this week? Pick just one to apply. Maybe it’s questioning assumptions in your next design review or thinking ahead about long-term consequences before committing to a tech stack. Great engineers don’t just write great code—they think strategically. Start using these mental models today, and you’ll set yourself apart in every decision you make.



career growth

How to Proceed When Stuck on an Engineering Problem

Understanding Technical Debt as a Junior Developer

The Best Mental Models for Engineers to Improve Decision-Making