Finish all but intro and ending section

This commit is contained in:
Corbin Crutchley
2021-09-28 03:06:28 -07:00
parent d216779c81
commit 7c55708a97

View File

@@ -83,6 +83,8 @@ const usageOfChar = (str, char) => {
}
```
![GitHub copilot making the code suggestions shown above with only a function name](./utils-suggestions.png)
While there may be _faster_ implementations of some of these, they're undoubtedly extremely readable and maintainable - they're how I'd implement these functions myself!
@@ -114,9 +116,10 @@ class BinarySearchTree {
}
```
This isn't all that was suggested by Copilot, either - [it generated a full implementation of a depth-first binary tree](https://github.com/CoderPad/github-copilot-interview-question/blob/main/questions/javascript/binary-depth-search.js)!
![Showcasing GitHub Copilot generating the binary file from a single class name](./binary.png)
This is an impressive range of capabilities for an automated code generation tool. While I would likely want to customize or otherwise modify this exact implementation, this is a very valid base of a binary tree that I could take an expand into something production-ready.
## Invisible Helper
@@ -179,21 +182,35 @@ But honestly, I was lucky to've been taken on as a Junior so early on into my co
This is why that Tweet stuck out so much in my mind. Would I have learned code as quickly if I was doing independent study without a such in-depth reference point to others' code? Likely not.
Sure, theoretically a new developer could jump into any number of open source projects and gain experience that way. But how many of those projects are able to provide 1:1 mentorship and code review on every PR? As it stands open-source maintainers are regularly overworked and unpaid for their efforts.
Sure, theoretically a new developer could jump into any number of open source projects and gain experience that way. But **how many of those projects are able to provide 1:1 mentorship** and code review on every PR? As it stands open-source maintainers are regularly overworked and unpaid for their efforts.
Moreover: how does a new developer's confidence play into that? I started with Angular as my first web framework, didn't have a formal education, and saw Google as an infallible agent of raw engineering in my first year. **Terms like "Dependency injection" and "Ahead-of-time compiler" scared me into feeling as if it were "unsafe" to read through any of the project's source code until I had found out that [I was rewriting it's source code without knowing it](https://unicorn-utterances.com/posts/angular-templates-start-to-source/#directive-same-name-input)**.
Even today, a developer of 7 years professionally - having written compilers and apps with millions of users - I am still oftentimes intimidated to read through large project's codebase. I regularly have to psyche myself out and reassure myself that it's okay to explore before diving into big source projects.
Even today, a developer of 7 years professionally - having written compilers and apps with millions of users - I am still oftentimes intimidated to read through large project's codebase. **I regularly have to psyche myself out and reassure myself that it's okay to explore before diving into big source projects.**
The beauty (and, unfortunately, again, [controversy](https://twitter.com/eevee/status/1410037309848752128)) of GitHub Copilot in this instance is that it doesn't tell you where large chunks of its generated code comes from. You're able to find new ways to do things and want to learn and research more without all the self-imposed stress I mentioned.
The beauty (and, unfortunately, again, [controversy](https://twitter.com/eevee/status/1410037309848752128)) of **GitHub Copilot in this instance is that it doesn't tell you where large chunks of its generated code comes from**. You're able to find new ways to do things and want to learn and research more without all the self-imposed stress I mentioned.
I've seen code generated by Copilot that could easily pass for logic within any major framework or application I've ever read through.
But **I don't just see Copilot as an opportunity for newcomer developers to learn**. For example, I'm familiar with binary search trees. I have written implementations before. But I won't lie: It's been a long time. Further, the last time I saw a tree in a production codebase, it was significantly more complex than an early implementation with only the core concepts exposed.
Being able to generate a decent implementation to a tree in my IDE is helpful for me to compare-and-contrast methods done there vs. what I would instinctually think of doing.
## Documentation
"Types are not documentation". If you've heard me say it once, you've probably heard me say it a dozen times. It's sorta a mantra for me.
> Here, I'll say it again: "Types are not documentation"
Unfortunately for me: My mantras don't define the outcome of a popular library's state of documentation. While making an upstream PR is almost always the way-to-go to solve this problem long-term - it can be a long process to figure out how something works without any usage examples to go off of.
While Copilot is far from _solving_ this problem, it can help. Having GitHub's projects as a reference point, it may suggest usages of non-documented APIs that it's seen elsewhere.
Honestly though? The number of external codebases that are not documented at all that I'm working in nowadays is fairly low.
More often than not, I'm working in a codebase like Vue that has a massive surface area, good docs, but I'm not always sure where to look.
While it's no replacement to a helpful community (which Vue absolutely has) or some masterful [GoogleFu](https://www.urbandictionary.com/define.php?term=google-fu), Copilot can often help guide me towards what I'm looking for by that same "teaching by reference" principle I outlined earlier.
# Conclusion