It's a cycle, design patterns, TDD, the latest framework or language. We keep chasing the next silver bullet, but there isn't one. There's no easy road.
Made me think. Every time I see a “Postman collection” or similar artifacts, my heart skips a bit. Use curl. Run it interactively in the terminal. When it works, move it into a shell script where you can simply check the status code. Voilà, magic! you’ve got yourself a simple but valuable integration test.
Instead of juggling dashboards and collections of requests, or relying on your shell history as Matklad mentions, you have it in a file that you can commit and plug into CI. Win-win.
At some point, that testing shell script can be integrated into your codebase using your working language and build tooling.
First. Love that more tools like Honeycomb (amazing) are popping up in the space. I agree with the post.
But. IMO, statistics and probability can’t be replaced with tooling. As software engineering can’t be replaced with no-code services to build applications…
If you need to profile some bug or troubleshoot complex systems (distributed, dbs). You must do your math homework consistently as part of the job.
If you don’t comprehend the distribution of your data, the seasonality, noise vs signal; how can you measure anything valuable? How can you ask the right questions?
> On the one hand, at lower-levels you want to exhaustively enumerate errors...
> On the other hand, at higher-levels, you want to string together widely different functionality from many separate subsystems without worrying about specific errors...
I feel like the Rust ecosystem of crates has naturally grown to handle these two ideas pretty well. `anyhow` for applications, `thiserror` for libraries.
Jokes aside, I liked the idea of listing things by level of detail.
One related issue I run into all the time is how context gets lost when moving between layers. You start with host metrics, then Kubernetes wraps the host and overrides the tags, and suddenly you can’t filter host metrics by node anymore. Watch out.
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
Everyone can talk and give opinions. The real question is if you can actually make a difference. I tell people there's a gap between knowing how to do something and actually doing it. And that gap is a big part of our engineering skills.
If I'm not going to change something, I'd rather not talk or give opinions.
> Any time you are making decisions based on information that you know at compile time, you could apply this technique
I’d go further. Most business requirements are known at compile time.
Take the simplest example, dispatching a function based on a condition. If A then do_X, if B then do_Y.
People often reach for elaborate design patterns, dependency injection, or polymorphism here. But why?
If the decision logic is static, don’t turn it into a runtime problem.
Inline the code. Move the ifs up. Write clear, specific functions that match your domain knowledge instead of abstracting too early…
I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.
You can force changes with a ‘—ignore-inmutable’ flag.