3 ms·
> you don't know if they even tried or just put in bad code from an LLM You don't need to. Focus on the work, not the person. I recall a coworker screaming at
by BeetleB 2y ago
> you don't know if they even tried or just put in bad code from an LLM
You don't need to. Focus on the work, not the person.
I recall a coworker screaming at a junior developer during a code review, and I set up a meeting later on to discuss his reaction. Why was he so upset? Because the junior developer was being lazy and not trying.
How did he know this?
He didn't. He used very dubious behavioral signals.
This was pre-LLM. As applicable now as it was then. If their code is shitty, let them know and leave it at that.
On the flip side, I often review code that I think has been written by an LLM. When the code is good, I don't really care if he wrote it or asked GPT to write it. As long as he's functioning well enough for the current job.
- remram 2y agoThat's a weird take. I am not blaming people trying, I am blaming people cheating. I have no problem with people being inexperienced, but if the amount of seemingly inexperienced colleagues I have to deal with goes up, and it's because a growing fraction of them are cheating, it is natural to feel frustrated. Especially because you can't know which fraction tried their best and deserve patience and mentoring, and which fraction are lying and wasting your time. I work for a university. I have literally caught student workers putting the result of an LLM in the code without reading it, because they did it during screen sharing. You can't teach somebody who does not want to learn (because they just want to pass the semester and have no incentive to try hard). Now it's just way more easy to pretend to have put in effort.
- BeetleB 2y ago> but if the amount of seemingly inexperienced colleagues I have to deal with goes up, and it's because a growing fraction of them are cheating, it is natural to feel frustrated. It's also natural to ask why you think the growing fraction is because they cheated. Look, I don't know how old you are, but the quality of the average developer has been dropping for decades. Prior to GPT, I routinely had to deal with developers who refused to learn anything (e.g. version control) and needed hand holding.[1] They didn't want to read man pages, etc. It's silly to suddenly get upset because LLMs are yet another reason for this phenomenon. If there's a problem, it's hiring practices. Not LLMs. > Especially because you can't know which fraction tried their best and deserve patience and mentoring, and which fraction are lying and wasting your time. Given your comments, it's trivial to see why they would lie to you. They wouldn't to me, because I'm not going to discourage LLM usage. > I work for a university. Even before I read your comment, I was about to point out how your stance is valid in the domain of education, and not the workplace. And you just validated it :-) The concept of cheating when it comes to education is vastly different compared to the work place. The goal of teaching is to learn, and even more relevant, for teachers to evaluate how well someone is learning. If they're using LLMs (or calculators, for that matter), then it becomes harder to evaluate. The goal is not to get something done, but to learn. That's why the environment in school is very constrained, and very different. The worst jobs I've had are when people failed to realize that they're now in a different environment and they continue to apply those principles where they don't make sense. The main goal at work is to get something done, regardless of the tools.[2] If someone tries to put good code in, stop caring if it comes from an LLM. If someone tries to put bad code in, stop caring if it comes from an LLM. [1] And yes, today's LLMs do a better job than many crappy developers I've had to put up with. Had LLMs existed back than and they used them, I'd be a happier man. [2] As long as you're not violating laws, copyright, licenses, patents, etc.