move-on-by

I must disagree. I normally clean my fans before switching spin directions. Our living room doesn’t get good circulation compared to the rest of the house and so the fan is on a low setting pretty much 24/7. I was thinking the same as you, it’s been moving like non stop since last time I switched directions, how much could have collected? A lot apparently. Once it stopped and I switched directions and turned it back on- dust went everywhere. I had to vacuum the entire room and couches. Learn from my mistake. Moving fan blades does not mean clean fan blades.

I never really thought much of any vacuum I’ve ever own until I got a shark one. It picks everything, to the point where you have to be extra careful you don’t vacuum over things you don’t want to be sucked up into the vacuum. It makes total sense, who needs such powerful suction when you can instead just put a roller on the floor to pick things up. Never going back to a suction-only vacuum.

I read Atlas Shrugged recently. I went in not knowing anything about the book or author. I liked it for maybe half way through and despised it by the end. Reading about the author after finishing the book, it had a lot of her personality in it.

Just one more data point but this is what I’m seeing too. The extreme ‘ruthless’ prioritization has stopped and devs (who want it) have breathing room to make the enhancements they’ve been wanting all along. Turns out what is good for AI is also good for regular old school SDLC. All you have to do is say it will make AI more effective.

> One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. This is a big caveat. I too, regularly find a fix problems that need to be solved. Very occasionally, something big blows up, and I already have a solution in progress. Those are curious, because it reinforces that I’m working on the right things, but also that I was too slow. Other times I fix things that never became a major issue. Is it because I fixed it in time? Or was it never going to be an issue? Anyways, I’m a staff engineer, so I guess I’ve been able to demonstrate my usefulness well enough, but it’s a constant struggle. The new product features and support for new partners is what gets all the glory. At the end of the day I suppose that it is right for the glory to go to them. It’s important for the business to gain new business and market advantages. I really enjoy ‘greasing the squeaky wheel’ and generally making things run as smooth as possible. Depending on your leadership, this might not be the type of ‘staff engineer’ they are looking for.

I can’t say I know much about kernels, but what you say rings true. It’s not unlike the micro service vs monolith argument. It depends on the use cases, but in a system where the micro services depend on each other, all you have is a distributed monolith. All the complexity and overhead, and none of the benefits. Keep dependencies close.

With any ORM, N+1 queries can be major performance problem. They can be a bit tricky to identify because individually the queries are fast, but when you execute N of them per request, it adds up. It’s worth looking at. You can write units tests that assert the number of actual SQL statements get executed for a given function. N+1 isn’t just a database issue either. I’ve seen N+1 at the cache level too with Redis. The cache layer supports ‘get_many’ and ‘set_many’. I haven’t stood up a ‘fresh’ Django app in ages, but some things I remember are worth looking at:

* compression middleware like gzip. There is a big scary warning on this, but modern Django has mitigations in place

* how your DB connections are managed and reuse them- I think Django even supports a DB connection pool these days

* serve static assets directly - skip hitting Django for anything that isn’t dynamic

This is just one of the many reasons I don't have the disposition to be in sales

I remember sitting in on a sales meeting early in my career. I kept quiet, but afterwards I complained to my manager that they were selling features that didn’t exist and conflicted with core concepts of the product. My manager told me that was how sales were made. I left the company not long after, I was already disgruntled prior to that discussion.

I’ve seen the same thing everywhere I go. I don’t have the disposition to be in sales, but I periodically daydream of making huge commissions by straight up bullshitting people. There seems to be no downside.

I don’t have great hearing, so I’m not sure I can really weigh in here (thanks punk concerts in my teens). I remember similar arguments around screens and 60Hz vs ‘the human eye’. I think a lot of people, myself included, can easily perceive the difference between 60Hz and something higher- given the right conditions. I would not be so quick to disregard claims of more sensitive hearing.

Ah yes, totally secure. I’m sure there will be no unforeseen problems or bypasses.

I’ve been very involved with the DNS blocking scene- and it’s extremely easy to circumvent. I always wonder if there are some principled nerds on the architecture side purposely designing things to be easily blocked with DNS blocking. Or perhaps the mercenary nerds are just that inept. Maybe a mix. I also don’t think the numbers of users with DNS blocking are large enough for the mercenary nerds to care about. However, the math for LoE to bypass DNS blocking has certainly changed recently.

I doubt the ‘average consumer’ is even using a password manager, let alone going to change their password because of something so common place as it being compromised.

It’s been a little over a week since ‘An update on GitHub availability’

> Our priorities are clear: availability first, then capacity, then new features.

Let’s see how long it takes them to turn this ship around.

My experience is not much different then what you listed, except I discussed programming with my math teacher. She said as long as I was the one who programmed it, and that I didn’t share the program with anyone else, the I could use it.

