cheatsheet

Productivity & Engineering Philosophy

A comprehensive guide to “Intellectual Production”, “Engineering Mindset”, and “Professional Conduct”.

“Efficiency is doing things right; effectiveness is doing the right things.” - Peter Drucker

1. Deep Work (Focus Management)

Source: Deep Work (Cal Newport)

The Core Hypothesis

The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy. As a consequence, the few who cultivate this skill, and then make it the core of their working life, will thrive.

Strategies for Focus

• The 4 Disciplines of Execution (4DX):
  1. Focus on the Wildly Important: Don’t try to do everything. Pick 1-2 ambitious goals.
  2. Act on Lead Measures: Track metrics you can control (e.g., “Hours of Deep Work”) rather than lag measures (e.g., “features shipped”).
  3. Keep a Scoreboard: Visualize your deep work hours.
  4. Create a Cadence of Accountability: Weekly reviews of your focus performance.
• Roosevelt Dashes:
  • Brief but extremely intense periods of work. Estimate how long a task should take, then drastically cut that time to force extreme concentration.
• The Shutdown Ritual:
  • End your workday with a strict ritual. Review tasks, plan the next day, and say a “termination phrase” (e.g., “Shutdown Complete”).
  • Why?: Incomplete tasks linger in your mind (Zeigarnik Effect). The ritual frees your brain to rest.

Scheduling Philosophies

• Monastic: No distractions, ever (unrealistic for most).
• Bimodal: Long periods (days/weeks) of isolation, followed by normal life.
• Rhythmic: Habitual blocks (e.g., 6:00 AM - 9:00 AM every day). Best for office workers.
• Journalistic: Seizing 30-minute gaps whenever possible. Requires high mental agility.

2. Managing Complexity (Cognitive Load)

Source: A Philosophy of Software Design (John Ousterhout)

The Root of All Evil

Complexity is the accumulation of dependencies and obscurities. It increases the cognitive load required to make even simple changes.

Tactical vs. Strategic Programming

• Tactical: “Just get it working.” Shortcuts, tech debt, spaghetti code. Fast now, slow forever after.
• Strategic: “Investing in design.” It takes 10-20% longer initially but keeps development velocity high over time.

  Rule: If you have to choose, always choose the strategic approach unless your startup dies tomorrow without the feature.

Design Principles

• Deep Modules:
  • Expose a simple interface for complex functionality.
  • Information Hiding: The implementation details that are most likely to change should be completely hidden.
• Comments as “Why”:
  • Code explains what is happening. Comments explain why it is happening (design decisions, non-obvious constraints).
  • Write comments before code to clarify your design thinking.
• Define Errors Out of Existence:
  • Instead of throwing exceptions, redefine the semantics so the exception is impossible.
  • Example: A file delete method dealing with a non-existent file. Instead of throwing FileNotFound, simple return Success (the desired state “file is gone” is achieved).

3. Teamwork & Culture (HRT Principle)

Source: Team Geek (Brian W. Fitzpatrick)

The HRT Triad

• Humility: You are not the center of the universe. You make mistakes. Be open to self-correction.
• Respect: Treat colleagues as competent professionals. Assume positive intent.
• Trust: Believe that others can do the job. Delegate authority, not just tasks.

The Bus Factor

• The number of key people who, if hit by a bus (or quit), would doom the project.
• Goal: Increase the bus factor. Share knowledge, document everything, avoid “hero programmers”.

Communication Protocols

• Mission Statements: Define a clear direction. “We are building X to solve Y for Z.”
• Consensus vs. Voting: Avoid voting. It creates winners and losers. Strive for consensus, but if deadlocked, the tech lead decides.
• The “No Asshole” Rule: brilliance is not an excuse for toxic behavior. Toxic high-performers destroy team net productivity.

4. Problem Solving (McKinsey Style)

Source: Bulletproof Problem Solving (Conn & McLean)

