Hacker News Reader

Comment by MattGaiser | Hacker News Reader

> the people who write the software are not fully aware of how it all works.

Is this much different from now? I have no idea how most of the libraries I use are implemented.

I've found that I typically don't need to know how it works if my use case is common and the library is well documented, but when either of those doesn't hold it can be very helpful to read through the implementation in the source to understand how best to implement. But I think the black box would be less of an issue when interfacing with documented third party libraries, than with internally developed services and libraries, particularly in smaller orgs. Team A 'generated' Service A and Team B needs to integrate it in their 'generated' Service B, it seems that could get messy and would be tough to test or troubleshoot. Possibly an additional AI tool specifically for compatibility and integration could solve that problem.

You don't know how other peoples' libraries work, and that's fine.

I think in this case the argument is that the author of the library also doesn't know how it works. Which means they can't fix it.

In addition to this, if the source code is available you could potentially take a peek and generally understand what's going on. But I can imagine that we could have a generation of developers who know little about nuts and bolts that underpin how their software works. Perhaps this is now already the case in certain domains. E.g. you could be working on a Jupyter notebook and be effective without being aware of what's happening behind the scenes. I think is qualitatively different as in this example you could be working at such a high level of abstraction that the nuts and bolts are not something you'd even be aware of. Whereas if you're writing a Java program and you bring in some third party libraries you could potentially look up that library. But more importantly you're still relatively close to the metal.

Reply on news.ycombinator.com