Breadth or Depth? Growing Beyond Your Role

Expand your contribution with AI, choose where to build depth, and test whether your understanding can support the decisions you own.

AI makes it easier to contribute beyond your specialty. The next question is what you need to understand to take responsibility for that contribution—and where your understanding should grow next.

The episode opens with a change in the development cycle: AI can help at many steps, and engineers can participate in work that previously required waiting on another specialist. That creates a learning question alongside the productivity question. If AI writes the implementation, what understanding do you gain from the task?

The aim is to keep using that speed while retaining control over decisions and building knowledge you can use on the next problem. The episode follows three connected ideas: expanding your contribution, choosing depth, and checking the learning.

Episode 1 asked how to build confidence in AI-written code. If something breaks, the engineer still needs to understand the situation and decide what to do. Episode 2 carries that responsibility into unfamiliar areas: confidence in the current change and growth over time are related, but finishing the change does not settle both questions.

A frontend engineer can now attempt a backend change; a backend engineer can explore a UI; either may contribute to mobile, testing, or infrastructure. In the episode, AI reduces part of the dependency that used to block this work. The useful next question is how much understanding supports a particular contribution.

Finishing a task in an unfamiliar area is useful. It does not establish that you understand its failure modes. Keep a broad picture of the system, then invest in the areas where you repeatedly make consequential decisions.

Can you explain how the change works across layers? Can you retrace why this solution was chosen? Can you name the assumptions you cannot yet judge? A small demo should explain the decisions as well as show the happy path.

Abdallah describes demoing what he built as a way to expose missing understanding. Clicking a sort button and showing the rows move demonstrates behavior. Explaining why the query joins two tables, which assumptions it relies on, and how the result was checked demonstrates the reasoning behind the change.

The episode warns against sending the first working solution straight to review. Testing on fifty customers and loading the page once gives limited evidence. Ask how many customers production holds, whether activity is distributed evenly, and what happens when a few customers have much larger histories.

Consider a hypothetical customer dashboard sorted by activity. Joining customers to activity produces one row per matching activity. A customer with several activities can appear several times. A small, uniform fixture can hide this problem.

Clarify the contract: one row per customer, which activity defines ordering, what happens with ties, and whether sorting covers the entire result before pagination. For performance, use representative data and inspect the query plan. Correctness on a tiny example cannot establish production cost.

A comment from a teammate, reviewer, or AI can reveal a concept you have never encountered. The episode treats that as an opportunity: investigate what the observation means, then decide how much investment the gap deserves. A recurring backend responsibility may justify learning the principle thoroughly; a bounded one-off task may call for help, a note, and a narrower contribution.

Before diving into internals, trace the flow from the user’s expectation through the API, its contract, and the data model. This broad picture helps you notice where risk lives and where deeper knowledge would affect the rest of the system. Repeated exposure and team feedback make those signals clearer.

The episode emphasizes two practical reasons to go deeper. High impact demands enough understanding or qualified review to judge the consequences now. Frequent responsibility makes investment useful across future tasks: you can recognize the important detail sooner and review it more confidently. Curiosity is also a valid reason to explore, even when the work is not recurring.

Use the context AI already has to request a focused guide about the part you could not explain. First establish where that part sits in the larger flow, then investigate the specific mechanism. The purpose is to improve your judgment on similar work and your ability to review the decisions you previously needed help with.

For performance uncertainty, use a separate investigation with representative data and the query plan. Learning about row multiplicity answers a correctness question; it does not by itself establish whether a production query is affordable.

Reading an explanation can feel like learning. Make a prediction, compare it with an experiment, and explain the mismatch. Then change the example to check whether the principle transfers.

In the final part, Abdallah connects breadth to his interview experience and current work across frontend, backend, and mobile. His specialty remains valuable while foundations in other areas let him contribute to more of the problem. He also describes product-engineer interviews that asked what he would build and how he would structure features, alongside technical design.

AI lowers the effort of making ideas concrete through prototypes. That opens room for engineers, product managers, and designers to discuss several approaches and their technical trade-offs. The engineer’s contribution includes identifying consequential decisions, explaining constraints, and helping the team choose what is worth building.

Before optimizing activity order, ask why the user wants it. If the goal is deciding whom to follow up with, activity alone may be an incomplete signal. Freshness needs also affect whether you compute a result on demand or maintain a summary. A prototype makes the idea discussable; user evidence and technical investigation still determine whether it is useful and ready.

The closing argument keeps both halves together. Expertise in internals, design, or a technical specialty still matters. Broader understanding helps connect decisions across the system, while depth develops where impact, repetition, and desired ownership justify it. AI remains part of the workflow throughout.