Live data from Hacker News

Small programming tricks

will-keleher.com

61–70 of 195 posts

Re: Small programming tricks

#61
post #2

This reminded me to ask: To what extent are people still coding by hand these days? In my profession (academia), literally no one codes anymore. On one hand, it sucks because the joy and fun of programming has been replaced by constant agent orchestration tasks, but on the other hand, it's hard to go back to the way things were before because the productivity gain is so good. I remember learning a lot of these progra…

> To what extent are people still coding by hand these days?

I write everything myself. After 41 years of coding, I think in code — code flows from my brain through my fingers effortlessly: translating my thoughts to English for an LLM to then translate back to code is much, much slower than me. And once my hyperfocus kicks in, the last thing I need is to be jolted out of it by an LLM prompting loop.

JetBrains Rider has an AI auto-complete which I do use for the 5-10% of the time that it can predict what I’m going to write next. But even the next-word/next-block-of-code prediction seems so hopelessly out of its depth (which is supposed to be LLM’s party piece), it’s genuinely shocking how wrong it is most of the time.

Disclaimer: I’m not writing vanilla line-of-business code or bog standard web apps, so I suspect I’m just not in the training data.

Re: Small programming tricks

#63

Only a few of these are actual programming tricks. The problem with sharing them is that they'll typically seem obvious to you, since you know them. It's difficult to know what is actually unknown to other people, and if you share stuff everybody knows you risk coming off as arrogant. Here's one that I think more people should know: avoid branches. If I can do the same thing without an if statement and even a logical…

I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.

There's stuff like the "Command Pattern"/dispatching/subclasses etc that can make this nice, although it's not always a good fit.

Like imagine you have a few different classes of things A,B,C so instead of checking if the thing you're handling is an A,B,C you have like a shared interface across all and can call Thing.do_it or whatever.

Still branching conditionally but it's passing it off to language features instead of code you have to write.

Re: Small programming tricks

#64

Earlier quoted context omitted.

I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.

Here's an example of removing a branch that was posted to HN a little over a month ago: https://www.greyblake.com/blog/branchless-rust/

From the article:

=====

Should you go branchless?

Most of the time, no. Branchless code is harder to read and easier to get wrong. Besides, compilers know a lot of tricks and already do a lot of this work for us.

Only when a profiler points at a hot loop, and the loop contains a branch on unpredictable data this technique can pay off big.

Re: Small programming tricks

#65

Earlier quoted context omitted.

I think there's a fine line between helping your team grow and the sorta annoying self promotion I've seen people do in overly broad slack channels. One is actually helping and the other is making yourself more visible to mgmt for promotions.

I rather think the opposite. People who share tips and hacks are genuinely trying to help others, while people who hoard information are competing on an individual basis without regard for team.

Please take this in good faith, as I hope your own post is, but I interpret the thread you're replying to as focusing on the "everyday' part.

Share knowledge? I don't think anyone here is arguing against that in any way (or conversely arguing for hoarding knowledge).

The concern, one I share, is where the sharing has to happen publicly "every day" - so no matter how trivial, useless, niche, overly-specific the tip is (whatever, the list isn't exclusive), someone shares it.

That's the part that's not sharing knowledge for the benefit of others, but rather self-serving. I might even go so far as to say self-serving doesn't even need to be selfish; the person might genuinely believe they're doing good, but even there, self-serving.

TLDR: Share your knowledge, don't make sharing something every day, even when you don't have something valuable to share, your target.

PS - if this note irks anyone (are routine maxxers a thing?), make the goal to learn something every day, then share where appropriate.

Re: Small programming tricks

#66
post #38

A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likel…

> go back to the old days where you manually approve every command the AI runs

Those are also the current days if you have any sense. It's a bad idea to run an LLM with access to your machine at all, but if you absolutely must, you better review everything it does to make sure it doesn't run anything insane.

Re: Small programming tricks

#67
post #34

Earlier quoted context omitted.

s/seen as// Annoyance is a clue; not about them, but about you.

Weird personal attack, thanks. What I'm saying is I am not a jerk and actually do care about my coworkers, however I also don't want a bunch of noise in a chat app I have to use to do my job.

You can mute the channel. Why would you want your teammates to communicate less ?

Re: Small programming tricks

#68
post #57
post #38

A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likel…

> “the old days” Is this just plain old rage baiting? I literally can’t tell any more.

It’s a figure of speech. I use that phrase for anything older than three months.

Re: Small programming tricks

#69
post #38

A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likel…

> go back to the old days where you manually approve every command the AI runs Those are also the current days if you have any sense. It's a bad idea to run an LLM with access to your machine at all, but if you absolutely must, you better review everything it does to make sure it doesn't run anything insane.

They run in a container with no network access, no data access other than the project folder.

Re: Small programming tricks

#70

Only a few of these are actual programming tricks. The problem with sharing them is that they'll typically seem obvious to you, since you know them. It's difficult to know what is actually unknown to other people, and if you share stuff everybody knows you risk coming off as arrogant. Here's one that I think more people should know: avoid branches. If I can do the same thing without an if statement and even a logical…

I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.

There are multiple ways to avoid branches. An early return, a lookup table are two that I use regularly and consider a code smell when the AI uses many if clauses or switches.
Post reply on HN