Looking back on that experience, I’m very grateful to her, but she also probably didn’t realize I was programming it to also show the individual ‘steps’ to get the solution instead of just the solution.

I’ve seen another pattern, I call it “The Document Mongerer”:

I regularly work in a largish monolith. We have micro services too, but most things are in the monolith. Over the years there have been multiple pushes to split it up into micro services. These efforts invariably fail because the _goal_ is the micro service architecture itself instead of something useful to the company, like the ability to do fast releases or better organized code.

Anyways, in the past few months I’ve seen multiple people individually ‘attack’ this insane goal with AI. The first step is always to generate massive amounts of documentation describing the current state of code and proposing areas to split up. Then, after the engineer generates this huge store of documents, they say ‘looked what I created’ and then drop it and move on to some other shiny toy. No one will ever read these documents. They are out of date before they ever get ‘completed’, their sole usage is to waste credits.

I’m seeing big wins with AI, but not at the product level. I’m excited about the progress, though maybe I should be questioning our priorities more.

There is so much hype around AI and using it to move faster that the extreme focus on ‘product’ and prioritizing ‘impact’ has greatly relaxed. For the first time in my entire career, I’m able to prioritize addressing technical debt and friction in our SDLC processes.

Normally, these types of changes get bundled in with regular product work and cause timelines to grow. Nobody paid down technical debt unless it came due and was no longer optional.

I am using AI to address tech debt, but these are all things I identified as problems - and big improvements - long before AI was a regular tool in the toolbox. I just could never demonstrate how addressing them early would pay off in the long run through faster project turnaround. Fixing known issues simply doesn’t rank against new features when it comes to prioritization.

Anyway, I’m thankful to finally get to fix these things, and our ticket-to-deployment time is going way down - but none of this matters if ‘product’ doesn’t streamline their goals and priorities as well.

Merge queues are great.

The bug only affected repos using merge queues AND squash/rebase merging (instead of the default merge commit)

> I was suddenly overwhelmed with purposelessness

My kids are young enough that I don’t need to worry about it yet, but I can totally see how I might have the same issue. Beyond just myself, my partner is just as invested in the kids and I can foresee needing to rediscover ourselves together. Do you have any advice, tips, or insights for new empty nesters?

The thing about active mines is that they expand. I’m not saying you should be concerned, but “it’s a mine away” is just a single data point

It’s a nice idea, but why not donate directly?

https://www.winehq.org/donate

I’ve seen this too, but mostly with the ‘team lead’ seniors- the ones interested in the management track.

On the other hand, a SE2 was asking me for help with something that was way off track from what they should have been doing. This isn’t a new SE2, but someone who seems the have topped out as an SE2. Anyways, they were not understanding anything I was pointing them towards, so I got frustrated and just gave them the exact prompt to feed into their AI. The AI fixed it for them. They were amazed by the result, but should have been horrified by their uselessness instead.

I don’t think it was clear, but thanks for the insight.

Was WolfSSL forced upon Elixir or Erlang? Did they purchase it and received a defective product? Are they held hostage by WolfSSL’s decisions? Are they not allowed to modify WolfSSL as needed themselves?

I fail to see any victims beyond perhaps the WolfSSL maintainers for having to suffer such entitlement.

> Asking me to open a new issue to discuss this behavior instead of it being a high priority for them to open up a new issue internally to fix this is odd. I'm not here to do their homework for them.

Why are people so entitled? How much is the author paying WolfSSL to make demands of them?

> Currently I've only identified one victim of this decision, but there's bound to be more out there.

Oh yes, he has become a victim of using a FOSS library.

> if I don't do it, nothing gets done

I work for a midsized fintech and I feel the same way. At least about the tech side of things.

I know this is a joke, but in all seriousness it will probably be locked to a Samsung Thermostat controller with a screen - which can absolutely show ads - and require an App with GPS permissions to work (and use your location history to drive the advertisements)

These are not JavaScript zero-day bugs, they are tooling bugs.

    researchers said the new bypass bugs were found in npm, pnpm, vlt, and Bun.

Pretty impressive. Whether you think AI is a bubble or not, we all benefit from these findings.

As for all the slop the Curl team has been putting up with, I suppose a fool with a tool is still a fool.

I like this. It seems obvious, but I’ve seen many different teams struggle with it. There is a lot of difficulty clearing the brush in a way that doesn’t break existing paths and is also repeatable. It takes a team with a vision and dedication to pull it off correctly, not to mention robust tests to ensure reliability.

One thing not mentioned, is that it’s still incredibly slow. There will be a lot of time pressure and bad optics no matter your choice, this is a lose-lose situation without the proper support. The pressure can also make it difficult to not create new brush in the process.

Interesting read! I’m a total outsider, but the supplement argument seems reasonable to me.