It is also a lifesaver for complicated fiddly array index code. One of the most cognitively costly thing for me, decades into programming, is still anything related to array partitioning, or remapping indices. Copilot pretty quickly just gets what you’re trying to do and auto fills a correct line of code. It’s basically never wrong about this sort of thing. And even in the rare case where it’s not correct (usually because it’s mistaken about what I’m trying to do), it’s much faster for me to read the line and figure out what it does than it is to mentally slog through the problem and write the line from scratch.

> result_dataFrame['yearOverYearMin'] = year_dataFrame.groupby('partId')['unitCost'].min()

> result_dataFrame['yearOverYearMax'] = year_dataFrame.groupby('partId')['unitCost'].max()

> And big productivity booster on code entry.

Try reducing the DRY violations and you might have to write less. Almost the entire right side of the first two lines is repeated and third line is only that long because it has to recover the results from the map instead of using local variables.

While tools like boxing gloves reduce the damage your face takes it is usually better to just try and stop hitting yourself first.

Sometimes 2 lines of code is just better than 6 and not worth the extra brain cycles.

There's DRY, then there's premature optimization.

> Sometimes 2 lines of code is just better than 6 and not worth the extra brain cycles.

I am unsure about what could possibly be better about them? Twice the chance to misspell one of the string constants? Twice the time to write the code, which in this case seems to be the big blocker? Twice the code to update in case any of it has to change? Twice the complexity per line of code?

This is pretty much the case. It was a quickly needed report of data from our ERP system and dumped into an excel sheet to use. I had not used Pandas before but seemed like a good fit for me t build this out. The people who needed this info were not very sure about what they needed, so being un-DRY is better. This is only a maybe 2 page Jupyter sheet. So it's not a huge deal.

In any case, DRY is just an optimization theme. And optimizing for understanding/intent is a higher priority for me. Sometimes they intersect, sometimes not.

I disagree that this is premature, but best practice. This example is actually a small lesson how this autocomplete can construct slightly less readable code. Of course not really a problem of the tool as you have to refactor anyway.

Yea, I could definitely improve this code. This was a quick excel report I build by extracting some data out of our ERP and building the report in Pandas. So those min and max values get surfaced in the output excel sheet.

It was a bit of an emergency and I was figuring Pandas out at the same time. The un-dry structure is handy for me because I can quickly tweak individual things since as a company we are still figuring out what is needed in the report.

This. Copilot enables bad programming practices imo, especially through clunky APIs like pandas.

I've had Copilot teach/tell me about things I didn't know I needed to be considering.

I was writing a parser for URL query strings (?these=things&key=value) and at one point Copilot suggested

  return [decodeURIComponent(key), decodeURIComponent(value)];

and until I saw that I didn't even know that percent encoded text in URLs is something I needed to be thinking about.

Are you in an environment where the compiler / interpreter can do CSE across string-indexed dictionaries? If not, this code seems like it's gratuitously doing two extra dictionary lookups vs. an implementation using temporary variables. Now you may very well, and rightly, say "who cares" -- but to me, this is where I'd really see something like Copilot contribute. The example you gave saves typing, but leads to equal or lower quality "correct" code to what you would write anyway with a few more keystrokes -- but a system that could advise to consider the alternate version (with the human in the loop to confirm semantic equivalence for the particular dictionary in use, since the compiler / interpreter / advice tool probably cannot) would lead to not just more code per minute, but better code.

Is there a way to fast track being able to try out Copilot? I put my email down a few days after it was announced and haven't heard anything.

Absolutely cannot wait for this to come to SQL. Or is there a way already to adopt this?