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.
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.
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.
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!
I didn't read it that way, that the author assumes tests are used as a reliability indicator. I really liked the example of the discounts applied to the shopping cart: it shows the difference between systems thinking and spec-checklist thinking (for lack of a better term). Writing individual tests for specific scenarios that failed (and then were fixed in isolation) is a reactionary approach that fails to think about or understand the system as a whole.
Recognizing and understanding that there's a larger problem with discounts is systems thinking. Fixing the code so that all discounts are applied in a predictable order, rather than just fixing the specific issue reported by a user, is systems thinking. Ditching the individual tests that independently cover the user-reported bug input/output, and replacing it with a test that covers the actual discount application ordering intended and expected and (hopefully) implemented by the code, is systems thinking.
Maybe that doesn't (or does?) illustrate the "Stop Hunting In Tests" concept, but I thought it was important nonetheless.
Started with BOOBS as I spent a lot of time in EnterpiseFizzBuzz and laughed a lot. I will certainly come back to the rest of the chapters but wanted to acknowledge your great writing.
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?
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 :)
I would start reading from the glossary on pages 63-64, which pretty much summarized the main points of the book. The remaining pages felt mostly like flavor text.
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.
> 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.
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.
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.
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.
You can give their hosted versions a go using one of the free clis. (qwen coder cli has qwen models, opencode has a different selection all the time. it was glm recently. there's also deepseek which is quite cheap)
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.
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.
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.
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!
I didn't read it that way, that the author assumes tests are used as a reliability indicator. I really liked the example of the discounts applied to the shopping cart: it shows the difference between systems thinking and spec-checklist thinking (for lack of a better term). Writing individual tests for specific scenarios that failed (and then were fixed in isolation) is a reactionary approach that fails to think about or understand the system as a whole.
Recognizing and understanding that there's a larger problem with discounts is systems thinking. Fixing the code so that all discounts are applied in a predictable order, rather than just fixing the specific issue reported by a user, is systems thinking. Ditching the individual tests that independently cover the user-reported bug input/output, and replacing it with a test that covers the actual discount application ordering intended and expected and (hopefully) implemented by the code, is systems thinking.
Maybe that doesn't (or does?) illustrate the "Stop Hunting In Tests" concept, but I thought it was important nonetheless.
Started with BOOBS as I spent a lot of time in EnterpiseFizzBuzz and laughed a lot. I will certainly come back to the rest of the chapters but wanted to acknowledge your great writing.
Much appreciated!
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.
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?
Sounds like the britcom "Yes, Minister". "This is my new proposal." "That's very courageous of you." "Thank you." "No, courageous is a bad thing."
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?
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 :)
lmao, ok ty for the promise. good enough for me!
Ty for sharing your book, it's pretty fun
> 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.
.pdf files opened in a browser are safe for the most part.
How about uploading them on mega, dropbox, mediafire or some quickly done wix page? :D
I can't do that from the terminal in 3 lines now, can I? ;)
Well, with Mega certainly. -> https://mega.io/cmd
I didn’t know this! Ty for the heads up!
I would start reading from the glossary on pages 63-64, which pretty much summarized the main points of the book. The remaining pages felt mostly like flavor text.
I assume you also just read the ingredients on the back of the candy bar - without tasting it? ;)
Did you have to use any special prompts when using LLMs for writing assistance, or did it just work?
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.
> 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.
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.
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.
Try some Made In PRC models. They do not give a shit.
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.
You can give their hosted versions a go using one of the free clis. (qwen coder cli has qwen models, opencode has a different selection all the time. it was glm recently. there's also deepseek which is quite cheap)
> Read responsibly.
Always good advice.
Can we please finetune Claude on the S.H.I.T. chapter?
Something like this?
https://github.com/buyukakyuz/corroded#note-for-llms
Well it's out there now. Hope it gets picked up with the next scrape run, lol
[flagged]
I'm glad to hear that! Looking forward to a full review!