No joke, the main reason I got TSA PreCheck was so I didn't have to take my shoes off. All the other benefits were just nice extra perks. It was a preposterous policy and I'm glad it's gone.
I looove cleaning up/refactoring old code, improving build systems, writing tests, etc. I've been contracting part-time at a place for a couple of years now, and that's basically all I do. I suspect there's going to be a greater need for people like me in the near future. I don't think that the code LLMs or agents produce is any better or worse than the code it was trained on. Not to sound too judgmental or condescending, but there's a lot of crap out there. That's a good thing as far as I'm concerned, because I have made a nice bit of extra cash cleaning that crap up. I imagine the description of what I do is going to go from "I'm being paid to fix issues caused by years of accumulated technical debt" to the title of this post. Ironically, AI helps me with my job to some extent, but I usually end up rewriting most of the code it generates because it follows the same bad patterns I'm trying to address.
When you're dealing with objects as small as this, their weight and size is essentially mathematically irrelevant. It doesn't have any type of propulsion, so we know that unless it collides with something along its trajectory, it will keep following the same course. We know the mass and diameter of the celestial bodies that the object will be traveling near, so we can calculate how those bodies will affect its trajectory. As one of the top comments said: it has a very high eccentricity, which means it's traveling along a path that forms a very elongated, open hyperbole, so it won't come close enough to the sun to be affected by its gravitational pull if it continues to follow its current trajectory.
I know XML and XSLT gets a lot of hate. To some extent, the hate for XSLT is warranted. But I have to work with XML files for my job, and it was pretty refreshing to not have to install any libraries to work with them in a web app. We use XML as the serialization format for a spaceflight mission planning app, so there's a lot of complex data that would be trickier to represent with JSON. At the end of the day, HTML is spicy XML, so you can use all the native web APIs to read/write/query/manipulate XML files and even apply XSLT transformations.
I suspect some of the hate towards XML from the web dev community boils down to it being "old". I'll admit that used to have the same opinion until I actually started working with it. It's a little bit more of a PITA than working with JSON, but I think I'm getting a much more expressive and powerful serialization format for the cost of the added complexity.
> Why doesn’t he ask his girlfriend what a thermodynamicist is? (She should know: That’s what her dad does.)
My dad worked a lot of different jobs at the same company before he retired a few years ago. I know at some point one of his jobs had "logistics" in the title. I only ever had a vague notion of what his job entailed. Unless the job title is obvious, like "plumber", I wouldn't expect this woman to know what the hell her dad does.
I was a little surprised by this bullet point for when make would be an appropriate build tool:
> The build system does not need to be highly portable.
I know "highly" is a vague qualifier here, but I pretty much always default to a Makefile in Go projects and have used it to build Electron apps on Linux, macOS, and Windows (without WSL, just Make for Windows). You have to do a little extra finagling to get the executable paths right, but it works well enough for my purposes.
To some extent, I get why Make gets a lot of hate. But if you keep them simple, they provide a great way to get around some of the limitations of package.json scripts (e.g., adding comments).
> The Trump administration argued in court filings that the plaintiffs are improperly questioning his executive orders, “inviting judicial second-guessing of the president’s judgment.”
Isn't this that whole "checks and balances" thing I learned about in school?
I've been frustrated about this for a while, but I haven't had a good term to describe it, so thanks for that! The biggest annoyance I find from the increasingly complex types is the impact on tooling. My IDE slows to a crawl trying to process recursive types. tsc takes 4 minutes because of some needlessly complicated library types. Just pump the brakes on the types and write some damn unit tests.
I've been working with the VS Code codebase for the past few months and I noticed they're encoding/decoding all the IPC messages using a custom binary buffer implementation (or at least I think that's the case, some of the code is hard to follow). It struck me as odd because most of the messages are pretty small (definitely not 100s of MB). I always wondered: at what point does it become more performant to encode messages to binary and decode them on the other end? Does it really take that much longer to just send strings?
Well, they're not, they're just an efficient way of encoding a subset of data. They can't compress that data, like, for example, compressing 100 x "a", unless they have a compression algorithm attached, they will just represent "a" 100 times, but more efficiently than unicode or whatever.
reply