Use Case
Let new developers ask questions about your codebase instead of interrupting senior engineers. Accelerate productivity and reduce onboarding time from months to weeks.
At UshaOm, I hired 27 engineers over two years. Our onboarding was a Google Doc and a 'find a buddy' message. Some engineers shipped their first PR in a week. Others took two months. The difference wasn't talent.
Getting a new engineer productive takes 30 to 90 days at most companies. Setting up the environment takes three days. Learning the tools and processes takes another week. But understanding the codebase takes three weeks or more. A new engineer spends a month in a constant state of not knowing what they don't know - asking the same questions experienced engineers have answered dozens of times, making changes that break things because they don't understand dependencies, waiting for synchronous answers to asynchronous questions.
The bottleneck in developer onboarding isn't environment setup or documentation. It's codebase comprehension. A new engineer needs answers to questions that only live in the code: What modules exist? Who owns each one? Why does this pattern work differently here than there? What's this code actually doing? Why is this dependency structured this way? How do we handle [cross-cutting concern] across the system?
These questions don't have single answers. They require understanding how the system is organized, how data flows through it, how different teams have structured different parts of it. Senior engineers can answer these questions quickly because they've internalized the codebase. New engineers can't. So they interrupt senior engineers constantly. Not because they're slow or unprepared - but because there's literally no other way to get answers about the territory they're operating in.
The cost is significant. A senior engineer spend 10-20% of their time answering onboarding questions. Across a 10-person team, that's one full-time engineer spend on onboarding. A new engineer is at 30% productivity for their first month because they're constantly context-switching between work and learning. And the institution loses knowledge when the person who answers onboarding questions leaves - that knowledge walks out the door.
For distributed or async teams, the problem is worse. New engineers can't just tap someone on the shoulder. They have to write a question, wait for a reply, context-switch while waiting, get an incomplete answer because it was written in 30 seconds, and come back with a follow-up. Onboarding takes twice as long. Senior engineers get deep-interrupted constantly because questions come in async and are always waiting for replies.
Most teams write documentation. Some of it is useful. Most of it is wrong - the code changed but the docs didn't, or the docs describe the happy path but not edge cases, or the docs are so abstract that they don't help someone trying to understand a specific module. Documentation requires someone to write it and maintain it. Most companies don't have that person, so docs rot.
Some teams pair new engineers with mentors. This works but it's expensive - the mentor is at 50% capacity for weeks. It only works if the mentor is available and patient. And it doesn't scale - you can't have more new engineers than mentors.
Others let new engineers just explore the codebase. This works for some people but takes time - a lot of time. The engineer might spend three days understanding why a module is structured a certain way and discover it's actually legacy code that could have been avoided. They might dig into code that's complex and spend days understanding it only to be told "that's on the list for refactoring, don't worry about it."
Some teams have an "onboarding checklist" of modules to learn about. But a checklist is passive - it doesn't respond to what the engineer actually needs to understand for their work. An engineer might spend a week learning the payment module when they're assigned to authentication. They're learning the wrong thing at the wrong time.
The deeper problem is that onboarding knowledge is asynchronous and personal. When a senior engineer answers a question, they're using context only they have. They might mention dependencies that matter, or edge cases to watch out for, or history about why something is the way it is. But if the next new engineer asks the same question, they might get a different answer from a different engineer, or a more complete answer, or a simpler answer. The knowledge isn't consistent because it's in people's heads, not in the system.
Glue lets new engineers ask questions directly instead of interrupting colleagues. This isn't search - it's comprehension. A new engineer can ask "What does the user authentication flow do?" and Glue shows the entire flow, from login through token generation through authorization checks, with each step's implementation and the modules involved. Not just code snippets - an explanation of what's actually happening.
A typical week-one onboarding with Glue looks different. A new engineer joins. They're assigned to the billing module. They ask Glue: "What does the billing module do?" Glue shows what's in the billing module, what it depends on, and what depends on it. The engineer immediately understands scope. They ask: "What does a billing transaction look like from end to end?" Glue shows the flow - user initiates charge, billing module calculates amount, integration with payment processor, transaction recorded, webhook confirmation, user notified. Each step linked to code.
The engineer spots a question: "What does this recurring billing logic do?" Glue shows how recurring charges are scheduled, how they're applied, how failed charges are retried, and what tests exist. The engineer can read the code more confidently because they understand the intent first. They ask: "Who owns this module and who has worked on it recently?" Glue shows commit history and can identify who has context.
Later in the week, the engineer is assigned a bug in the billing module. They ask Glue: "What are the data models that billing uses?" Glue shows the schema, relationships, and constraints. They ask: "What's the expected behavior when a charge fails?" Glue shows the code, tests, and error handling. The engineer now has context to understand the bug instead of guessing.
Specific queries work like this: "What does our subscription lifecycle look like?" Glue shows states, transitions, and code. "Where is currency conversion handled?" Glue finds the conversion logic. "What payment methods does our system support?" Glue lists them with implementation details. "What does an API request to [endpoint] do?" Glue traces the request through the system. "Who should I ask about [module]?" Glue shows recent contributors and knowledge owners.
The speed difference is dramatic. Without Glue, a new engineer asks "what does this do?" and waits for a synchronous reply from a senior engineer who has to context-switch. With Glue, the engineer gets a response in seconds. If the response doesn't answer the question, they can ask a follow-up immediately. They're not blocked on other people's availability.
For distributed teams, this is game-changing. Async onboarding that doesn't require interrupting senior engineers. A new engineer in a different timezone can ask questions and understand answers without waiting for meetings or real-time collaboration.
The benefits compound. New engineers become productive faster - not because they're smarter, but because they have answers to the questions blocking them. Senior engineers spend 80% less time on onboarding because they're not interrupting their work to answer questions. The knowledge about how the system works is consistent because it comes from the system itself, not from whoever happens to answer.
A new engineer is productive in their first feature work by week two instead of week four. They still need to learn your culture, your release process, your team norms. But they're not blocked on understanding the codebase. They can read code confidently because they understand what it's supposed to do and where the important parts are.
Senior engineers stop treating onboarding questions as a constant interruption. They have more time to ship features, think about architecture, and mentor in deeper ways than just answering "what does this code do?" The team's average delivery velocity is higher because the senior engineers aren't at 20% capacity on onboarding support.
As your team grows, onboarding time stays flat instead of growing. Adding five new engineers doesn't slow down the whole team because onboarding doesn't require proportional senior engineer time anymore. The institutional knowledge about your codebase is in Glue, not just in people's heads.
Q: Won't Glue just replace human mentorship? A: No. Glue answers "how does the system work?" Mentorship is about culture, judgment, and deeper learning. Glue handles the blocking questions so mentors can mentor instead of answer FAQs.
Q: What if the answer Glue gives is outdated? A: Glue queries your current codebase. If the code changed, Glue's answers will be current. (Unlike documentation, which can get stale.)
Q: Does every new engineer query Glue or do mentors still need to guide them? A: Both. A mentor still provides structure and guidance on what to learn and in what order. But instead of answering 100 questions a week, the mentor answers 10 substantive questions.
Q: How does Glue handle code that hasn't been changed in a long time but is still important? A: Glue can identify that code - it flags code that hasn't changed in years. The engineer knows to learn it for context but also that it's not in active development, which is valuable knowledge.
Keep reading
Related resources