The Seven Steps Overview

1. Define: Context, criteria for success, constraints, stakeholders.
2. Disaggregate: Break it down.
3. Prioritize: Pareto principle (80/20).
4. Workplan: Who, what, when.
5. Analyze: Heuristics -> Deep Analysis.
6. Synthesize: Findings -> Insights.
7. Communicate: Drive action.

Disaggregation Techniques

• Logic Trees:
  • Component Tree: “What is it?” (Decompose a system).
  • Hypothesis Tree: “Why might this be?” (Testable hypotheses).
• MECE: Mutually Exclusive, Collectively Exhaustive. No overlaps, no gaps.

The “One Day Answer”

• Before spending weeks on research, formulate your “best guess” answer on Day 1.
• This hypothesis drives your analysis. You are trying to prove or disprove it, not just “looking at data”.

5. Technical Writing & Communication

Source: The Pyramid Principle (Barbara Minto) / Technical Writing Guidelines

The SCQA Framework (Storytelling)

To get attention, frame your document/presentation as a story:

1. Situation: The undeniable, non-controversial context. “We use Python 3.8.”
2. Complication: The problem that disrupts the situation. “Security support for 3.8 ends next month.”
3. Question: The natural question arises. “What should we do?”
4. Answer: Your solution (The BLUF). “Migrate to Python 3.12 immediately.”

Micro-Writing Tips

• Active Voice: “The server received the request” (Better) vs “The request was received by the server”.
• Strong Verbs: Avoid “make”, “do”, “get”. Use “generate”, “calculate”, “retrieve”.
• Lists: If you have 3+ items, make a bulleted list.

---

6. Professional Conduct (Communicating like a Pro)

How to behave to be trusted by Seniors, Managers, Juniors, and Clients.

Managing Up (Bosses / Managers)

• No Surprises:
  • Never let your boss be surprised by bad news from someone else.
  • Report bad news immediately, but always pair it with a potential solution or a mitigation plan.
  • Bad: “The DB crashed.”
  • Good: “The DB crashed. We’ve failed over to the replica. I’m investigating the root cause and will update in 30 mins.”
• Solution-Oriented:
  • Don’t just bring problems. Bring proposals.
  • “We have a problem X. I recommend we do Y. Option Z is also possible but riskier.”
• Manage Expectations:
  • Under-promise, over-deliver. If a task takes 3 days, say 4-5.
  • If a deadline is at risk, communicate it days in advance, not hour of.

Interacting with Seniors / Mentors

• Respect Their Time (The “15 Minute Rule”):
  • Before asking, spend 15 minutes trying to solve it yourself (Google, Docs, Debug).
  • Don’t spend hours spinning your wheels.
• Ask High-Quality Questions:
  • State: 1. What you want to do. 2. What you tried. 3. What exact error you got. 4. What you think might be the cause.
• Close the Loop:
  • If they give you advice, come back later and say “That worked, thanks!” or “It didn’t work because…”

Leading Juniors

• Psychological Safety:
  • Explicitly tell them: “It’s okay to make mistakes. It’s okay to ask ‘stupid’ questions.”
• Delegate Context, Not Just Tasks:
  • Don’t say “Write this function.”
  • Say “We need to fix this user bug. I think this function is the place. Can you look into it?”
• Code Review as Mentorship:
  • Explain why you are requesting a change. Link to documentation.

Client / Stakeholder Management

• Speak Their Language:
  • They don’t care about “Refactoring the React hook”.
  • They care about “Making the checkout page load 50% faster to increase conversion.”
• Reliability is King:
  • It is better to be consistently average speed than wildly unpredictable.
  • If you say “Tuesday”, it must be Tuesday.
• The “Yes, and…” or “No, but…“:
  • Avoid hard “No”.
  • “We can’t do that feature by Friday (No), but we can ship the core version and follow up next week (Alternative).”

This site is open source. Improve this page.