• 1 Post
  • 567 Comments
Joined 1 year ago
cake
Cake day: July 25th, 2024

help-circle

  • I don’t think that’d be much good when the way the specs are written are not based purely on technical merits. We also aren’t paid to test hardware - we have hardware because we develop software to test hardware on. Knowing how to navigate those waters is the key skill. Once I’ve got a solution that’ll work getting it implemented is relatively trivial as our approach is extremely atomic.

    In general what you describe sounds like a tremendous amount more overhead than we currently have for little to no gain. What I could do with is a few more engineers that I could train up to have sufficient contextual knowledge, not another junior to babysit. I trained one up and he’s tremendously useful - apart from when he leans too heavily on LLMs. That cost a side project two months of unnecessary faff and sapped team morale massively in the process. I ended up dragging the damn thing over the finish line after he refactored it into something that was exhausting to work with.


  • Unless it’s the most rudimentary logic I tend to have to hold the LLM’s hand through the entire design. Sometimes that involves breaking the damn thing’s fingers.

    I mostly use them to write stuff that I can do but hate because the syntax is a faff (argparsers, docstrings, shite like that). There’s just too much contextual knowledge needed for them to be much use with the codebase I work with, much of which is not in the codebase so much as in the metatextual knowledge needed. I write a lot of software for testing hardware and there’s a needle that has to be threaded - the specifications are not bulletproof, the hardware being tested failing may be the desired outcome (so code that passes on it is inherently wrong), and there are various limitations and priorities that inform test approach.

    The actual code I write is fairly minimal but the knowledge needed to write it is extensive.

    Occasionally I’ll take on side projects at work to get my hands dirty on something more involved but simpler.











  • Flamekebab@piefed.socialtoMicroblog Memes@lemmy.worldOld cheddar
    link
    fedilink
    English
    arrow-up
    38
    arrow-down
    1
    ·
    7 days ago

    When I was growing up my father had a wooden mallet he’d made himself. He still has it now, but he had it then too.

    It was called a “dongy knocker”.

    The thing is, there’s contradictory stories for why it was called that. On the one hand when I looked it up, it seems like it’s an obscure antipodean term. My father was in rural New Zealand in the '70s and may well have picked it up the term over there. This is reinforced by the name of a weapon in Furiosa: A Mad Max Saga, the Bommy Knocker, and threads like this.

    However it’s also possible I named it, according to a book someone published about working for my father (in the anecdote someone had damaged the fabled mallet and was rather worried about what they’d done!). I’m not worried about doxing myself - I’ve been using this username since 2002 and have clothes with it on. It’s not a secret who I am.


  • When I was a kid, we had a class on Logo in, I think, 4th grade? (It was either that or 5th grade.) It wasn’t particularly hard to make various geometric drawings with it, but it also wasn’t clear how to use it to do anything beyond that.

    This sums up my early experiences with programming. It felt like either pointless flashing lights or building the universe from scratch. These days I have lots of tasks that programming is useful for but for the longest time no sources I encountered ever seemed to talk about what practical use I could put the concepts to.

    Telling me about for and while loops and various other things felt like learning by rote and I never got very far. It wasn’t until my late 20s when I had a load of tedious administrative tasks to do that I was able to get my teeth into programming.