How To Actually Build On Other People's Work Without Making It Worse
You have probably heard the phrase before. I am not here to trace the etymology of Bernard of Chartres or explain why Newton wrote to Hooke about it. I am here to tell you how this actually works when you are trying to ship something real. The core idea is simple. You find what someone else has already solved, you understand the limits of their solution, and you extend it from there. The hard part is the "understand the limits" part. Most people skip that step and spend three weeks debugging something the original author already documented in their issue tracker. In practice this is a workflow, not a mood. Start by identifying what you are actually trying to do. Then search for existing implementations, papers, libraries, or frameworks that solve a closely related problem. Read the source or the methodology section carefully. The documentation will only show you the happy path. The edge cases live in the issues, the pull requests, and the comments on older blog posts. I spent a week trying to adapt a Python package for a data pipeline project because I did not read the release notes. The package worked fine for structured JSON. My data had nested arrays with mixed types. The author had acknowledged this limitation two years ago and recommended a preprocessing step. I found that in a comment buried in issue #47. Once I added a normalizer before the ingestion step, everything ran in about twelve minutes instead of crashing repeatedly. That saved me roughly a day and a half of frustration.
The Method
Step one is scoping. Define the boundary of what you need. Write it down in one or two sentences. If you cannot describe the problem narrowly, you cannot identify the right foundation. Step two is discovery. Look for established solutions in your domain. Prioritize things with active maintenance, clear licensing, and documentation that includes examples. A library with five stars and no examples is a gamble. A lesser-known project with thorough API docs and a changelog is usually worth more. Step three is evaluation. Try the minimal example exactly as written. Do not modify it. Run it against your environment. If it fails immediately, check whether the issue is your setup or a known incompatibility. Search the issue tracker first. Many beginners assume a missing dependency means the project is abandoned. It usually just means the README was written on a different OS version. Step four is integration. Once the base works, add your variation. Incremental changes only. Do not refactor the upstream code while you are still learning how it behaves. That is the fastest way to lose track of what broke. Keep a diff or a fork and note every modification in a log file. You will thank yourself later when something stops working and you need to know what changed.
Step five is validation. Test your extended version against the same cases the original author tested, plus your own. This is where most people fail. They assume the foundation is solid and skip testing the overlap area. That overlap is where bugs hide. It is also where you discover that your use case actually exposes a design assumption the author made that does not hold for your data shape.
Common Pitfalls
The biggest trap is abstraction mismatch. Someone solved a problem at a higher level than you need. Their solution works, but it adds overhead you do not want and cannot easily remove. I once pulled in a full-featured HTTP client library for a script that only needed to send a few POST requests. It added forty seconds to startup time because of dependency loading. A simple socket-level call would have taken two hundred milliseconds. The lesson was not that the library was bad. The lesson was that I should have matched the tool to the task instead of reaching for the most popular option. Another pitfall is license ignorance. You find a great piece of code, reuse it in a commercial product, and then get a cease and desist because the project is GPL rather than MIT. Check the license before you integrate anything. This takes about three minutes and prevents problems that take three months to untangle. A third pitfall is stale references. Academic papers often cite other papers. You trace a citation back and find the original implementation link is broken. The code has moved, the repo is archived, or the author renamed the project. In those cases, look for forks, mirror repositories, or the author's current GitHub profile. Sometimes the best replacement is not a direct clone but a newer library that solved the same problem using a different approach. You should evaluate both and pick the one that fits your stack.
When This Approach Fails
Standing on the shoulders of a giant does not work when your problem is fundamentally different from anything anyone has tackled before. Some research areas, novel hardware integrations, or highly regulated industries have very little existing work to build on. In those situations, you may need to start from first principles. The cost is higher. The timeline is longer. You will make more mistakes because there is no one to learn from directly. Accept that early so you do not waste time looking for a foundation that does not exist. Another scenario where this breaks down is when the available solutions are all proprietary or require paid licenses that exceed your budget. I worked on a project where every viable open-source option had a paid enterprise tier for the features we needed. We ended up writing our own module. It took longer, but it removed the licensing constraint and gave us control over the feature set.
A Practical Example
Let us say you are building a small reporting tool that aggregates logs from multiple services. You search for existing log aggregation libraries and find three candidates. One is well-maintained but designed for high-throughput streaming. Another is simpler but lacks filtering. The third is outdated but has the exact parsing behavior you need. You choose the third, update its dependencies, and test it with your sample logs. It parses correctly. You add a filter wrapper around it instead of rewriting the parser. You write unit tests for the filter. You document the change. The final tool is functional in about two days instead of two weeks. The time savings come from not rebuilding the parser. The risk comes from inheriting the parser's untested edge cases. Mitigate that risk by writing tests against unusual input: empty lines, malformed timestamps, oversized fields. If the parser handles those, you are in good shape. If it does not, either patch it or switch to the second candidate and accept the longer development time.
Where To Find Good Foundations
GitHub remains the primary source for code. For academic work, Google Scholar and arXiv are useful. For domain-specific knowledge, check community forums, Stack Exchange threads, and project mailing lists. Mailing lists are underrated. The discussions there often contain detailed reasoning about design decisions. Reading a thread where the author explains why they rejected an alternative approach teaches you more than the final documentation does. Conferences and meetups are also valuable. A talk you see in person often includes practical tips that never make it into the slides. I learned about a caching bug in a popular framework from a presenter who admitted it during Q and A. He showed a workaround that involved disabling a specific optimization flag. That fix saved me from investigating a problem that looked like a memory leak but was actually a cache invalidation issue.
The Core Discipline
The entire approach comes down to discipline. Do not copy blindly. Do not assume someone else's solution is complete. Test the foundation before you build on it. Keep your changes minimal and documented. When something breaks, check your diff first, not the upstream repo. Most of the time the issue is your modification, not the original code. There is no shortcut for reading the code. There is no shortcut for understanding the assumptions. The people who do this well are not the ones who find the most impressive library. They are the ones who read it carefully, test it honestly, and extend it responsibly. That is the whole thing. It feels mundane when you do it. It also works every time you apply it consistently.
