rbongers (u/rbongers)

rbongers commented on Vibe Debugging: Enterprises' Up and Coming Nightmare marketsaintefficient.subs... · Posted by u/someoneloser

rbongers · 20 days ago

>The discipline required to use AI tools responsibly is surprisingly difficult to maintain

I don't find that this requires discipline. AI code simply requires code review the same as anything else. I don't feel the need to let AI code in unchecked in the same way I don't feel the need to go to my pull request page one day and gleefully hit approve and merge on all of them without checking anything.

rbongers commented on Prime Number Grid susam.net/primegrid.html... · Posted by u/todsacerdoti

pinoy420 · 23 days ago

It looks the way it does because we like to see patterns even where there are none. E.g. you see a number 696969 and this seems more significant than 482649 for whatever reason

rbongers · 23 days ago

Prime numbers are a pattern; take the natural numbers - starting after 2, exclude every number that isn't 2, starting after 3, exclude every number that isn't 3, etc.

It repeats like this predictably. Even though it changes, the way in which it changes is also predictable. Their repetition and predictability make prime numbers a pattern.

Out of the fundamental pattern of prime numbers, higher-level patterns also appear, and studying these patterns is a whole branch of math. You can find all kinds of visualizations of these patterns, including ones linked in this thread.

It's not that you're seeing a pattern that's not there, it's that you're seeing a pattern that gradually becomes infinitely complex.

rbongers commented on · Posted by u/NeelDas

rbongers · a month ago

I've often thought that this (and every problem where a manual process is required that is tough to automatically enforce) an AI code reviewer could be very useful.

It's the type of thing you might add to a long checklist of things to make sure you do (or don't do) in an MR template that quickly becomes difficult, if not impossible, for MR authors and especially reviewers to reliably follow.

Tests is another example - you can check that coverage doesn't slip over time, but not that every change is tested. And a human can maybe remember to check if there are tests, even if there are good tests, even if there are tests for every change if coverage tools are well integrated in your system, but not if every change is tested well, and not reliably.

AIs are great at sorting through lots of data to check for errors that a human would miss. Letting it add MR review comments, not letting it make any changes it wants, would allow for a human to provide checks and balances.

So I like the idea, I'm not sure how I feel about limiting it to docs or letting it write changes itself.

rbongers commented on The Useless UseCallback tkdodo.eu/blog/the-useles... · Posted by u/0xedb

efortis · a month ago

> At worst it's unnecessary

Not really. The problem goes beyond re-rendering 15 times. For instance, how do you instrument usage? It can’t be simply debounced.

Similarly, you’ll be making unnecessary requests. e.g., we need to fetch X when this prop changes.

Or, we need to lazy load X once.

And back to re-rendering, there’s plenty of apps rendering @1FPS when dragging elements.

rbongers · a month ago

Thank you, that was the example I needed to hear to see why this could be an issue.

I will still say though, I have not actually had this happen to me yet with all the years of using hooks. Generally when I'm fetching when X prop changes, it's not in response to functions or objects, and I guess if it's ever happened it's been fixed and never broke or hasn't caused problems.

Not to say it isn't an issue - it is - but the number and degree of issues I saw with lifecycle functions was much worse. That was with a less experienced team, so it could just be bias.

rbongers commented on The Useless UseCallback tkdodo.eu/blog/the-useles... · Posted by u/0xedb

rbongers · a month ago

I don't have a problem with needing to memoize props passed to child components for their memoization to work.

If your parent component doesn't need the optimization, you don't use it. If it does need it, your intention for using useMemo and useCallback us obvious. It doesn't make your code more confusing inherently.

The article paints it as this odd way of optimizing the component tree that creates an invisible link between the parent and child - but it's the way to prevent unnecessary renders, and for that reason I think it's pretty self-documenting. If I'm using useMemo and useCallback, it's because I am optimizing renders.

At worst it's unnecessary - which is the point of the article - but I suppose I don't care as much about having unnecessary calls to useMemo and useCallback and that's the crux of it. Even if it's not impacting my renders now, it could in the future, and I don't think it comes at much cost.

