zlacker

>>orph+(OP)
I’ve never understood the value proposition for Copilot.

In terms of difficulty, writing code is maybe on average a two out of ten.

On average, maintaining code you wrote recently is probably a three out of ten in terms of difficulty, and maintaining code somebody else wrote or code from a long time ago probably rises to around a five out of ten.

Debugging misbehaving code is probably a seven out of ten or higher.

GitHub Copilot is optimising the part of the process that was already the easiest, and makes the other parts harder because it moves you from the “I wrote this” path to the “somebody else wrote this” path.

Even during the initial write, it changes the writing process from programming (which is easy) to understanding somebody else’s code to ensure that it’s right before accepting the suggestion (which is much less easy). I just don’t understand how this is a net time/energy savings?

>>mewse+4T
By the same logic you've presented, what's the value proposition of the plain-old auto-completion? What's the value proposition of a slick editor? All you need is the built-in notepad and a debugger.

Speaking from my personal experience, I usually write code in TDD style, in which I test the properties of the software I desire upfront, then make it pass with a minimal amount of effort. When I see there's a need for refactoring, I refactor. And I repeat this process until it is done.

The three parts take roughly the same portion of time, and when I'm writing tests, I'm thinking about the functionality and value of the software. When I'm refactoring I'm thinking about the design. When I'm writing the implementation initially, I want it to Just Work™ in the first place, and I find Copilot is great for this matter: why not delegate the boring part to the machine?

>>namelo+vH1
You know, perhaps this is tangential to the point that you're making at best, but i still couldn't help but to notice:

> The three parts take roughly the same portion of time, and when I'm writing tests

that bit and have some strong feelings about it. At my current dayjob, writing tests (if it was even done for all code) would easily take anywhere between 50% and 75% of the total development time.

I wish things were easy enough for writing test code not to be a total slog, but sadly there are too many factors in place:

  - what should the test class be annotated with and which bits of the Spring context (Java) will get started with it
  - i can't test the DB because the tests don't have a local one with 100% automated migrations, nor an in memory one because of the need to use Oracle, so i need to prevent it from ever being called
  - that said, the logic that i need to test involves at least 5 to 10 different service calls, which them use another 5 to 20 DB mappers (myBatis) and possibly dozens of different DB calls
  - and when i finally figure out what i want to test, the logic for mocking will definitely fail the first time due to Mockito idiosyncrasies
  - after that's been resolved, i'll probably need to stub out a whole bunch of fake DB calls, that will return deeply nested data structures
  - of course, i still need all of this to make sense, since the DB is full of EAV and OTLT patterns (https://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html) as opposed to proper foreign keys (instead you end up with something like target_table and target_table_row_id, except named way worse and not containing a table name but some enum that's stored in the app, so you can't just figure out how everything works without looking through both)
  - and once i've finally mocked all of the service calls, DB calls and data initialization, there's also validation logic that does its own service calls which may or may not be the same, thus doubling the work
  - of course, the validators are initialized based on reflection and target types, such as EntityValidator being injected, however actually being one of ~100 supported subclasses, which may or may not be the ones you expect due to years of cruft, you can't just do ctrl+click to open the definition, since that opens the superclass not the subclass
  - and once all of that works, you have to hope that 95% of the test code that vaguely correseponds to what the application would actually be doing won't fail at any number of points, just so you can do one assertion

I'm not quite sure how things can get that bad or how people can architect systems to be coupled like that in the first place, but at the conclusion of my quasi-rant i'd like to suggest that many of the systems out there definitely aren't easily testable or testable at all.

That said, it's nice that at least your workflow works out like that!

>>Kronis+mc2
Have you read Working Effectively with Legacy Code?

It's transformative in situations like this, it has a bunch of recipes for solving these kinds of problems.

While I don't use Java or C++, this book has probably been the most useful to me in working with larger bodies of code.

>>disgru+Af2
While the book is indeed good, it's pretty hard to do anything to improve that particular codebase because there are developers who are actively introducing more and more of the problematic patterns and practices even as i write this.

To them it isn't "legacy code" but just "code", while attempting to offer alternatives either earns you blank stares or expressing concerns about anything new causing inconsistencies with the old (which is a valid concern but also doesn't help when the supposedly consistent code is unusable).

To me it feels like it's also a social problem, not just a technical one and if your hands are essentially tied im that situation and you fail to get the other devs and managers onboard, then you'll simply have to either be very patient or let your legs do the work instead.