On every large codebase I’ve worked on , updating a low level function has required more work updating the tests than updating the application using it.
Unit tests have a place, but IME are overused as a crutch to avoid writing useful bigger tests which require knowing what your app does rather than just your function.
> Integration test are slow/expensive to run compared to unit tests and reduce your iteration speed.
My unit tests might take under a second to run but they’re not the ones (IME) that fail when you’re writing code. Meanwhile, integration tests _will_ find regressions in your imperfect code when you change it. I currently use c# with containers and there’s a startup time but my integration tests still run quickly enough that I can run them 10s or hundreds of times a day very comfortably.
> If you’re doing a lot of mocking then your design is not good.
This is the “you’re holding it wrong” argument. I’ve never seen a heavily unit tested codebase that didn’t either suffer from massive mocking or wasn’t decomposed into such small blocks that they were illogically small and the mental map of the project was like drawing with sand - completely untenable.
> And only public interfaces should have testing.
This is the smoking gun in your comment - I actually disagree and think you should infer this. Services (or whatever you call them) should be tested, and low level functionality should be tested but the stuff in the middle is where you spend 80% of your time and get 10% of the benefit
> Unit tests let you change code fearlessly with instant feedback.
Sure they can add confidence in making changes. But I've seen they can also give you false confidence.
As I said, I can still assemble your perfect Lego bricks together wrong. And you can still change the public behavior while keeping your unit tests passing fine. I've seen both happen in practice.
That's why I think integration tests (or whatever you want to call them) give you more bang for your buck. They give you even greater confidence that your stuff works, and generally you can cover a lot more with far fewer tests so improves ROI.
The tradeoff is that it can take a bit longer to run.
> If you’re doing a lot of mocking then your design is not good.
If my app needs to talk to a database, store things in object store, send some messages in a message queue and so on, I can't not mock those things away if I'm to write unit tests.
They even priced it so people would avoid using it. GPT-4.5's entire function was to be the anchor of keeping OpenAI in the news, to keep up the perception of releasing quickly.
My assumption was that the pricing was because it really was that expensive for whatever reason. I'm keeping fingers crossed that they're going to do some kind of 4.5 mini at some point that will be more affordable.
You're not wrong, but that just means the <adjective> is where the bulk of information resides. The trade-off matters. Maybe it's a model with good enough quality but really cheap to serve. Maybe it's a model that only plays poker really well but sucks at everything else because it bluffs too much. Etc. etc.
But have you experienced a high flow _and_ high pressure shower head? Sooooo good.
It makes you realize a low flow/high pressure shower head is a just a bunch of little needle jets that neither feel good nor adequately cover you in a deluge of water. While better than low flow/low pressure shower heads, they are still a joke.
> a low flow/high pressure shower head is a just a bunch of little needle jets that neither feel good nor adequately cover you in a deluge of water
This is the mark of a mediocre shower head.
There’s something about Speakman shower heads that spread the individual streams in a much more satisfying way. They’re adjustable in a flexible/continuous manner, which may have something to do with it.
As for the “deluge” - you’d be surprised how well ~2gpm can rinse with the right application of pressure/spread. Maybe I’m just not as sensitive to having a few square inches of my body not covered in sheets of water? I don’t need to be luxuriated with a veritable waterfall every day.
Yeah there's ok feeling accumpuncture low pressure shower heads. But dangerously high pressure shower head is like lying on bed of nails, acquired taste, pretty incredible feeling. My mom swore it maintained her skin better, my bro science is it's also better for skin... as in it bruises it like microneedling and forces skin to rejuvenate. Have to avoid getting shot in the eye on big nozzles though.
Chime was pretty basic, but it worked, and it had a few killer features that are not available in the primary alternatives like Teams or Zoom.
Chime can autodial you when the meeting starts, which is life-changing if you haven't experienced it. We all know we have a meeting at 2pm, Outlook reminds you 15min before, but then at 1:58pm you get nerd-sniped and suddenly at 2:11pm you realize you're late! With Chime the the meeting launches automatically with Accept/Decline options, usually 1min before the meeting actually starts.
Chime also allows a meeting to start before (or even without) the host attending. How often have you had a meeting scheduled by senior leader, then they get pulled away and everyone is stuck in the virtual waiting room and end up coordinating/meeting in Slack instead? With Chime, the meeting starts anyway and the host can join when (if) they become available.
Chime was pretty basic, but it worked, and it had a few killer features that are not available in the primary alternatives like Teams or Zoom.
Chime can autodial you when the meeting starts, which is life-changing if you haven't experienced it. We all know we have a meeting at 2pm, Outlook reminds you 15min before, but then at 1:58pm you get nerd-sniped and suddenly at 2:11pm you realize you're late! With Chime the the meeting launches automatically with Accept/Decline options, usually 1min before the meeting actually starts.
Chime also allows a meeting to start before (or even without) the host attending. How often have you had a meeting scheduled by senior leader, then they get pulled away and everyone is stuck in the virtual waiting room and end up coordinating/meeting in Slack instead? With Chime, the meeting starts anyway and the host can join when (if) they become available.
My favorite feature is that the little mic next to someone's name on the roster goes red when their internet is spotty. No ambiguity on who's internet is spotty ;)
> Chime can autodial you when the meeting starts, which is life-changing if you haven't experienced it.
I wished Zoom could do this too, it's a great feature to build in to a videoconferencing product. I use a free companion app, called MeetingBar, which syncs with your calendar and has an option to join the meeting's waiting room for you.
There is an older gentleman on TikTok that does programmer humor. He has an ongoing gag this reminded me of. Microsoft PowerInterrupt. Be forced to join meetings basically. Funny it’s almost an actual real life product.
>Chime also allows a meeting to start before (or even without) the host attending. How often have you had a meeting scheduled by senior leader, then they get pulled away and everyone is stuck in the virtual waiting room and end up coordinating/meeting in Slack instead? With Chime, the meeting starts anyway and the host can join when (if) they become available.
Not sure about other videoconferencing services but I never had this issue with zoom.
I'm almost sure this is a pretty common Zoom feature, I have run into this at least once a month the last 6-7 years.
IMO, it's less a Zoom problem, and more a setting on the host's side problem. Same category as "guest cannot move a meeting invite unless explicitly allowed to" on google calendar.
Fastmail's iOS client on mobile, and their browser client on desktop.
I de-Google'd my life and Fastmail is amazing. I use their own clients because I'm creating new mail filters to sort my incoming email just often enough that I miss not being able to do that when using other clients.
The best advice I've heard about keeping a notebook or journal is "Don't overthink it, just use it."
Mix your ideas, data, todos, and everything else all together. By nature of a notebook being composed of successive pages, your notes will be naturally organized by time through append-only operations.
You'll find your important stuff by folding down the page corner, frequently flipping through it, or adding bookmarks/sticky notes; no index required.
Anything more is getting sucked into the analog version of writing your own blogging engine/static site generator.
I'm not worried about matching the build script language to the project language.
I am worried when I have to install a full dependency graph to run your build scripts...that's where things become brittle and annoying.
Python with Typer[0] and Plumbum[1] is great for quickly cranking out ergonomic build scripts, or Invoke[3] which is intended for exactly this purpose.
But then I've gone from "any Python 3.x can be used as-is" to "setup a Python venv and install these dependencies" as soon as I add any dependency :(
So you either have to constrain yourself to Argparse and Subprocess in the Python stdlib, or accept that your build scripts are a project unto themselves.
This applies similarly to Ruby, TS/JS/Node, Perl, etc.
It’s much better with uv, but nothing beats the ergonomics of running go mod tidy && go run script.go.
I wish Python had a native way to build self-contained executables like Go. The binary would be larger since it’s a dynamically interpreted language, but as long as it’s self-contained, I wouldn’t mind.
I mean... at first blush it seems like `./scriptname` which is what the `uv` shebang provides beats having to remember two commands and && them together.
Sourcing bash functions is the worst experience, I loathe it.
Many people think of Bash as "special", but it's just another interpreted language like Ruby or Python or Perl. It's that many people also use a Bash repl for their interactive shell that they get confused.
Unit tests let you change code fearlessly with instant feedback.
Integration tests require basically deploying your app, and when something fails you have to debug the root cause.
If you’re doing a lot of mocking then your design is not good. And only public interfaces should have testing.
reply