>> Use these tools for rapid onboarding onto new frameworks.

Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code. I have to make all the decisions, and guide it, but I don't need to learn Ruby to write acceptable-level code [0]. I get to be immediately productive in an unfamiliar environment, which is great.

[0] acceptable-level as defined by the rest of the team - they're checking my PRs.

▲ AdieuToLogic 5 days ago | parent [-]

>>> Use these tools for rapid onboarding onto new frameworks.

> Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code.

If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself?

> ... but I don't need to learn Ruby to write acceptable-level code [0].

Since the team you work with uses Ruby, why do you not need to learn it?

> [0] acceptable-level as defined by the rest of the team - they're checking my PRs.

Ah. Now I get it.

Instead of learning the lingua franca and being able to verify your own work, "the rest of the team" has to make sure your PR's will not obviously fail.

Here's a thought - has it crossed your mind that team members needing to determine if your PR's are acceptable is "a bad thing", in that it may indicate a lack of trust of the changes you have been introducing?

Furthermore, does this situation qualify as "immediately productive" for the team or only yourself?

EDIT:

If you are not a software engineer by trade and instead a stakeholder wanting to formally specify desired system changes to the engineering team, an approach to consider is authoring RSpec[0] specs to define feature/integration specifications instead of PR's.

This would enable you to codify functional requirements such that their satisfaction is provable, assist the engineering team's understanding of what must be done in the context of existing behavior, identify conflicting system requirements (if any) before engineering effort is expended, provide a suite of functional regression tests, and serve as executable documentation for team members.

0 - https://rspec.info/features/6-1/rspec-rails/feature-specs/fe...

▲ maccard 5 days ago | parent | next [-]

> Instead of learning the lingua franca and being able to verify your own work, "the rest of the team" has to make sure your PR's will not obviously fail.

I lead the engineering team at my org and we hire almost exclusively for c++ engineers (we make games). Our build system by happenstance is written in c#, as are all the automation scripts. Out of our control to change. Should we require every engineer to be competent and write fluent c# or should we let them just get on with their value adds?

▲

skydhash 5 days ago | parent [-]

Programming language are not actually that different. There’s only a few models of computation and paradigms. The effort is mostly about learning the syntax, the standard library and whatever abstractions built around the above paradigms and computation models. And learning the standard library is the tough one.

I would expect every engineer to be able to read C#. It’s not that hard.

	▲	marcus_holmes 4 days ago \| parent [-]
		This. Reading a language (and not only programming languages) is very different from being able to construct good, elegant, routines (or sentences) in that language.

▲ hamdingers 5 days ago | parent | prev | next [-]

> If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself?

Reading code doesn't mean you can write it, as any programmer will tell you.

If I want to know if a string in ruby begins with another string, is the method starts_with or start_with or startwith like python or is it like perl where I have to use some completely different method? I don't know, better google it.

But if I'm reading and see `str.start_with?("https://")` I know instantly what it's doing.

▲ ponector 5 days ago | parent | prev | next [-]

That is what I observe at work: people who heavily use LLM in their coding don't read, review and test their code, pushing this work to teammates and testers.

Great skill multiplier, right?

▲ nchmy 5 days ago | parent | prev [-]

are you advocating for not having code reviews...? Just straight force push to main?

▲ AdieuToLogic 5 days ago | parent | next [-]

> are you advocating for not having code reviews...? Just straight force push to main?

No, not at all.

What I was speaking about was if the person to whom I replied is not a s/w engineer, then perhaps a better contribution to their project would be to define requirements in the form of RSpec specifications (since Ruby is in use) and allow the engineering team to satisfy them as they determine appropriate.

I have seen product/project managers attempt to "contribute" to a development effort much like what was described. Usually there is a power dynamic such that engineers cannot overtly tell the manager(s), "you define the 'what' and we will define the 'how'." Instead, something like the PR flow described is grudgingly accepted and then worked around.

▲ marcus_holmes 4 days ago | parent [-]