I don't think it's an egregious level of indirection either. You're moving your callbacks to the top of the same function where all of your state and props are already.

rbongers commented on The Pain That Is GitHub Actions feldera.com/blog/the-pain... · Posted by u/qianli_cs

deng · 6 months ago

Already see people saying GitLab is better: yes it is, but it also sucks in different ways.

After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is:

* Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code.

* Invest time that your pipelines can run locally on a developer machine as well (as much as possible at least), otherwise testing/debugging pipelines becomes a nightmare.

* Avoid YAML as much as possible, period.

* Don't bind yourself to some fancy new VC-financed thing that will solve CI once and for all but needs to get monetized eventually (see: earthly, dagger, etc.)

* Always use your own runners, on-premise if possible

rbongers · 6 months ago

In my opinion, unless if you need its ability to figure out when something should rebuild or potentially if you already use it, Make is not the right tool for the job. You should capture your pipeline jobs in scripts or similar, but Make just adds another language for developers to learn on top of everything. Make is not a simple script runner.

I maintained a Javascript project that used Make and it just turned into a mess. We simply changed all of our `make some-job` jobs into `./scripts/some-job.sh` and not only was the code much nicer, less experienced developers were suddenly more comfortable making changes to scripts. We didn't really need Make to figure out when to rebuild anything, all of our tools already had caching.

rbongers commented on My washing machine refreshed my thinking on software estimation cosive.com/blog/my-washin... · Posted by u/tashicorp

rbongers · 7 months ago

I have had a lot of opportunity to estimate a lot of projects, but one thing I still can't figure out is estimate education.

If a client wants to know "why is this going to take so long?" I can list the unknowns and third-party touch points, which are always things that make tasks take longer, but then they'll wonder why those are going to make it take longer. From there it's a challenge to communicate how unknowns are part of every project, how they are a good indicator of the risk of a task, and how there are some things you just won't know until you start work on a task in earnest.

Doesn't seem to matter how much detail I go into, it always comes back to "but I thought this would be easy."

The best I can come up with is to educate clients on what bad estimation looks like (Did they come right back with a fixed estimate for your type of project? Are they even asking questions?), hope they come back after getting different estimates with the exact red flags I warned them about, and then maintaining client trust by any means necessary so that when I say something is going to take a certain amount of time they know I'm not exaggerating.

rbongers commented on New junior developers can’t code nmn.gl/blog/ai-and-learni... · Posted by u/mhfs

malfist · 7 months ago

This article is just the latest in the long history of lamenting the laziness of the youth

rbongers · 7 months ago

I don't think it's quite the same. We live in an inbetween time - AI is not quite there yet.

AI struggles with knowledge from after its training date (so it can't help very well for anything relating to new versions of libraries) and often just generally gets things wrong or comes up with suboptimal answers. It's still only optimized to create answers that look correct, after all.

With these problems, someone on the team still needs to understand or be able to figure out what's going on. And dangit if it isn't getting hard to hire for that.

And the day that AI can actually replace the work of junior devs is just going to cause more complications for the software industry. Who will get the experience to become senior devs? Who will direct them? And even if those people also get replaced eventually, we will still probably have more awkward inbetween times with their own problems.

Can't say it's not convenient, but no use pretending the challenges don't exist.

rbongers commented on Some people with insomnia think they're awake when they're asleep scientificamerican.com/ar... · Posted by u/sabrina_ramonov

rbongers · a year ago

When I went for a sleep study, I was wired awake for half the night, up in bed reading waiting for the study to be over. According to the study though, I was in sleep stage 2 the entire time I was sat up in bed reading.

rbongers commented on 22-year-old builds chips in his parents' garage (2022) wired.com/story/22-year-o... · Posted by u/pabs3

rbongers · 2 years ago

I am surprised semiconductor engineers called it impossible. A cutting edge chip, sure, but a few thousand transistors?