Software engineers research continuously: reading documentation, exploring library APIs, investigating unfamiliar code patterns, researching architectural approaches, debugging production issues, and keeping current with technical developments in their field. The research-to-output challenge for engineers is ensuring that this research converts into working solutions, technical decisions, and useful knowledge rather than remaining as background reading that didn't produce anything concrete.
Engineering research has four output paths: implementation (research that produces working code), technical decisions (research that informs architecture or design choices), documentation (research that produces technical documentation for the team), and knowledge capture (research that produces knowledge base entries for future use). Each path has its own workflow.
Output Path 1: Research to Implementation
The most common engineering research-to-output path is research that leads directly to implementation: reading documentation to understand how to use an API, exploring code to understand how a system works, or investigating approaches to a technical problem before choosing one.
The implementation-focused research approach:
Implementation research should be bounded by a specific question. The engineer who begins researching "how to implement pagination in this system" and ends up reading about every pagination pattern that has ever existed has done interesting research that produced nothing. The engineer who researches "what's the best approach for cursor-based pagination given this system's constraints" has done focused research that informs a specific implementation decision.
Research to implementation workflow:
IMPLEMENTATION RESEARCH
Problem: [What I'm trying to build or fix — specific]
Question: [The specific question this research needs to answer]
WHAT I FOUND:
Approach 1: [Name]
How it works: [Brief]
Pros for my context: [Why this might work]
Cons for my context: [Why this might not work]
Approach 2: [Name + same fields]
DECISION:
What I'm implementing: [The chosen approach]
Why: [Given my specific constraints and context]
IMPLEMENTATION NOTES:
The key insight: [What made this work]
Non-obvious parts: [What required investigation to understand]
Code reference: [Link or file location]
KB UPDATE:
[ ] Solution captured in debugging/solution KB
[ ] Architecture decision captured if appropriate
The "non-obvious parts" field is the knowledge capture that has the highest future value. The part of the implementation that required research — the behavior that isn't documented clearly, the constraint that isn't obvious until you encounter it — is exactly the knowledge that will be needed again and that won't be in the official documentation.
Output Path 2: Research to Technical Decision
Some research is explicitly in service of a technical decision: evaluating technology options, assessing architectural approaches, or investigating whether a specific technical constraint exists.
The decision research workflow:
Technical decision research should be structured around the decision criteria: what factors matter for this decision, and how do the options compare on those factors?
TECHNICAL DECISION RESEARCH
Decision to be made: [What are we deciding?]
Context: [Why we're making this decision now + constraints]
Decision criteria: [What factors matter for this decision]
OPTIONS INVESTIGATED:
Option A: [Name]
How I investigated this: [Documentation, prototypes, examples]
Performance against criteria: [How it does on each factor]
Option B: [Name + same fields]
RECOMMENDATION:
Suggested option: [What I recommend]
Primary reasons: [The 2-3 main factors driving the recommendation]
Risks: [What might go wrong with this choice]
When to reconsider: [Conditions that would change the recommendation]
OUTPUT:
[ ] ADR written
[ ] Decision documented in codebase or wiki
[ ] Team notified
Prototyping as research:
For significant technical decisions, building a small prototype is often the most reliable research method. Reading documentation about how something works produces a theoretical understanding; building a small working example reveals the practical realities — the unexpected constraints, the performance characteristics at scale, the developer experience of working with the API.
A prototype built for a technical decision should be lightweight: the goal is to answer specific questions about the option, not to build production-quality code. But the prototype result — what it revealed about the approach — should be documented.
Output Path 3: Research to Documentation
Technical research sometimes reveals that a gap in existing documentation is causing repeated confusion, and the right output is documentation rather than (or in addition to) implementation.
The documentation gap identification:
The trigger for research-to-documentation output is usually one of:
- A question asked repeatedly in team channels that isn't answered in existing docs
- Knowledge that exists only in one person's head and needs to be distributed
- Understanding developed during debugging or implementation that would have saved time if it had been documented before
Documentation output principles:
Technical documentation that comes from research has an advantage over documentation written "from knowledge": it reflects the questions and confusions that actual learners encounter, not the questions an expert thinks learners should have. Good technical documentation is organized by the learner's question, not by the expert's model of the system.
The "what triggered this document" meta-note helps future writers know when the document might need updating: "this document was written because of a recurring question about X" tells a future reader that when X is no longer an issue, the document may no longer be needed.
Output Path 4: Research to Knowledge Capture
Not all research produces immediate output — sometimes research accumulates background knowledge that isn't needed right now but will be. The knowledge capture output path converts this background learning into retrievable personal knowledge rather than allowing it to fade.
The capture-on-learning trigger:
Research-to-knowledge-capture should be triggered by the feeling "I didn't know this and I might need it again" — not by "this is interesting." The difference matters: interesting technical information produces enjoyable reading; useful-in-the-future information produces knowledge base entries.
The knowledge capture from learning:
TECHNICAL LEARNING CAPTURE
What I learned: [The specific knowledge]
Where I learned it: [Source + URL]
Context: [What I was working on when I learned this]
WHY THIS IS WORTH CAPTURING:
When I'd need this: [Future situations where this would be relevant]
Why it's not obvious: [What makes this worth capturing vs. what could be re-derived]
THE KNOWLEDGE:
Key insight: [The substance — not just "read this article"]
How to apply it: [Practical application]
Caveats: [When this doesn't apply]
KB UPDATE:
[ ] Appropriate KB domain updated with tags
The "why it's not obvious" gate prevents the knowledge base from filling with things that could be easily re-found through search. The knowledge that's worth capturing is knowledge that would be hard to find again, knowledge that's specific to a particular system or context, or knowledge that requires significant synthesis to produce.
The Integration: Research Session Discipline
Before starting research:
- What specific question am I trying to answer?
- What output will this research produce? (implementation / decision / documentation / knowledge)
- What's the time box for this research?
During research:
- Am I making progress on the specific question, or am I exploring interesting adjacent territory?
- When I find the answer, am I capturing it in the right form for the output path?
After research:
- Did I produce the intended output?
- Is there anything worth capturing for the knowledge base beyond the immediate output?
- Did this research reveal a documentation gap?
The time box:
Research without a time box tends to expand to fill available time. Setting a time box — "I'm going to research this for 90 minutes and then make a decision with what I know" — prevents research from becoming procrastination. If the time box expires without an answer, the question is either poorly defined or the problem is harder than expected; either is worth surfacing.
Key Takeaways
-
Implementation research should start with a specific question. "What approach should I use for X given these constraints?" produces a decision; "what are the options for X?" produces a survey.
-
Capture the "non-obvious" parts of implementations. The part that required research — the undocumented behavior, the surprising constraint — is exactly what will need to be re-discovered without capture.
-
Prototyping is the most reliable research method for significant technical decisions. Reading about how something works produces theory; building a prototype reveals practical realities.
-
Documentation output triggers are repeated questions and knowledge that lives only in one person's head. Good technical documentation is organized by the learner's question, not the expert's model.
-
The "why it's not obvious" gate determines what's worth capturing. Knowledge that's easily re-found through search doesn't need a knowledge base entry; knowledge specific to a context or requiring synthesis to produce does.
Conclusion
Software engineering research produces four output types: implementation (bounded by a specific question; "non-obvious parts" captured for the KB); technical decisions (research structured around decision criteria; prototyping as the most reliable investigation method; ADR as the documentation output); documentation (triggered by repeated questions and single-point-of-knowledge problems; organized by learner's question); and knowledge capture (triggered by "I'd need this again and it's not obvious"; "why it's not obvious" gate for what's worth capturing). The research session discipline — specific question before starting, output path identified, time box set — is what prevents engineering research from becoming background reading that doesn't produce anything.
For more on this, see Clip Articles for Later Reading.