How Elite Developers Think Differently (And How You Can Too)

Main ideas & lessons

1) Learn by building, experimenting, and failing

• The best way to learn technical skills is to build things (especially real/technical projects).
• Learning accelerates when you:
  • set clear learning goals,
  • put yourself in situations where you must use the skills,
  • try different approaches, then fail, and observe what works vs. doesn’t.
• Curiosity is a recurring driver: sometimes “dumb ideas” or approaches that seem wrong are valuable because they teach boundaries and failure modes.

2) Elite engineers avoid “solving the wrong problem”

• A key concept is avoiding the “Z problem”:
  • An expert (or would-be problem-solver) fixates on a “special” or narrow solution that they’re stuck on.
  • This wastes time for both the solver and helpers because it may not address the true underlying requirement.
• Better approach:
  • focus on the real intention / requirement behind the problem,
  • confirm what the requester actually needs,
  • allow for alternative, better solution directions.

3) Non-technical skills matter more than many people think—especially at scale

• A major claim: “software building” is not mostly technology assembly; non-technical skills can be more important, particularly when systems/teams scale.
• Non-technical competencies include:
  • alignment on value and priorities,
  • stakeholder communication,
  • collaboration and psychological safety,
  • clarity of direction and roles,
  • creating an environment where people can contribute ideas without fear.

4) Communication bottlenecks and responsibility alignment

• A common pitfall in teams is centralizing coordination through one person (e.g., funneling too much through a single product person or engineer), which creates bottlenecks.
• Instead, improve outcomes by:
  • opening communication lines,
  • reducing stress caused by stakeholders bypassing the normal priority/accountability path,
  • using structured stakeholder-team interactions.

5) Prefer co-creation over proxy handling of stakeholders

• Two models:
  • Proxy model: stakeholders communicate priorities/urgency via a single intermediary (e.g., product person), who then produces specs for engineers.
  • Co-creation model: recurring collaborative sessions where stakeholders and the team build shared understanding.
• Co-creation benefits:
  • shared context,
  • fewer surprises,
  • stakeholders leave sessions “happy” because they co-create,
  • the team better understands stakeholder perspective.
• Transparency and shared artifacts (e.g., demos, roadmaps/what’s changing, retros learnings) help stakeholders grow with the team.

6) Career-stage “sphere of influence” and evolving skill balance

A structured career progression is described, where influence expands and technical coding time typically decreases:

• Entry level
  • influence: self and immediate contribution
  • focus: learn the codebase and execute technical work
• Mid-level
  • influence: balance between technical execution and collaborating with more people
• Staff / senior engineer
  • influence: mostly within team/peers; requires strong communication with people you work with regularly
• More senior
  • influence: broader audience (multiple teams)
  • coding time may be insufficient to rely on technical work alone; communication becomes central

Related idea: engineers become less like “code-only executors” and more like communicators and decision-shapers as they grow.

7) Overlap of responsibilities is better than strict silos

• The conversation argues against strict separation like “someone only does databases” and “someone else only does infrastructure,” because it can create:
  • silos,
  • communication overhead,
  • misalignment between components.
• Better: at least some cross-involvement/overlap where it matters for delivering meaningful outcomes.

8) Experimentation culture: let people fail fast, within limits

• Good leadership enables experiments and learning.
• Distinction:
  • allow mistakes and learning,
  • but be stricter when mistakes impact security or critical paths.
• Credibility grows when leaders understand failures first-hand and let teams learn rather than insisting “do it because I said so.”

9) Innovation vs business needs: “technical excitement” can mislead

• Not all businesses need highly exotic technical innovation.
• A risk pattern:
  • engineers who strongly chase technical novelty push for complex/rare tech as a backbone,
  • creating hiring difficulties and long-term maintainability issues,
  • even when the business problem could be solved more simply.
• Nuanced critique:
  • sometimes the engineer isn’t the only cause—the environment can pressure people into “playing with technology” when experimentation or proper problem framing is restricted.
  • organizational constraints can make people revert to the only available form of agency.

10) Organization design: speed and reachability beat excessive hierarchy (often)

• Startups/smaller teams can move faster because:
  • problems are visible,
  • people can act immediately (fewer layers),
  • communication is more direct.
• Large organizations often slow down due to:
  • hierarchies,
  • waiting for review cycles/metrics to realize team pain,
  • complex pathways to escalate issues.
