[HN Gopher] NSFW Acronyms for Programmers (Free eBook)
       ___________________________________________________________________
        
       NSFW Acronyms for Programmers (Free eBook)
        
       Author : fristovic
       Score  : 40 points
       Date   : 2026-01-04 18:49 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | CharisZ112 wrote:
       | I genuinely chuckled at the PISS one! This is very brave, not
       | sure how wide the audience for this is but I think I'll give it a
       | pass.
        
         | moron4hire wrote:
         | I got called "very brave" on Christmas Eve for walking around
         | in public with an elf hat on. What is it with this calling of
         | slightly off-kilter things "very brave" lately? Just how
         | insecure/scared are y'all expecting people to be?
        
       | sedatk wrote:
       | The book looks great actually, and I agree with the first
       | sentiment about S.H.I.T, but the author incorrectly assumes that
       | tests are used as a reliability indicator. Maybe some do use it
       | for that, but most teams don't. Tests are regression detectors.
       | Tests are there to prevent you from causing unintended behavior
       | change while changing other parts of code. Tests never tell you
       | if your code or even if your spec is reliable. They just tell you
       | that code adheres to the given spec.
       | 
       | I also dislike TDD but for a different reason: it incorrectly
       | assumes that spec comes before code. Writing code is a design act
       | too. I talk about that in Street Coder.
        
         | fristovic wrote:
         | I'm sorry I was not familiar with your game sir... Street Coder
         | was never on my radar but right now it is the first thing I'm
         | buying when the learning budget at my company resets in a
         | couple of days!
        
         | rhdunn wrote:
         | I have a pragmatic approach to TDD, i.e. it doesn't practically
         | matter if you write the code or tests first as long as the
         | relevant code has tests:
         | 
         | 1. write the test code first (possibly with a skeleton
         | implementation) if you want to get an idea/feel for how the
         | class/code is intended to be used;
         | 
         | 2. write the code first if you need to;
         | 
         | 3. ensure that you have at least one test at the point where
         | the code is mimimally functional.
         | 
         | More generally:
         | 
         | 1. don't aim for 100% code coverage (around 80-90% should be
         | sufficient);
         | 
         | 2. test a representative example and appropriate boundary
         | conditions;
         | 
         | 3. don't mock classes/code you control... the tests should be
         | as close to the real thing as possible, otherwise when the
         | mocked code changes your tests will break and/or not pick up
         | the changes to the logic -- Note: if wiring up service classes,
         | try and use the actual implementations where possible;
         | 
         | 4. use a fan in/out approach where relevant... i.e. once you
         | have tests for various states/cases in class A (e.g. lexing a
         | number, e.g. '1000', '1e6', '1E6') you only need to test the
         | cases that are relevant to class B (e.g. token types, not
         | lexical variants, e.g. integer/decimal/double);
         | 
         | 5. test against publically accessible APIs, etc... i.e.
         | wherever possible, don't test/access internal state; look
         | for/test publically visible behaviour (e.g. don't check that
         | the start and end pointers are equal, check that is_empty() is
         | true and length() is 0) -- Note: testing against internals is
         | subject to implementation changes whereas public API changes
         | should be documented/properly versioned.
        
         | d-lisp wrote:
         | Businesses do business; but there are endavours to make tests
         | be reliability indicators and in some (critical) domains you do
         | write them to perform such a thing. write tests the way test-
         | theory intended; as formal verification.
         | 
         | There is software for which writing code is a design act, and
         | there is software for which you write specs before anything. I
         | don't know if a) they are the same, b) they are different, c)
         | one is better than the other.
        
       | ctoth wrote:
       | Can we please finetune Claude on the S.H.I.T. chapter?
        
         | fristovic wrote:
         | Well it's out there now. Hope it gets picked up with the next
         | scrape run, lol
        
         | piskov wrote:
         | Something like this?
         | 
         | https://github.com/buyukakyuz/corroded#note-for-llms
        
       | threeducks wrote:
       | Did you have to use any special prompts when using LLMs for
       | writing assistance, or did it just work?
        
         | fristovic wrote:
         | GPT-5.2 was not out at the time this was finished
         | unfortunately...but, GPT-4o mini was used throughout in order
         | to make the points in the book "hit" a little better. See - I'm
         | not a native english speaker, so making something "sound" the
         | way it sounds in my native language is hard, so I felt AI could
         | help reasonably well with that in a book that is supposed to
         | feel very opinionated.
         | 
         | But if you are insinuating AI made all this up on it's own, I
         | have to disappoint you. My points and my thoughts are my own
         | and I am a very human.
        
           | threeducks wrote:
           | > But if you are insinuating AI made all this up on it's own,
           | I have to disappoint you.
           | 
           | No worries, I am not a native English speaker myself. I was
           | genuinely interested in whether commercial LLMs would use
           | "bad" words without some convincing.
        
             | fristovic wrote:
             | Oh, it was a hassle for sure! It kept rewriting the
             | sentences I fed to it, trying to style them properly and it
             | kept throwing out words and changing the rebellious tone I
             | wanted in the book. It was worth it for some pieces, they
             | really became more punchy and to the point, but for others
             | looking back at it - I could have just saved the time and
             | just published it as-is. So it's a medium success for me.
        
               | threeducks wrote:
               | That was my experience as well. Sometimes, LLMs were a
               | big help, but other times, my efforts would have been
               | better spent writing things myself. I always tell myself
               | that experience will make me choose correctly next time,
               | but then a new model is released and things are different
               | yet again.
        
             | dizhn wrote:
             | Try some Made In PRC models. They do not give a shit.
        
               | threeducks wrote:
               | I have tried a few Qwen-2.5 and 3.0 models (<=30B), even
               | abliterated ones, but it seems that some words have been
               | completely wiped from their pretraining dataset. No
               | amount of prompting can bring back what has never been
               | there.
               | 
               | For comparison, I have also tried the smaller Mistral
               | models, which have a much more complete vocabulary, but
               | their writing sometimes lacks continuity.
               | 
               | I have not tried the larger models due to lack of VRAM.
        
       | CoreTester223 wrote:
       | I got trough a few chapters and I have to say this book is
       | unexpectedly easy to read! Examples can a bit wonky at some
       | spots, but the overall theme and feel seems very refreshing to
       | me! I will come back to it in the morning, but I've got to say -
       | Nice job!
        
         | fristovic wrote:
         | I'm glad to hear that! Looking forward to a full review!
        
       | fusslo wrote:
       | Am I crazy to distrust a .pdf and .epub only option hosted on
       | github in 2026?
       | 
       | The author looks legit - or at least has contributions for over a
       | year.
       | 
       | But github is free & idk if they scan user repos for malware
       | 
       | Are .pdfs and .epub safe these days?
        
         | fristovic wrote:
         | You are not crazy, you make a valid point. But the truth is -
         | the author (me) - was just lazy to upload it to something else
         | and just wanted it published. I promise you I'm not trying to
         | hack you :)
        
           | fusslo wrote:
           | lmao, ok ty for the promise. good enough for me!
           | 
           | Ty for sharing your book, it's pretty fun
        
         | SunlitCat wrote:
         | How about uploading them on mega, dropbox, mediafire or some
         | quickly done wix page? :D
        
           | fristovic wrote:
           | I can't do that from the terminal in 3 lines now, can I? ;)
        
         | threeducks wrote:
         | > Are .pdfs and .epub safe these days?
         | 
         | Depends on the viewer. Acrobat Reader? Probably not. PDF.js in
         | some browser? Probably safe enough unless you are extremely
         | rich.
        
         | rfl890 wrote:
         | .pdf files opened in a browser are safe for the most part.
        
       ___________________________________________________________________
       (page generated 2026-01-04 23:00 UTC)