undefined | Better HN

story

0 pointsnilsherzig1y ago0 comments

To give you some insights from someone with a different starting point:

For context I'm a 22 year old CS student and part-time SRE working on everything related to kubentes (golang, scripting, yaml, ...). I can assure you that reading the fucking manual isn't a thing my fellow students or I did when we could avoid it. I think that might be because university projects don't tend to be long lasting and finding quick pre build solutions - without understanding them - works just fine. There is no penalty for technical debt.

Now almost exclusively read the primary docs or code and I think that might (surprisingly?) be because of copilot.

The neovim copilot extension resulted in me not feeling the need to switch to my browser all the time. Not having to do this context switch and looking more at my code got me into reading the lsp provided symbol docs. After some time I noticed that copilot just made me feel like I know what I'm doing and reading the overlay docs provided a way deeper understanding.

0 comments

dkersten1y ago

Thanks for the perspective!

Do you think this helps or hinders your ability to internalise the information (ie so that you don’t need to look it up, in the browser or from the LSP)?

For me, I feel that documentation is a starting point, but the goal is always to not need to look it up, after a little ramp up time.

With that said, I do use ChatGPT as a replacement for documentation sometimes, asking it how to do things instead of looking it up, but again the goal is to internalise it rather than to rely on the docs or tools. I won’t shy away from reading primary documentation, though, when necessary.

nilsherzigOP1y ago

> Do you think it [copilot?] helps or hinders...

It showed me some nice shortcuts (quick anon js functions and the like) which I will be using in the future, but I noticed that I didn't remember multi step code flows. For example while trying to get the response from an http request in go, there is a chain of calls which you will most likely follow. Building the client > making the request > checking the response code > reading the body > maybe parsing the body if it's structured text. I had written this kind of flow hundreds of times while having copilot running, and I still could not write it myself - I just had this abstracted idea of what's happening, but no memory of the syntax.

> as a replacement for documentation

I feel like they are too focused. And not having to go through the docs to find the piece I'm searching for results in me missing out on important context / possibly even better ways to solve my problem.

j / k navigate · click thread line to collapse