4 ms·

AI is just another tool. A pretty good one. And there is a skill to using it efficiently. If you ask it dumb questions, you will get dumb answers. Garbage i

AI is just another tool. A pretty good one. And there is a skill to using it efficiently. If you ask it dumb questions, you will get dumb answers. Garbage in, garbage out. I am a software developer and I hire devs as well. If somebody is ignorant of AI or refuses to use it, that is hard pass for me. It is not all that different from an accountant not wanting to use computers. Sure, you could still do some work. But, you will not be competitive.

kachapopopow 2y ago
Some people are just really good without AI so I wouldn't immediately hard pass on them.
- jillesvangurp 2y ago
  They are still going to be slow doing things manually.
  - kachapopopow 2y ago
    You write automation tools for that.
- kolinko 2y ago
  Perhaps if they are super specialised in one narrow niche. The moment they need to write code in a new language/framework/algorirhms/domain, they benefit tremendously from chatgpt. Or even just redacting their documentation entries. I’d say the main devs that don’t benefit is mid-level ones. Good enough to do some programming, but not good enough to figure out how to benefit from gpt.
  - kachapopopow 2y ago
    AI's are currently not helpful since they make shit up when you ask things about documentation or mix and match things from different libraries. Normal search is still the best for docs. Anything javascript related it's probably fine tho.
  - omg7584 2y ago
    It's interesting most of you equate being "good" with being able to close a lot of tickets. I'd take a collegue with knowledge of the fundamentals and that knows how to ask the right questions - and when not to - over "produces a metric shit ton of code, but when asked doesn't actually know anything". The first one might be slow and might be editing his, horrors or horros, documentation entries by hand, but that's because he is thinking and refining while he is doing it. He is not an automaton spitting out "work units". After some contemplation he will wipe the whole project off the table, because in the grand scheme of things it doesn't pan out while collegue number two was busy generation a metric shit-ton of work units and being happy about his productivity. No LLM will tell you that or more specifically, no LLM will tell you that if you don't know what to ask for in the first place.
u20241003 2y ago
Damn, I would be sending AI-generated pull-requests your way all day! Closing tickets left and right.
- jillesvangurp 2y ago
  As long as those are good pull requests, more power to you. Why aren't you?
  - EraYaN 2y ago
    Mostly because most project ban you if you start auto generating PRs and patches or even issues. Most LLMs are just not good enough yet. We have seen this with curl and a bunch of other projects where LLMs were used to do security issue reporting and well the maintainers were not too happy talking to a bot that didn't know what the hell it was doing. It's essentially a DoS attack on the maintainers.
