Comment by apothegm

Comment by apothegm 3 months ago

So much this. The AI takes care of the tedious line by line what’s-the-name-of-that-stdlib-function parts (and most of the tedious test-writing parts) and lets me focus on the interesting bits like what it is I want to build and how the pieces should fit together. And debugging, which I find satisfying.

Sadly, I find it sorely lacking at dealing with build systems and that particular type of boilerplate, mostly because it seems to mix up different versions of things too much and gives you totally broken setups more often than not. I’d just as soon never deal with the he’ll that is front end build/lint/test config again.

dxroshan 3 months ago

> The AI takes care of the tedious line by line what’s-the-name-of-that-stdlib-function parts (and most of the tedious test-writing parts)

AI generated tests are a bad idea.

Reply View 3 replies

simonw 3 months ago

AI generated tests are genuinely fantastic, if you treat them like any other AI generated code and review them thoroughly.
I've been writing Python for 20+ years and I still can't use unittest.mock without looking up the details every time. ChatGPT and Claude are great at that, which means I use it more often because I don't have to deal with the frustration of figuring it out.

Reply View | 0 replies
apothegm 3 months ago

Just as with anything else AI, you never accept test code without reviewing it. And often it needs debugging. But it handles about 90% of it correctly and saves a lot of time and aggravation.

Reply View | 0 replies
otabdeveloper4 3 months ago

Well, maybe they just need X lines of so-called "tests" to satisfy some bullshit-job metrics.

Reply View | 0 replies

tcfhgj 3 months ago

Aren't stdlib functions the ones you know by heart after a while anyways?

Reply View 7 replies

apothegm 3 months ago

Depends on the language. Python for instance has a massive default library, and there are entire modules I use anywhere from one a year to once a decade —- or never at all until some new project needs them.

Reply View | 0 replies
danielbln 3 months ago

Not everyone works in a single language and/or deep in some singular code base.

Reply View | 5 replies
- BigJono 3 months ago
  
  Gee do you think maybe that's why all our software sucks balls these days?
  
  Reply View | 2 replies
  
  Philpax 3 months ago
  
  No? Of all the reasons software sucks, multidisciplinary programmers are unlikely to be near the top.
  
  Reply View | 1 reply
  
  jajko 3 months ago
  
  They certainly are for me, working but horribly designed java projects done by plsql devs were a proper eyeballs bleeding long into the night.
  Absolutely 0 framework or libs, nothing even for logging. Code architecture that would be left in the dust by most university semester projects.
  This is how plsql codebases look, but boy Java (and rest of the world) moved quite far since 1995.
  
  Reply View | 0 replies
- skydhash 3 months ago
  
  I struggle to think how one person is supposed to interact with that many languages on a daily (or even weekly) basis.
  I’ve been on projects with multiple languages, but the truly active code was done in only two. The other languages were used in completed modules where we do routine maintenance and rare alterations.
  
  Reply View | 1 reply
  
  simonw 3 months ago
  
  "I struggle to think how one person is supposed to interact with that many languages on a daily (or even weekly) basis."
  LLMs. I've expanded the circle of languages I use on a frequent basis quite dramatically since I started leaning on LLMs more. I used to be Python, SQL and JavaScript only. These days I'm using jq, AppleScript, Bash, Go, awk, sed, ffmpeg and so many more.
  I used to avoid infrequently used DSLs because I couldn't hold them in my memory. Now I'll happily use "the best tool for the job" without worrying about spinning up on all the details first.
  
  Reply View | 0 replies