I'm the person you replied to. I've been developing software for >30 years now. In this case I have domain knowledge, architecture knowledge, experience with the type of systems we're building, but not the language (it's an odd situation). I'm using an LLM to avoid the weeks/months of getting up to speed with Ruby myself, and it appears to be working.

To address your comments about PRs: without the LLM I would be submitting shitty PRs with lots of basic Ruby mistakes. With the LLM I am submitting PRs that are on a par with everyone else's PRs (Ruby has many ways of doing the same thing, so most suggested changes to my PRs are the usual "or you could do it this way and that might be more elegant" discussions). It's not that the rest of the team are picking up my slack, it's actually better this way.

I was a bit sceptical when I started, and like you I assumed that I would end up having to learn Ruby, but in fact it's working well.

▲ AdieuToLogic 3 days ago | parent [-]

> I'm the person you replied to. I've been developing software for >30 years now.

As a s/w engineer with 30+ years of experience, I assume you agree that in order to become proficient in a programming language one must go through the process of learning its syntax and idioms. Yet when you say:

  I'm using an LLM to avoid the weeks/months of getting up
  to speed with Ruby myself, and it appears to be working.

This contradicts my understanding of what you originally stated:

  ... I don't need to learn Ruby to write acceptable-level code [0]

  [0] acceptable-level as defined by the rest of the team

Regarding:

  To address your comments about PRs: without the LLM I
  would be submitting shitty PRs with lots of basic Ruby
  mistakes.

IMHO, this is how s/w engineers learn quickest assuming an environment which supports an open learning process. There are no shortcuts to achieving understanding.

Maybe we just have very different opinions on the learning process and/or maybe I lack the context required to understand your situation. In any event, best of luck in your endeavours.

EDIT:

For some reason I cannot reply to your reply to this message in order to share this resource:

  Why’s (Poignant) Guide to Ruby[0]

I found it a very entertaining read and one of the best language tutorials I have ever found. Hopefully you find it as useful as well.

0 - https://poignant.guide/book/chapter-1.html

▲ marcus_holmes 3 days ago | parent [-]

Thanks, yeah, it's interesting. We're not through the whole project, so it may still mess up ;) But so far so good.

I think the key point here is that I'm not trying to learn Ruby. We're trying to get a single project done in Ruby. I'm the best person to do the project, Ruby is the best language to do it in, but I don't know Ruby.

If I was trying to learn Ruby, this is not the way I'd do it, and I'd go up the learning curve as normal, writing all those shitty PRs and making all the mistakes as normal. As you say, there are no shortcuts to achieving understanding.

	▲	AdieuToLogic 3 days ago \| parent [-]
		And the plot thickens... :-) Now I can reply to your message (can't say why I couldn't before, so moving on). Below is the added content in the event you were unaware of the previous message edit. In addition are three other resource links which may be beneficial to your project. The last one, nokogiri[3], is least likely to be applicable in general but is simply too cool to omit. `Why’s (Poignant) Guide to Ruby[0]` I found it a very entertaining read and one of the best language tutorials I have ever found. Hopefully you find it as useful as well. 0 - https://poignant.guide/book/chapter-1.html 1 - https://www.rubyguides.com/2018/07/rspec-tutorial/ 2 - https://github.com/cucumber/cucumber-ruby 3 - https://nokogiri.org/

▲ cyphar 5 days ago | parent | prev [-]

Code reviews (especially internal ones) generally assume that the person writing the original code has an idea of what they are doing and are designed to catch mistakes that humans might make. Just because they probably work to improve codebases with human submissions doesn't mean that they are good enough filter for LLM-generated code that the submitter doesn't sufficiently understand and has submitted without their own review. Same goes for CI and testing.

This reminds of some of the comments made by reviewers during the infamous Schön scientific fraud case. The scientific review process is designed to catch mistakes and honest flaws in research. It is not designed to catch fraud, and the evidence shows that it is bad at it.

Another applicable example would be the bad patches fiasco with the Linux kernel. (And there is going to be a session at the upcoming maintainers' summit about LLM-generated kernel patches.)