Description du poste
I often find myself frustrated and overwhelmed when people try to explain things to me. It's similar to the guy in this Software engineer interns on their first day be like... video, but with me it's more like "Software engineer after 12 years be like...".
At a high level, the conversations I'm referring to look something like this:
Eric: Here is how A works.
Eric: Here is how B works.
Eric: Here is how C works.
Adam: Um —
Eric: Here is how D works.
Adam: But —
Eric: Here is how E works.
Adam: I —
Eric: Here is how F works...
In this example, B depends on A. In order to understand B, you have to first understand A.
When Eric tried to explain B to me, I didn't understand A yet. Without understanding A, I wasn't ready to hear an explanation of how B works.
Ideally, before explaining B, Eric would have checked in to see if I understand A. Only once I understand A do we have the green light to proceed.
JavaScriptA thought occurred to me the other day: this situation seems analogous to software dependencies. Consider the following JavaScript code:[1]
// b.js
import { a } from 'a';
const result = a + 2;
export { result };b.js depends on a. Without a, b.js isn't able to run. In order for b.js to run, there needs to be a node_modules directory with an a package. Something like this:
b.js
node_modules/
a/
package.json
index.jsSuppose you want to run b.js but see that node_modules is missing a. You can run npm install a to download the dependency.
Returning to the analogy with Eric:
• In explaining B to me, it's like Eric is trying to run b.js.• Because I didn't yet understand A, it's as if my node_modules didn't have an a package.• Ideally, before running b.js, Eric would have "checked my node_modules", seen that my "a package" was missing, and "ran npm install a".ComplexIn a more complicated situation, Eric might want to utilize something like package.json and npm install. For example, consider the following:
In order to understand F, you need to understand D