bcoughlan

Hence why I said "Not aimed at all the wonderful, sane and reasonable people of the USA." I know it's not a Europe vs USA divide, just that it pisses me off that the American news and social media is talking about air conditioners instead of climate change.

There's a lot to criticise of every country, but we're trying. The US is not trying (*) https://en.wikipedia.org/wiki/Paris_Agreement#/media/File:Pa...

* Not aimed at all the wonderful, sane and reasonable people of the USA.

I don't mean to be divisive, but this meme-like stream of news articles and comments about Europeans being silly about air conditioning, from the drill-baby-drill nation that refused to even try to do anything about climate change, really grates on me.

I've been thinking the same: the smaller the codebase, the better AI performs. So a way to scale AI is to modularize your architecture to maximize the number of leaf nodes in the dependency tree, and split out separate libraries where it makes sense.

It is huge for token usage also, Claude grepping the codebase for context it doesn't have is the main consumer of input tokens from what I can see.

I misinterpreted the parent comment to mean that they won't notice it because they will be extinct!

Perhaps we are putting human intelligence on a pedestal. I have often caught myself having a supposedly original idea only to find I inherited it from something I read months before.

We are mostly autocomplete with a mild capacity to synthesise new ideas. It’s the network effect of communicating that creates the feedback loops which amplify our collective intelligence.

Also if you think intelligent life has to have a regard for truth, not just a regard for self, tune in to any news channel.

Something an older and wiser programmer taught me, is to think of the infrastructure costs as a per-user cost. These numbers look enormous next to my bank balance, but if you save 500k per year to service 1 million users, it's nothing to your bottom line.

Meanwhile there's the opportunity cost of moving. All of the people who put effort into this migration, who could otherwise be building something revenue-generating. I think that's why in many companies cloud costs are a problem, but never enough to make it high up the backlog.

I’m talking youtube-dl and VLC player. No YouTube logos, no concept of what YouTube even is.

Even the sidebar of recommendations is a dark pattern for a 3 year old. Unlike Netflix etc where you have to exit the video to browse something else.

I considered doing the same but in the end decided I don’t want to use a platform I have to fight against, while still letting them build brand recognition to my kid.

So I downloaded a bunch of the videos on our desktop and blocked the site. Works for my 3.5 year old, not sure the plan when they outgrow it.

I would guess it comes down to that the best researchers in the world want their work out in the open

I'm nearly certain that the images and the text are AI generated from other sources and perhaps tweaked a bit. The headings are the giveaway. Low signal-to-noise ratio.

Google search results is full of this stuff, but first time seeing it at the top of HN

As a non-american I also thought the same. Reading a synopsis of evidence completely changed my mind [1]. Pipe bombs planted at party headquarters to divert the police, maps of tunnels under the Capitol building and so on. Not amateur stuff.

[1] https://en.wikipedia.org/wiki/Planning_of_the_January_6_Unit...

Can't uninstall the browser, and occasionally it's needed for legit reasons. I quite literally can't resist drifting towards mindless scrolling apps, though I know that's hard to fathom for some people.

My approach for iPhone:

- Set time limits on apps. - Block App Store. - Set a Screen Time pin, then forget it.

Downside: if you need to install a new app, you need to do a iTunes backup, factory reset and restore the backup,. Also apps won't continue to update with this approach.

Worth it though. I don't miss wasting 10-20 hours a week on brain rot apps.

On the flip side, putting a ticket on the backlog knowing it will never be high enough priority to be done is an effective way to manage people's feelings without outright nopeing their idea.

Then you would love https://theuselessweb.com/

I made a tool to generate command line clients from OpenAPI definitions out of pure frustration from trying to stitch together incantations of curl commands to work with APIs.

I haven't revisited it in a while, and the docs could probably do with some love, but I use it every day.

[1] https://github.com/bcoughlan/openapi-commander

The solution at my workplace is a bot that opens PRs to bump dependencies and automatically merges if the tests pass.

It's taken a lot of workload off devs to meet security targets. But I worry it makes supply-chain attacks more attractive. If an attacker can compromise a package and it's instantly merged into the codebases of thousands of different companies that's a huge danger.

This was always my interpretation of "Flat is better than nested." from "The Zen of Python".

I often run into conflict with developers who believe in the single return statement. This is flatter but irks a lot of devs:

if (!condition) {

  return

}

more code

return