jillesvangurp 2y ago
Exactly. I expect people to know, be proficient with, and use all relevant tools available to them. Including AI; but not just AI. There are a lot of people trying to argue why they don't want/need to use certain tools. A job interview would be the wrong place to have that argument. A good, open interview question these days would be asking candidates how they are using AI in their work and what challenges they are facing with it. Say, you are a python developer and you are working on some FastAPI rest service. Do you 1) ask chat GPT to generate documentation for your API. 2) do this by hand. or 3) routinely skip that sort of thing. 1) would be the correct answer. 2) would be you being inefficient and slow 3) would be lazy. It takes 1 minute to generate perfectly usable documentation. Tweak it a little if you need to and job done. Bonus points for generating most/all of the endpoints. I did that a few weeks ago. And the tests that prove it works. And the documentation. And the bloody README as well. Slightly tedious and you need to be good at prompting to get what you need. But I managed. Artisanal software is not going to be a thing for very long. I expect people to get standard stuff like that out of the way efficiently; not to waste days doing things manually. I would also encourage candidates to use chat gpt during coding tests. If I actually believed in those, which I don't. I'd be more interested in their ability to understand the challenge then to produce a working solution from memory. Use tools for that.
- mschuster91 2y ago
  > Bonus points for generating most/all of the endpoints. Swagger has solved that one for years now. In any case I think it's foolish to have multiple competing "sources of truth"... in the worst case you have stuff written on your website/Confluence/wiki, some manually written docs on Dockerhub, a README in the repository, an examples folder in the repository, Javadoc-based comments on classes and functions, Swagger docs (semi-)autogenerated from these, inline documentation in the code, years worth of shit on StackOverflow and finally whatever garbage ChatGPT made out of ingesting all of that. And (especially in the Javascript world) there's so much movement and breakage that all these "sources of truth" are outdated - especially StackOverflow and ChatGPT - which leaves you as the potential user of a library/API often enough with no other choice than to delve deep into the code, made even messier by the intricacies of build systems, bundlers and include/module systems (looking at you Maven/Gradle/Java Modules and webpack/rollup/npm/yarn/AMD/CommonJS/ESM). The worst nightmare is "examples" that clearly haven't been run in years, otherwise the example would have reflected a breaking API change whose commit is five years ago. That's a sure way of sending your users into rage fits. IMHO, there is only one way: your "examples" should be proper unit/integration/e2e tests (that way you can show your users how you intend for subscribers to use your interface, and you'll notice when your examples are broken because they are literally your tests!), and your documentation (no matter the format, be it HTML, Markdown or Swagger) should all be auto-generated from in-code Javadoc/whatever. Inline code should be reserved for stuff that's only needed to be known for someone intending to work on the actual library, to describe why you took a certain way of implementing a Thing (say, to work around some sort of deficiency) - think of the infamous "total hours wasted here" joke [1]. My to-go example, even if it is not perfect (the website is manually maintained, but the maintainers are doing a fucking good job at that!) is the Symfony PHP framework. With the exception of the security stack (that one is an utter, utter nightmare to keep up with), their documentation is excellent, legible, and easy to understand, and the examples they provide on usage are clear to the point. Even if you haven't worked with it for a year or two, it's so easy to get up to speed again. [1] https://nickyreinert.medium.com/ne-13-total-hours-wasted-here-42-175cb1d49728 https://nickyreinert.medium.com/ne-13-total-hours-wasted-her...

kachapopopow 2y ago

Some people are just really good without AI so I wouldn't immediately hard pass on them.

jillesvangurp 2y ago
They are still going to be slow doing things manually.
- kachapopopow 2y ago
  You write automation tools for that.
kolinko 2y ago
Perhaps if they are super specialised in one narrow niche. The moment they need to write code in a new language/framework/algorirhms/domain, they benefit tremendously from chatgpt. Or even just redacting their documentation entries. I’d say the main devs that don’t benefit is mid-level ones. Good enough to do some programming, but not good enough to figure out how to benefit from gpt.
- kachapopopow 2y ago
  AI's are currently not helpful since they make shit up when you ask things about documentation or mix and match things from different libraries. Normal search is still the best for docs. Anything javascript related it's probably fine tho.
- omg7584 2y ago
  It's interesting most of you equate being "good" with being able to close a lot of tickets. I'd take a collegue with knowledge of the fundamentals and that knows how to ask the right questions - and when not to - over "produces a metric shit ton of code, but when asked doesn't actually know anything". The first one might be slow and might be editing his, horrors or horros, documentation entries by hand, but that's because he is thinking and refining while he is doing it. He is not an automaton spitting out "work units". After some contemplation he will wipe the whole project off the table, because in the grand scheme of things it doesn't pan out while collegue number two was busy generation a metric shit-ton of work units and being happy about his productivity. No LLM will tell you that or more specifically, no LLM will tell you that if you don't know what to ask for in the first place.

u20241003 2y ago

Damn, I would be sending AI-generated pull-requests your way all day! Closing tickets left and right.

jillesvangurp 2y ago
As long as those are good pull requests, more power to you. Why aren't you?
- EraYaN 2y ago
  Mostly because most project ban you if you start auto generating PRs and patches or even issues. Most LLMs are just not good enough yet. We have seen this with curl and a bunch of other projects where LLMs were used to do security issue reporting and well the maintainers were not too happy talking to a bot that didn't know what the hell it was doing. It's essentially a DoS attack on the maintainers.

jillesvangurp 2y ago

Exactly. I expect people to know, be proficient with, and use all relevant tools available to them. Including AI; but not just AI. There are a lot of people trying to argue why they don't want/need to use certain tools. A job interview would be the wrong place to have that argument. A good, open interview question these days would be asking candidates how they are using AI in their work and what challenges they are facing with it. Say, you are a python developer and you are working on some FastAPI rest service. Do you 1) ask chat GPT to generate documentation for your API. 2) do this by hand. or 3) routinely skip that sort of thing. 1) would be the correct answer. 2) would be you being inefficient and slow 3) would be lazy. It takes 1 minute to generate perfectly usable documentation. Tweak it a little if you need to and job done. Bonus points for generating most/all of the endpoints. I did that a few weeks ago. And the tests that prove it works. And the documentation. And the bloody README as well. Slightly tedious and you need to be good at prompting to get what you need. But I managed. Artisanal software is not going to be a thing for very long. I expect people to get standard stuff like that out of the way efficiently; not to waste days doing things manually. I would also encourage candidates to use chat gpt during coding tests. If I actually believed in those, which I don't. I'd be more interested in their ability to understand the challenge then to produce a working solution from memory. Use tools for that.

mschuster91 2y ago
> Bonus points for generating most/all of the endpoints. Swagger has solved that one for years now. In any case I think it's foolish to have multiple competing "sources of truth"... in the worst case you have stuff written on your website/Confluence/wiki, some manually written docs on Dockerhub, a README in the repository, an examples folder in the repository, Javadoc-based comments on classes and functions, Swagger docs (semi-)autogenerated from these, inline documentation in the code, years worth of shit on StackOverflow and finally whatever garbage ChatGPT made out of ingesting all of that. And (especially in the Javascript world) there's so much movement and breakage that all these "sources of truth" are outdated - especially StackOverflow and ChatGPT - which leaves you as the potential user of a library/API often enough with no other choice than to delve deep into the code, made even messier by the intricacies of build systems, bundlers and include/module systems (looking at you Maven/Gradle/Java Modules and webpack/rollup/npm/yarn/AMD/CommonJS/ESM). The worst nightmare is "examples" that clearly haven't been run in years, otherwise the example would have reflected a breaking API change whose commit is five years ago. That's a sure way of sending your users into rage fits. IMHO, there is only one way: your "examples" should be proper unit/integration/e2e tests (that way you can show your users how you intend for subscribers to use your interface, and you'll notice when your examples are broken because they are literally your tests!), and your documentation (no matter the format, be it HTML, Markdown or Swagger) should all be auto-generated from in-code Javadoc/whatever. Inline code should be reserved for stuff that's only needed to be known for someone intending to work on the actual library, to describe why you took a certain way of implementing a Thing (say, to work around some sort of deficiency) - think of the infamous "total hours wasted here" joke [1]. My to-go example, even if it is not perfect (the website is manually maintained, but the maintainers are doing a fucking good job at that!) is the Symfony PHP framework. With the exception of the security stack (that one is an utter, utter nightmare to keep up with), their documentation is excellent, legible, and easy to understand, and the examples they provide on usage are clear to the point. Even if you haven't worked with it for a year or two, it's so easy to get up to speed again. [1] https://nickyreinert.medium.com/ne-13-total-hours-wasted-here-42-175cb1d49728 https://nickyreinert.medium.com/ne-13-total-hours-wasted-her...