---
name: intellectual-honesty-in-development
description: Apply intellectual honesty principles when debugging errors, reporting project status, and providing time estimates. Use this skill when encountering compiler warnings, preparing progress reports, or negotiating project timelines with management.
---

# Intellectual Honesty in Development

## When to Use This Skill

- **Debugging and Error Handling**: When you encounter errors, warnings, or uncertain situations
- **Project Status Reporting**: When preparing progress reports or status updates
- **Estimation and Negotiation**: When providing time estimates and management pressures you to adjust them

## Scenario 1: Admitting Errors and Understanding Warnings

### Core Principles

1. **Never pretend to be an expert** - If you don't know something or made a mistake, admit it readily
2. **Understand compiler warnings** - Don't suppress or ignore warnings; investigate what they point to
3. **Understand your program** - Never compile code just to "see what happens" without understanding the logic

### Warning Signs

- Feeling tempted to compile code to determine whether to use `<` or `<=`
- Running programs to verify logic you don't understand
- Ignoring warnings because you think they mean something else

### Actions

- When you encounter a warning, investigate the root cause rather than suppressing it
- If you don't understand why code works, return to the design phase
- Admit mistakes quickly and explicitly - everyone will know anyway

## Scenario 2: Honest Project Status Reporting

### Core Principles

1. **Avoid the "90% complete" fallacy** - Don't claim 90% completion when you're in the last 50% of time
2. **The 90-90 Rule**: The first 90% of code takes the first 90% of development time. The remaining 10% takes the other 90%.
3. **Provide accurate assessments** - Managers appreciate honest observations even when they're not what they want to hear

### Communication Guidelines

- Deliver honest observations calmly and privately when possible
- Recognize that management needs accurate information to coordinate development
- If you struggle with progress judgment, study your own work patterns to improve

## Scenario 3: Estimation and Negotiation

### Core Principle

**Estimates are not negotiable.** You can refine estimates for accuracy, but negotiating with your boss won't change the time required to develop software.

### When Management Pressures You

Use this approach:

> "Look, this is what it costs. I can't judge whether it's worth it to the company—that's your job. But I can tell you how long it takes to develop the software—that's my job. I can't 'negotiate' how long it takes; that's like negotiating how many feet are in a mile. You can't negotiate natural laws."

### What You CAN Negotiate

If management needs different timelines, negotiate project scope:

- Eliminate features
- Lower performance requirements
- Phase the project development
- Adjust team size (fewer people/longer schedule OR more people/shorter schedule)
- Re-estimate based on the new scope

### What NOT to Do

- Never underestimate costs to gain project approval
- Underestimating steals management's authority to make informed decisions

## Key Takeaways

- Intellectual honesty builds trust and credibility
- Pretending to know what you don't know damages your reputation
- Accurate information enables better decision-making at all levels
- Negotiate scope, not reality