adregan

The gp's comment wasn't made regarding the look of the operator in its ascii representation `|>` but about the vertical misalignment.

Typically you align a pipeline like so:

     df
     |> rbind(other_df)
     |> select(...)

But these topics are largely left to code formatters these days.

One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros.

Now apologies for the aside—and I know I'm likely wading into a very expansive topic and reducing it down to something simple—but why in Rust, if the types are known:

    struct Song {
      title: String,
      artist: String,
      rating: i64,
    }

do you have to call `.to_string()` on things that look a lot like strings already?

    Song::new("Hate Me".to_string(), "Blue October".to_string(), 9)

Couldn't the compiler just do that for you?

I often think of Thoreau when my mind drifts to romanticizing farming:

> I see young men, my townsmen, whose misfortune it is to have inherited farms, houses, barns, cattle, and farming tools; for these are more easily acquired than got rid of. Better if they had been born in the open pasture and suckled by a wolf, that they might have seen with clearer eyes what field they were called to labor in. Who made them serfs of the soil? Why should they eat their sixty acres, when man is condemned to eat only his peck of dirt? Why should they begin digging their graves as soon as they are born?

They need to bring back the control strip!

https://en.m.wikipedia.org/wiki/Control_Strip

Solves this exact issue.

So you don't have to go through the factory reset if you are fine with having the app store? Safari is the only app I need to excise, and the OS won't let me delete it.

I was using a vertical Logitech mouse but was still experiencing discomfort mousing out to the side of my enormous Advantage2 keyboard. In an effort to head off any compounding RSI issues, I switched to a ploopy Adept trackball. Had no idea if I'd like switching to a trackball, and I love it! My hand never moves in an awkward motion, and mousing has become pretty restful. Better be careful tossing the ball up in the air idly during meetings as I won't be able to get a replacement if ploopy has paused shipping to the US (It's a pretty dumb habit at any rate).

Thanks!

Though hopefully, once the idiom is learned, I'll be able to remember it :)

Curious as to why a scan \ rather than a reduction /?

Is the q solution equivalent? In doing a plus scan, isn't the last element always going to be the largest? To find the largest subarray sum, I would think you'd want to split into a matrix along the `null`s first and then plus reduction and then a max of those results.

Say what you will about clarity, but my mind sort of glossed over the intention in the python and rust code, focusing instead on the syntax, while the q code made me consider what was actually happening.

When the article mentions "tech-adjacent," I think it is worth keeping in mind that this includes a broad swath of jobs that would never had qualified for amortizing salaries as R&D. For example, I'm skeptical that the tax change will have an impact on the number of television and film producers that are currently unemployed due to a huge slowdown in greenlighting projects from streaming services. I feel there is a contraction happening (though, practically, it doesn't always appear that way) that is a greater source of consternation than amortizing developer salaries will alleviate.

Surely the weight of a tractor pales in comparison to the person sitting inside? The heavy weight is for that big engine with a lot of torque. Can a lighter weight tractor pull its load?

There are only 2 transports in the current spec[0] though. WebSockets would be welcome but aren't a part of the spec.

0: https://modelcontextprotocol.io/specification/2025-06-18/bas...

There are a couple of patterns for accomplishing this in Elixir.

One is to build multiple function heads that pattern match on the arguments. If it’s an error tuple, pass it along. Build up your pipeline and handle any errors at the end.

Another is to use the `with else`[0] expression for building up a railroad. This has the benefit of not having to teach your functions how to pass along errors. Error handling in the else block can be a little gnarly.

I find it a little more manual than languages that have a `runEffect` or compose operator. In large part that’s due to the :ok, :error tuples being more of a convention than a primitive like Either/Result.

0: https://elixirschool.com/en/lessons/basics/control_structure...

Are there any binary formats that include the specification in the format itself?

I hate to be a hacker news poster who responds to a positive post with negativity, but I was also surprised at the praise in the article.

