[dkarl]

> absorb best practices by osmosis a few years after they're developed by the bigshots

Better yet, ignore the concept of "best practices" and learn what different software development practices have to offer in different contexts, from your personal experience and from nuanced reports from people you (at least somewhat) trust.

There are a lot of ideas flying around about how to do software development better, in my experience, someone describing an idea as a "best practice" is more likely to be a red flag than a sign you should pay attention.

That said, try Copilot. It's surprisingly helpful.

[specproc]

Yeah, Copilot is worthwhile. You need to keep an eye on it, I've definitely been sent down the wrong path plenty of times, but all in all it's been enough help enough times.

The trick is knowing when to have it off and when to have it on.

I particularly like Copilot Chat. Really nice to have there in the IDE.

[cschneid]

Can I ask for a real example of it? I'm a senior dev, worked in software for ~18 years now. We work in a medium to large sized Rails codebase, with some idioms for things like logging and error handling that have been built over time. We mostly deal with detailed business logic.

I have really wanted to like AI assistance, but I can't figure out when it really helps. I'm an expert at ruby already, a targeted google search is faster than asking when it comes to an api I know exists, and I just need the order of arguments. It generates annoyingly "wrong" code, since it doesn't know our idioms.

Copilot is basically just a context-aware one line autocomplete. I can't figure out how to use it for more.

[dkarl]

Not just one line, but often 3-4 lines, and when writing tests, it often completes 10+ lines for me, and I only have to make a few corrections, sometimes none at all.

You have to read every line and character it suggests, but even so, it saves time.

It has also helped me while learning Typescript. As a beginner, it wasn't/isn't always clear to me how to find the types I need to use in third-party libraries like the Firebase SDK, and generating the code via Copilot and then finding the types it references helps me work backwards to understand where the types are declared. Sometimes, working with Copilot is like having documentation with tailor-made examples. Sometimes it's just wrong, though, so it's a mixed bag.

[specproc]

I'm not young, but considerably less experienced and more of a data scientist, so YMMV.

I'm signed up to the Copilot Chat preview so there are two parts to this answer: autocomplete and chat.

Autocomplete is great for things like boilerplate, docstrings, and annoying tip-of-tongue syntax.

It's a lot less helpful when working on something more creative or difficult, and that's when it needs to be off. I find it's an absolute no-go for complex data analysis, for example.

The Chat function is just GPT in IDE, so use is optional at all times.

As a concrete example, I was doing a Django project recently. I've done a few in the past, but I'm far from being an expert.

Things like the models.py were a breeze with the autocomplete on, but fell apart rapidly when writing a fiddly feature.

I used the chat whenever I ran across issues for which I wasn't finding quick answers on SO. This generally worked well, particularly as you can ask as many follow up questions as you like.

I also found chat good in other areas where I'm out of my comfort zone. Like throwing some vanilla HTML at it and asking for some CSS to layout and format in a particular way.

Long and short is it enabled a fair-to-middling dev to rapidly knock-up and document something in a relatively unfamiliar framework that was useful to his org.

In your case, you might find you have more truck with it when exploring something new or less familiar.

[huijzer]

My impression is that Copilot mostly saves me a lot of typing; even on top of using Nvim. Mostly those little refactors where some complex statement is moved partially to a separate variable. On personal codebases, also sometimes helper functions which are on the edge of what could have been in the base language.