401–410 of 446 posts
Earlier quoted context omitted.
I think current co-pilot is less useful for person who entirely knows the language and libraries. Right know I see more use for people who understand the language and libraries, but are frequently Googling ”how do I do xyz in P” (because they can’t recall certain things).
Bouncing around languages and ecosystems is pretty common, isn't it?
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. Gi…
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 r…
> 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
That said, it's nice that at least your workflow works out like that!
Earlier quoted context omitted.
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 r…
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…
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.
Earlier quoted context omitted.
For what it's worth, Copilot can do it. I typed the following prompt: def search_wikipedia(lat, lon): """ use "requests" to do a geosearch on Wikipedia and pretty-print the resulting JSON """ And it completed it with: r = requests.get('https://en.wikipedia.org/w/api.php?action=query&list=geosearch&gsradius=10000&gscoord={0}|{1}&gslimit=20&format=json'.format(lat, lon)) pprint.pprint(r.json())
It's like a junior dev who doesn't quit unnecessary code golfing. Somehow the AI is more comfortable with string-based URL manipulation, which is a straight anti-pattern.
Earlier quoted context omitted.
> Because I've been using it for weeks and it makes me read these types of comments as "I don't understand the value of the internet" or "what's the purpose of owning a phone". And yet apart from making this very inaccurate comparison you haven't made any argument for why such a thing as Copilot would be useful to anyone. How do you personally find Copilot useful? And why do you think someone whose job demands more t…
> The onus is on you to convince the skeptics. Is it? Look, I don't care at all if you use copilot; you can use notepad to write your code if that floats your boat; do whatever you want. What the parent post said is: Copilot is useful; it helps you write code with autocomplete suggestions. If you think that you don't get productivity gains from an IDE or you're in the 'no IDE makes you more hardcore and better progra…
Over the past decades we went from snail mail to email to instant messaging, each step made it easier to write text to a person. Today, we are writing so many messages to each other that people have started arguing for less instant messaging and less email. Mainly because distractions and frequent context shifts allegedly reduce productivity and happiness.
With Copilot, we have a similar evolution where writing code becomes easier. Could this result in people writing more and more code since it is a smaller effort? What would this do to the developer ecosystem in the long term? Maybe code reviews will take longer because there is more code and because it is more likely for junior developers to introduce bugs using copilot code. Maybe this results in more bugs slipping through code reviews and into production and eventually lower productivity and happiness since more time is spent stress-fully fixing production errors. I can't predict the future, but I do think it's valuable to ask these questions before it's too late.
Earlier quoted context omitted.
> The onus is on you to convince the skeptics. Is it? Look, I don't care at all if you use copilot; you can use notepad to write your code if that floats your boat; do whatever you want. What the parent post said is: Copilot is useful; it helps you write code with autocomplete suggestions. If you think that you don't get productivity gains from an IDE or you're in the 'no IDE makes you more hardcore and better progra…
That sounds about as useful as Tesla's "auto-pilot" - good when it works but you have to always pay attention that it's not trying to kill you (or your code in this case). A bad proposition for most people, because you can't trust it.
Earlier quoted context omitted.
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…
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.
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.
Earlier quoted context omitted.
I think it depends if you're getting paid. If they call you an intern because you're still in college or have no professional experience, but they're paying you fairly then it seems like a fine arrangement they ask you to do real work. On the other hand, if your compensation is primarily "experience" then I'd say you're being bamboozled.
I am being paid, although significantly less than my previous job. It's not that I can't do the work, but it feels like I'm being taken advantage of because I have no professional experience; although I have almost 10 years of personal experience. It might sound like I'm complaining about the work itself, but it's more than that to me.
Earlier quoted context omitted.
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 r…
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…
Sadly it's easier said than done, since it's not an easy thing to fix for an existing system. We've spent quite some time improving things to ease the pain on writing tests, it was getting better but would never reach the level if we were aware of this problem in the first place - there are tens of thousand tests and we cannot rewrite them all.
I'm not too familiar with your tech stack. But there are two things you mentioned that are especially tricky to handle for testing: DB and service calls.
For DB, there are typically two ways to handle it: Use real DB, or mock it.
Real DB makes people more confident, and don't need to mock too many things. The problem is it can be slow and not parallelizable, or worse, like your case there's no impotent environment at all. We had automated migrations, but the test was run against the SQL Server on the same machine, so it was not parallelizable so the tests took more than a day to run on a single machine. On CI there are tens of machines but still takes hours to finish. In the end, we generalized things a little bit, and used SQLite for testing in a parallel manner. (Many people suggest against this because it's different from production, but the tradeoff really saved us). A more ideal approach is to have SQL sandboxing like Ecto (written in Elixir). Another ideal approach is to have in memory lib that is close to DB, for example, the ORM Entity Framework has an in-memory implementation, which is extremely handy because it's written in C# itself.
If there's no way to leverage real DB, you have to mock it. One thing that might help you is to leverage the Inversion of Control pattern to deal with DB access, there are many doctrines like DDD repositories, Hexagonal, Clean Architecture but essentially they're similar on this point. In this way, you'll have a clean layer to mock, and you can hide the patterns like EAV under those modules. As you leverage them enough, they will evolve and there would be helpers that could simplify the mocking process. According to your description, the best bet I would say is to evolve toward this direction if there's no hope on using real DBs, as you can tuck as much as domain logic into the "core" without touching any of the infrastructures. So that the infrastructure tests could be just very simple and generic.
For service calls, the obvious thing is to mock those calls. The not so obvious thing is to have well-defined service boundaries in the first place. I cannot stress this enough. When people failed to do this, they will feel they're spending a lot of time mocking services, while at the same time they feel they've tested nothing because most things are mocked. Microservices were getting too much hype over the years, but very few people pay enough attention on how to define services boundaries. The ideal microservice should be mostly independent, while occasionally calling others. DDD strategic design is a great tool for designing good service boundaries (while DDD tactic design is yet another hype, just like how people care more about Jira than real Agile, making good things toxic). We were still struggling with this because refactoring microservice is substantially harder than refactoring code within services, but we do try to avoid more mistakes by carefully designing bounded contexts across the system.
With that said, when the service boundaries are well-defined, and if you have things like SQL sandboxing, it's a breeze to test things because most of the data you're testing against is in the same service's DB, and there are very few service calls need to be mocked.