Starting with a monolith is nearly always great advice. However, monoliths tend towards spaghetti because it's too easy essentially to draw new lines on the architecture diagram by importing from anywhere.

To scale a monolith codebase without devolving into spaghetti you need to have a well defined layered structure for modules. The other aspect is being able to hide internal code to prevent it being imported by other modules.

I did a write-up a while ago about how we do this on my current project [1], and published the Maven enforcer rule and ArchUnit test example as an open source project [2].

[1] https://bcoughlan.github.io/posts/modulithic-architecture/ [2] https://github.com/bcoughlan/base-package-enforcer-rule/ https://github.com/bcoughlan/base-package-enforcer-rule/blob...

Strength training is so good for desk jobbers! I recommend joining some small group circuit training or CrossFit groups, where the trainers will show you how to lift correctly and safely.

I stopped adding salt in my cooking when I had to cook for a young baby. Pleasantly surprised to find I didn't miss it much, and pretty soon my tastebuds reset and when I eat out everything tastes wayyy too salty.

I used to follow topics to try to answer questions. It's a great way to learn a topic in depth. But I find that the bulk of questions about {topic} have already been asked, and the stream of questions are like "How do I get {topic} to work with {other niche tool}?". The Venn diagram of people who know both topics is way smaller. If you want an answer, narrowing the question to a single topic really helps.

But I have asked a few questions, and the quality of answers have really declined, mainly because people are rushing to answer and not reading the question. They could address this by delaying voting on answers.

I have done pretty well with a combo of Nokia dumbphone for calls and texts, and a separate smartphone with no SIM as needed. I leave my smartphone at work or in the car when I want a break.

Only downside really is no WhatsApp but you can get a KaiOS phone that supports WhatsApp if it's essential.

Honestly the urge to constantly pull it out just passes after a couple of days. The boredom is intense but pretty soon you won't miss it and will enjoy other activities.

I also had good results with a very very cheap Android phone running Android Go. It was so slow that I just didn't want to use it for browsing. Downside is as a Dad I want to have a good camera within reach for special moments.

Overly granular tests are a scourge of our industry, unless you’re writing a widely used utility library. It leads to tests that become a useless burden for even mild refactoring.

Writing larger test cases that test the actual functionality is a game changer. With Testcontainers and good mocking tools you can spin up a real version of your app with external dependencies mocked and faked, and write test cases against the same input layer your user uses. If your test fails you can be pretty sure it’s because you broke something.

This is a layer between unit and integration tests that you don’t read much about. I call them “service tests” (coming from a microservices world).

Investment is still needed though to reduce the effort of implementing tests, like extracting common fixture code so that every test doesn’t need long winded setup code. Also snapshot testing libraries take the pain out of writing assertions.

I am speaking from the API based backend world so YMMV. Once you’ve worked this way it’s hard to go back. Any developer can come in and confidently make changes. You spend way less time investigating regressions and broken environments, so you can release more frequently (which takes a whole other layer of pressure off the team)

It depends on your use case. Starting with the spec can unblock other implementers, so that they can work with mocks while you build the implementation. And it can help prevent re-work by describing the API first and getting feedback.

Bigger orgs also have style guides for public APIs and you can use various linters/standardization tools to enforce this. Tech writers can work on the API documentation without making changes in your code. There are tools that can tell you if your spec changes would cause breaking changes to API clients, such as adding a required query parameter.

You might not need these things on your project, but for some users it makes sense to write the spec first.

Contrary to some others experience here I've had good results writing OpenAPI YAML and generating server stubs in Spring. Because it's generating strongly typed code we get a lot of guarantees that the docs match the implementation. For working with frontend devs it's a huge win over the lossy communication of word-of-mouth API docs.

It is definitely verbose to write and Moonwalk would help. Co-pilot helps a huge amount, but I do crave a DSL that's not indentation based.

I quite like the idea of viewing run cost as architecture fitness function https://www.thoughtworks.com/radar/techniques/run-cost-as-ar....

If your architecture has a high cost to develop, test and run when a cheaper architecture meets your needs, it's a sign that you have overengineered. In my experience there is an order-of-magnitude increase in complexity by adopting microservices that only starts to pay off when your org and user base are huge.

I think the majority of people have the same experience with screens. There's something inherently distracting about reading anything long on a screen. Idly drifting to easy dopamine-hit activities is perfectly normal. Also pro tip, send anything long to your Kindle to read.

I'm not saying ADHD isn't real, just that environment-induced distractions aren't it.