• Suggested best practice: leadership/management roles should retain hands-on understanding (e.g., managers with technical involvement rather than fully non-technical leadership).

11) Company as product + feedback mechanisms (management philosophy)

• Referenced book: “It doesn’t have to be crazy at work.”
• Core idea:
  • Treat the company like a product,
  • build user experience for internal “users” (employees/customers),
  • create mechanisms for detecting problems early and addressing them quickly,
  • organization size doesn’t eliminate the need for efficient feedback loops and processes.

12) Future engineering: more hats, cross-functional skills, but experience still matters

• Expectations may broaden:
  • engineers become more cross-functional (backend/frontend/product-adjacent),
  • tooling/AI may accelerate learning.
• Caution:
  • foundational knowledge can be learned faster, but experience still takes time.
  • new engineers who swing too quickly may miss deep experience in specific areas.
• Suggested balance:
  • periodically “swing” between executing and rebuilding foundational knowledge,
  • become comfortable enough to move fast while deepening understanding.

13) GenAI and “deep research” positioning (controversial take)

• The speaker(s) argue that many current AI uses may not be ideal for genAI.
• A more promising fit is:
  • problems requiring search across large corpora (information retrieval and synthesis).
• This is described as relevant to tooling that analyzes markets/users/segments by crawling and summarizing sources.
• Underlying software engineering problems remain regardless of AI:
  • search, ranking,
  • embeddings/vectors vs. classic keyword search.

---

Methodologies / practical instructions mentioned

A) How to learn as an engineer (from the discussion)

• Build something to learn:
  • start with a real technical or personal project,
  • choose a clear learning goal (professional or personal),
  • force yourself into situations where you must use the skill.
• Iterate through experimentation:
  • try multiple approaches,
  • intentionally observe failure cases,
  • document what worked, what didn’t, and why.
• Use curiosity and “safe failure”:
  • test ideas you think may not work,
  • treat “not working” as data, not wasted effort.

B) How to avoid the “Z problem” when solving issues

• Before choosing a solution:
  • ask what the real requirement/intention is,
  • identify whether the problem is actually the “special part” someone is stuck on.
• During troubleshooting:
  • communicate back and forth to understand the core goal,
  • consider alternative approaches not tied to one favorite technique.
• Decide based on requirement fit:
  • validate you’re addressing the actual need,
  • avoid prematurely optimizing for a narrow technical workaround.

C) Stakeholder engagement approach (co-creation)

• When priorities are unclear or stakeholders have urgent needs:
  • prefer collaborative sessions where stakeholders and engineers discuss context together.
• Create recurring touchpoints:
  • let stakeholders co-create solutions,
  • ensure stakeholders understand tradeoffs and constraints.
• Maintain transparency continuously:
  • share demos,
  • share what’s next,
  • share learnings and retros outcomes.
• Avoid proxy-only flows when they cause bypassing/stress:
  • prevent stakeholders from going directly to engineering in unstructured ways,
  • reduce panic caused by last-minute urgency without shared context.

D) Experimentation leadership guidance

• Enable fast experiments:
  • allow failure early,
  • keep experiment costs low.
• Set boundaries:
  • be stricter when the experiment impacts security or critical paths.
• Build credibility through learning:
  • don’t demand compliance solely by authority,
  • lead by enabling teams to discover what works.

E) Team structure principle

• Avoid hard technical silos when they create overhead:
  • create overlap/involvement across disciplines as needed for meaningful delivery.
• Prefer cross-functional collaboration to end-to-end integration:
  • reduce “handoff integration at the end,” which is slower.

F) Career skill balancing strategy (implied)

• Use “sphere of influence” to guide what to prioritize:
  • early: code execution + collaboration basics,
  • later: communication and decision-making across teams.
• Periodically swing between:
  • executing (building and shipping),
  • strengthening foundations (filling knowledge gaps).

---

Speakers / sources featured (identified)

Speakers

• Patrick Akil (host)
• Fardjad Davari (guest; software engineer)

Sources referenced

• Stack Overflow (example of expert question/answer behavior and “avoid the Z problem”)
• “It doesn’t have to be crazy at work” (book; company-as-product and management ideas)
• V8 Vector Search Database (mentioned as an example conversation topic / vector search company)
• OpenAI (referenced for “deep research” functionality and genAI discussion)