091. ARE Technical: Top 5 Tips for Programming & Analysis (PA)

David and Eric discuss five tips for passing the programming and analysis (PA) division of the Architect Registration Examination (ARE). They emphasize that PA is about evaluation, not design, and highlight the importance of using highlighting tools for long, wordy questions. They stress that programming focuses on constraints before opportunities, using codes and zoning as filters, and that economics matter at a high level. Programming is about relationships and feasibility, not just square footage. They also note that PA questions are longer, providing more clues for candidates to use.

Listen to the Audio

Show Notes

A. Setup & Mindset Shift

• Why PA feels so different from PCM / PJM / CE and PPD / PDD
• PA = gray area, long wordy questions, more about judgment than memorization
• Bonus: practice using the exam highlighter—critical for PA’s long questions

B. What PA Is Really About

• Programming phase = problem seeking, not problem solving
• No design yet: you’re evaluating constraints, feasibility, and relationships
• You’re analyzing inputs: site, climate, soils, codes, zoning, owner’s program

C. Five Core Tips

1. Stop Designing – Evaluate, Don’t Solve
   • You haven’t designed anything yet
   • Compare options, surface risks, and recommend feasibility
   • Bubble diagrams and big‑picture fit, not plans and details
2. Start With Constraints Before Opportunities
   • Environment + context: sun, wind, soils, climate, topography, neighbors
   • Look for what cannot be done first, then what could be done
   • Treat this as due diligence at the very start of a project
3. Codes & Zoning Are Filters, Not Afterthoughts
   • Use setbacks, easements, FAR, occupancy, construction type as early filters
   • Goal: define the buildable area / envelope and check viability
   • You’re not doing deep PPD/PDD code work—just feasibility‑level analysis
4. Programming = Relationships More Than Square Footage
   • Quantitative: room sizes, totals
   • Qualitative: adjacencies, privacy, sound, light, experience
   • Residential example: public vs. private zones, don’t dump a powder room on the kitchen
   • Good programs describe how spaces relate and feel, not just how big they are
5. Economics Matter, But Only at a High Level
   • Rough cost per SF or per unit to test viability, not detailed estimates
   • Don’t blindly pick the cheapest option; PA is not a bid
   • Think: “Is this project basically viable on this site with this program?”

D. How PA Connects to PPD & PDD

• PA, PPD, PDD as three views of the same project at different scales
• Studying PPD can make a PA retake easier (you see the “other side” of programming)

E. Big Takeaway

• You pass PA by thinking like an architect at the very beginning of a project:
  curious, constraint‑driven, feasibility‑focused, and comfortable in the gray area.

 

---