I don’t find Linear to be all that quick, but apparently Mac OS thinks it’s a resource hog (or has memory leaks). I leave linear open and it perpetually has a banner that tells me it was killed and restarted because it was using too much memory. That likely colors my experience.

I’m actually a neovim user already! This makes me worry that my config has something to prevent this behavior (but I hope not, I hate messing with my config)

Out of curiosity, do you have a good flow for having a file buffer automatically update in response to claude's changes? I'm perpetually needing to remember to `:e!<CR>` to read the updated file.

The author of this post was the guest on the most recent episode of the podcast The Array Cast

https://www.arraycast.com/episodes/episode111-ideal-array-la...

The is not the xkcd I thought it would be. This is the xkcd that Claude code makes me think of:

https://xkcd.com/1205/

I don’t feel Claude code helps one iota with the issue in 1319. If anything, it has increased the prevalence of “ongoing development” as I auto mate more things and create more problems to solve.

However, I have fixed up and added features to 10 year old scripts that I never considered worth the trade off to work on. It makes the cost of automation cheaper.

I’ve found in my interviewing that since having a child I am way worse at coding interviews—in ways I never was before. Perhaps this is due to being at a higher level of stress all the time—worrying about a young child’s wellbeing is a full time stressor (it doesn’t even stop when they go to sleep!)—but it also seems like there is so much more riding on an interview. When it was just me, and I was younger, if I failed, “oh well, I’ll get it next time.” Now there are concerns about health insurance, a mortgage, retirement &c.

I get stuck in ways I’ve never experienced in my life; my brain feels like it stopped working (but has reserved the bandwidth to shout at me the whole time “you’re blowing this!”). Then shortly after the call ends, sitting quietly, a path forward opens and suddenly I’m working on a solution, which it’s own special kind of hell—to know you could do it but didn’t and now some stranger out there thinks you’re a real idiot.

Studying/practicing has mixed results as you are taking away time from your partner and kid, this causes feelings of guilt. I found the more time I spent practicing, the more leetcode hards I solved, the worse I got. It was paradoxical! It was additionally demoralizing!

I only share all of this to say that circumstances change; you change. What once was easy becomes hard—maybe just for now, maybe forever, I don’t know. What I do know from my time at Big Co., is that this style of interview (often aped at smaller co.) is employed as one of the stated goals is to remove opportunity for biases (test everyone the same "quantifiable" way). However, my experiences lead me to believe that it falls short in that regard. As I said, people change, and a candidate who becomes a coworker with a high tolerance for stress today might not have the same appetite in a few years. Surely removing biases is about seeking balance, but I think certain types of interviews are blind to the imbalances they might cause.

This is precisely the risk I’ve been wondering about with vectorization. I’ve considered that an open source model might be valuable as you could always find someone to host it for you and control the deprecation rate yourself.

I think folks were too quick to throw out the good things about redux when hooks came out. Namely “dumb” presentational components that had no logic and abstractions for wiring up data and actions (mapStateToProps and mapDispatchToProps).

Sure reducers could be a bear (and asynchronous actions were hard), but the easily testable and portable logic-less views were really nice to work with.

Having worked in a number of codebases from React’s earliest days until now, I see echos of the bad old mixin days in the usage of hooks.

This is an interesting analogy as I have found that unless you are regularly in contact with hand made furniture, you have little feel for what is different about mass produced furniture and why anything else is desirable.

There may very well be a texture to “hand crafted” software that will be totally lost on users. But I kind of doubt the difference will be anything like the difference in furniture.

Those sound like the exact same use case in the end as both are concerned with what happens to the texture of a page were the font to change.

I’ve seen Claude code get halfway through a small sized refactor (function parameters changed shape or something like that), say something that looks like frustration at the amount of time it’s taking, revert all of the good changes, and start writing a bash script to automate the whole process.

