4 ms·
Unless the plan is to quickly produce a prototype that will be mostly thrown away, any code that gets into the product is going to generate far more work mainta
by not2b 2y ago
Unless the plan is to quickly produce a prototype that will be mostly thrown away, any code that gets into the product is going to generate far more work maintaining it over the lifetime of a product than the cost to code it in the first place.
As a reviewer I'd push back, and say that I'll only be able to approve the review when the junior programmer can explain what it does and why it's correct. I wouldn't reject it solely because chatgpt made it, but if the checkin causes breakage it normally gets assigned back to the person who checked it in, and if that person has no clue we have a problem.
- KronisLV 2y ago> I wouldn't reject it solely because chatgpt made it, but if the checkin causes breakage it normally gets assigned back to the person who checked it in, and if that person has no clue we have a problem. That's a fair point, but regardless of who wrote the code (or what tools were used) it should also probably be as clear as possible to everyone who reads it, because chances are that at some point that person will be elsewhere and some other person will have to take over.
- not2b 2y agoTrue, but you're talking about the difference between "only one person understands this, that's a risk!" and "zero people understand this".
- solatic 2y agoNot being willing to throw out bad/unused features is a different trap that organizations fall into. The amount of work that goes into, shall we say fortifying the foundations of a particular feature, ideally should be proportional to how much revenue that feature is responsible for. Test code also has to be maintained, and increasing the maintenance burden on something that has its own maintenance burden when customers don't even like it is shortsighted at the very least.