Manish Vachharajani

Web #developers have been working with declarative specifications (HTML, CSS) for quite some time. #DevOps can learn some things from how web evolved from static #html to #php to things like #reactjs. #javascript adaptjs.org/blog/2020/01/2…

@ChShersh The problem is one of abstraction. The callee's exceptional case is the caller's simple error. As a library writer you cannot know what is exceptional and what is ordinary for the caller.

Many devs don’t understand that you’re supposed to use exceptions only for exceptional cases. Exceptions are NOT for error handling.

Installing @ubuntu 24 on a mini PC and true to form, WiFi config hangs setup, even though the connection was successful. Settings->System->Remote Desktop hangs the settings app. Classic Linux Desktop. Much better than 10 years ago, still can't get the basics right.

@martin_casado Definitely interested!

Hey infra folks. We're standing up a new Discord server to discuss CS infra. If you want an invite DM me (reply and I'll follow). thanks!

As I set up my new Mac, I do not understand why so much software makes me download an installer that then downloads the actual software to install. Why not bundle the two together?

@thdxr The language.

so what exactly is regular about a regular expression

@rakyll I don't think AI is going to replace the interesting parts of SWE (yet). I use AI daily. It handles some of the tedious parts of programming. It cannot write interesting code, and I think making it do so is a hard problem, despite the hype to the contrary.

I’m sorry but this is hell. AI was supposed to replace the boring parts of the job, not the intellectually most stimulating parts.

@Swizec I'll say it again. I am amazed that there are devs with the patience and discipline to build large systems in purely dynamically typed languages. Seems like insanity to me.

4 months ago I changed from mostly TypeScript to mostly Python suddenly I find myself missing tests, a lot 😅 This confirms my suspicion that 90% of unit testing is just devs building a half-baked type checker. But I can’t find any papers about this

@the_sttts @kubernetesio No true abstraction for k8s itself. I should be able to create a namespace such that in that namespace it looks like a private k8s cluster as far as CRDs, permissions, etc.

Biggest mistake @kubernetesio did, but cannot correct without breaking changes in a v2?

@ibuildthecloud At some point we all mature to the stage of just wanting to get things done.

I've reached the "can the IDE just install the toolchain for me" age in my life.

@ibuildthecloud Things get complicated when they are used in real life to solve real problems. Let's see how Deno looks when its adoption is as far reaching as Node.js. On the bright side, I don't see them moving to C++.

I like the design philosophy of deno. Which makes sense because I also liked nodejs in the beginning before the community destroyed everything about it and made it the most complicated platform ever invented.

@housecor Certainly as many quality checks as practical should be moved before merge. As the team scales though, the integration tests will inevitably take too long, and you cannot serialize all merges if you want any merge velocity.

Controversial opinion: 🌶️ I prefer for all quality checks to occur *before* merge. Here's why. Merging code that hasn't been fully quality checked leads to batching work. It means we need to maintain a long-lived environment (like QA, UAT, or Staging) to integration test all our changes. It means need more release overhead - we need to agree on a release cadence, release cutoff dates, etc. This encourages developers to rush to hit release cutoff dates too. And it leads to devs getting pulled back into work days later if their code doesn't pass inspection in some other environment. 👎 In contrast, if all quality checks occur *before* merge, we can automatically deploy the code when it's merged. So all the release overhead above melts away. No more batching, coordination overhead, release planning, etc. Code just automatically deploys to prod the moment we merge it, because we've already determined that it's good enough. 🔥

@ibuildthecloud Not everyone is ready for the power of emacs ;)

I love vim. I hate neovim. I think y'all missed the point of vi. It wasn't supposed to be emacs.

@AdamRackis The dev tools space is hard. Adoption is hard, revenue is even harder.

The funniest thing I heard this year in my conference travels is that Prisma is actually a VC-backed company that’s now scrambling for revenue while Drizzle is just some 10x engineer having fun lmfao

I've been using @cursor_ai to solve the 2024 Advent of Code in Rust to learn the language and some of the AI's autocompletes are creepily good. I had a simple bit compare and it auto-completed the error message as "loop detected" when it doesn't seem to me at all obvious that that is what the check does.

@ChShersh Plus, devs know where the bodies are buried. Good QA sometimes exercises code in unexpected ways, but there is nothing like knowing where the complexity is.

Separating QA from SWEs is a huge anti-pattern. As a developer, you must test your own code. Otherwise, you have no incentives to improve ergonomics and automate flows.

@housecor So what about backend changes that can corrupt data? Where/how do you perform system-level testing for those things without some kind of staging environment? Unit tests and such can only go so far.

Yep. A staging environment is an architectural code smell. Prefer continuous deploy and feature flags if possible.

@housecor @devanfarrell_ Devs are rewarded for shipping code on time because that is easy to measure. Bugs and their impact are harder to quantify. If devs think QA will stop major issues, the incentive is to merge. Later, business pressure forces QA to yield and a lower quality product is shipped.

@devanfarrell_ I agree quality is everyone’s responsibility. But unfortunately I’ve found devs often abdicate that responsibility when QA exists.

Hot take 🌶️: I’m not a fan of dedicated QA. I prefer the dev team to be solely responsible for quality. When dedicated QA exists, 2 problems tend to occur: 1. Devs get lazy. They lean on QA to find bugs. 2. Dev and QA often use different testing tools which duplicates effort.

@housecor Also don't forget the finger pointing when things don't ship on time.

@ibuildthecloud Once you realize you really care about reliable software with the least pain, the rational choices get pretty narrow.

Why do I feel like TypeScript is a gateway drug to Rust? I swear, I can stop at anytime, I'm only just looking at Rust.

@ChShersh The gains are still real though.

Every time I see benchmarks like “We improved performance by 4587%!” I wonder how hilariously bad the product was done in the first place