In that case, you have put a stop to it and point out that it would already be done if it hadn’t decided to blow it all up in an effort to write a one time use codemod. Of course it agrees with that point as it agrees with everything. It’s the epitome of strong opinions loosely held.

Ah this takes me back. It felt as thought the early 2010s were replete with ipsum generators (https://hipsum.co/ was always fun), and they were really handy when coding up a PSD design.

Not really sure if it’s just me, but I don’t really reach for them in my work anymore. Not sure if it’s because everything used to be a blog and now everything is an app, lower information density, or that content is less likely to be text.

Might be another reflection of McLuhan‘s “the medium is the message” in that APIs are built with the intended interface in mind.

To this point, GUIs; going forward, AI agents. While the intention rhymes, the meaning of these systems diverge.

How ironic given the amount of APIs that were locking down access in response to AI training!

Though the general API lockdown was started long before that, and like you, I’m skeptical that this new wave of open access will last if the promise doesn’t live up to the hype.

While I mostly try to go with the flow, I do get frustrated that there are more natural places to integrate with a issue tracking system like trailers, but they are so far off issue trackers’ happy path that it’s not worth it.

I think the problem is exacerbated by the fact that issue trackers follow fashion; and it’s more common that you are using the flavor of the week; and that flavor isn’t close to feature complete; and new features get added at a glacial pace.

I suppose this is a long winded way of stating how annoyed I am with branch names derived from linear ticket’s titles for tracking purposes, and I wish I could use some other form of metadata to associate commits with an issue, so that I could have more meaningful PR titles (enforced that I must use the linear branch name as the title).

Though I’ll admit that it’s an issue of a size that’s more appropriate to gripe about on the internet than try to change.

Oops. Thank you!

Here are my 2¢ on using AI at work. I’m using Claude code and my typical tmux/neovim setup.

1. I use AI to find my way in a sprawling micro(service|frontend) system that I am new to. This helps cut down massively on the “I know what to do, I just can’t figure out where.” I started a new job where everyone has years of context as to how things fit together and I have none. I feel strongly that I need to give an honest effort at finding things on my own before asking for help, and AI certainly helps there.

2. Anything I stumble upon in a dev/deployment process that leans too heavily into the “good behavior/hygiene,” I try to automate immediately for myself and then clean up to share with the team. In the past, I might have tried to adopt the common practice, but now it’s less effort to simply automate it away.

3. There is value in using AI in the same manner as I use vim macros: I use the planning mode heavily and iterate like crazy until I’m satisfied with the flow. If the task has a lot of repetition, I typically do the first one myself then let the AI take a whack at one or two. If I don’t like the process, I update the plan. Once I see things going smoothly, I give the AI the ok to finish the rest (making atomic commits so that it’s not just one big ball of wax). This is pretty similar to how I record macros (make one change yourself, record the macro on the next line, test it out for a line or 2, re-record if necessary, test again, plow through the rest).

4. When I come across something that needs to be fixed/could be improved but isn’t related to my task at hand, I do a few minutes of research and planning with the AI, and instead of coding a solution, we create a todo document or an issue in a tracking system. This wasn’t happening before because of the context switching required to write good documentation for later. Now it’s more of the same thing but akin to a dry run of a script.

5. I can quickly generate clear and easy to read reports to allow other teammates to give me feedback on work in flight. Think about a doc with before and after screenshots of changes throughout an app produced by a playwright script and a report generator that I can rerun in under a minute whenever I want.

I’m finding that I really enjoy the skipping the tedious stuff, and I’m also writing higher quality stuff because I have more bandwidth. It helps me collaborate more with my non dev peers because it lowers the barrier to sharing.

Important to note that in my experimenting, I haven’t had great luck with winding it up and setting it loose on a task. Too often it felt like being a junior engineer again, doomed to throw spaghetti at the wall. Once I started using AI as an assistant, I felt things really started to click. Software development is about writing code, but it’s about a lot of other things too. It’s nice when the AI can help write code, but it’s fantastic when it helps you accomplish the other things.