Codex

I came into the industry right when XML fever had peaked as was beginning to fall back. But in MS land, it never really went away, just being slowly cannibalize by JSON.

You’re right though, there was some cool stuff being done with xml when it was assumed that it would be the future of all data formats. Being able to apply standard tools like XLT transforms, XSS styling, schemas to validate, and XPath to search/query and you had some very powerful generic tools.

JSON has barely caught up to that with schemes and transforms. JQ lets you query json but I don’t really find it more readable or usable than XPath. I’m sure something like XLT exists, but there’s no standardization or attempt to rally around shared tools like with XML.

That to me is the saddest thing. VC/MBA-backed companies have driven everyone into the worst cases of NIHS ever. Now there’s no standards, no attempts to share work or unify around reliable technology. Its every company for themselves and getting other people suckered into using (and freely maintaining) your tools as a prelude to locking them into your ecosystem is the norm now.

I’ve written Go code; they were right to fear.

I wrote a powershell script to parse some json config to drive it’s automation. I was delighted to discover the built-in powershell ConvertFrom-Json command accepts json with // comments as .jsonc files. So my config files get to be commented.

I hope the programmer(s) who thought to include that find cash laying in the streets everyday and that they never lose socks in the dryer.

Seeing this actually sent a small wave of dread through my body

What’s with the downvotes on a silly joke? Is the Linux kernel team on Lemmy?

That’s why Rust had to be developed! Oxidize all those computers and stuff back to nature.

To be fair, this is also how VS looks when you open a project fresh from the clone. Or after updating .net versions. .NET is awful about losing references and then claiming thousands of errors. Sometimes just running the build will fix it by relinking the DLLs it couldn’t find.

But also yes, VS with a team can be “fun” if people don’t sync their formatting settings. I once had a junior that kept converting spaces to tabs on every file he’d touch. You’d get it fixed and then he’d screw up his settings again with a VS update or something.

I should get to work on my opus, “Dirty Code”

Inside I’ll reveal all my secrets like: not writing tests, not documenting anything, putting the whole app into a single python file, object-disoriented relational mapping, obscure SQL tricks, unobscure no-sql tricks, and more!

Lol, this is how I’ll eventually open source my game: completely new repo with one fresh checkin. No one will ever see how many curse words and diary-entry commit messages litter my fossil repo.

I made a static site with Hexo a few years back. I thankfully didn’t make any “Get started with Hexo” posts but I did only really use it for a few months. I think that puts me in the cluster with the “switch from Jekyll to Hugo” people. Now it just sits there, absorbing some money every two years for the “personal website tax”.

Shame too, I constantly think I need to get back to it. Hexo is nice, popular with Chinese users I think. I don’t recall now why I liked it over Jekyll or Hugo, but I’ve always loved an underdog. Once I got the hang of using it, it was very customizable and fun to work with.

As a senior at my last big company job, basically all I did was conduct meetings and do PRs. It’s such a grind.

My opinion now is that most PR is worthless anyway. Most people give, at best, a superficial skim for typos, lack of comments, or other low-hanging replies (that usually, really, a static checker or linter should be dealing with).

Reading the code base in little chunks like that doesn’t give you proper context for the changes you’re reading. Automated unit and integration tests would be better for catching issues like that, but of course then who is reviewing and verifying the tests? Who’s writing them for that matter?

Ideally, pair-programming or having extra people on projects to create knowledge redundancy would help. But companies want to replace juniors with AI now, so that’s not looking good. Senior devs and architects might know the major pieces of much of the code, but can they “load it into working memory” sufficiently to do a quality PR that will catch something the tests didn’t and QA wouldn’t? Not in my experience.

I think the best actually-implementable solution for most teams is to get rid of PR expectations and take a multi-pronged approach to replacing that process.

1. use tooling to check for and fix basic stuff. Use a linter, adopt a code standard, get a code formatting tool that forced adherence to the standard and run it on every PR.
2. Unit tests if you got them, start if you don’t. You don’t need 90% code coverage, just make sure critical paths are covered.
3. Turn one of your useless meetings into a code review session. Each week/sprint, one Very Important Code section is presented by the developer that works on it most or that last changed it. This helps the whole team learn the code base, gets more eyes on the important stuff regularly, and enforces not just a consistent style but a consistent approach to solving and documenting problems.
4. PR (and the github PR approval stuff or its equivalent for you) should be streamlined but preserved. Do have a second person approve changes before merging, just to double check that tests have finished and passed and all that. If your team is so busy that no one ever approves PRs then allow self-approval and be done with it. This will make regular code review very important for security and stability, since any dev could be misbehaving unseen, but these are the trade-offs you make when burning out your team is more important than quality.

Tembra, his music downloaded. Darmok and Jalad with the AUX cable.

You mean, it’s all Electron? 🌍👨‍🚀🔫👩‍🚀

Wibbly-wobbly nerky-networky things

This is why I stick to Rust. The gender affirming surgery takes some getting used to, but at least I have both legs.