I’m dealing with a new service written by someone who extensively cut and pasted from ChatGPT, got it to “almost done – just needs all the operational excellence type stuff to put it into production”, and left the project.
Honestly we should have just scrapped it and rewritten it. It’s barely coherent and filled with basic bugs that have wasted so much time.
I feel maybe this style of sloppy coding workflow is better suited to front end coding or a simple CRUD API for saving state, where you can immediately see if something works as intended, than backend services that have to handle common sense business logic like “don’t explode if there is no inventory” and etc.
For this dev, I think he was new to the language and got in a tight feedback loop of hacking together stuff with ChatGPT without trying to really understand each line of code. I think he didn’t learn as much as if he would have applied himself to reading library and language documentation, and so is still a weak dev. Even though we gave him an opportunity to grow with a small green field service and several months to write it.
So cool, thanks. As a kid I spent so much time in DEBUG, stepping through DOS’s executables, and especially the Interrupt handlers. It’s so neat to see the actual source code-- way easier to read and follow. I didn’t know it was all written in assembly, from within Debug it sometimes seemed so messy and convoluted that I just assumed more was written in C.