pclowes

You can just do things. Not everything needs a study, you don’t have to justify yourself to anyone!

Try things, if you like them, do them!

Try not living a neurotic “study” based life, I am trying it and its pretty great!

This is a farce. Handwringing about a cat while SF drivers kill hundreds per year, and SF policy kills thousands.

I dunno, for a while it was the most valuable company on the planet. While you might not like his judgment it seems plenty of people did.

Honestly, stuff like this makes me want to leave my smart phone in the garage when I get home and have a single desktop linux box that is in a “computer room” hardwired and the house has no wifi or smart anything and every other screen goes into the trash.

I fear the move to LLM based search is a short term boost with a potential long term cost.

Yes they are very helpful. But what is the incentive to create more blogs for them LLM companies to scrape for novel tech? They are great for answering questions about things that are very well documented and understood but the incentive structure that aligns technical bloggers with search is being undermined.

In tech, knowledge scales non-linearly. No amount of trivial search can amount to finding excellent technical writing. Most of the stuff LLMs are great at answering are things that an individual can typically figure out already just much more slowly by RTFM (eg: react component, MVC code etc.) However, the LLMs fail at deeply technical or highly novel subjects.

I worry LLM usage overtime will create a gap between research papers and engineering as nobody is incentivizeded to write about their implementations/explorations.

I am hearing more and more tech-people jumping to Kagi regardless of role (SWE,SRE, PD,DS) which is encouraging.

I agree, and personally think we need to be very careful about surrendering data privacy in order to stop the bad guys or creating a surveillance state to police immigration.

Is he wrong?

This has historically been very true. The nuclear deterrent has significantly decreased the probability of civilian or armed forces dying as a result of conflict globally.

There are plenty of reasons to critique Palantir but this article comes across as so ham-fisted, conspiratorial, and wanting facts that it actually makes me more sympathetic.

Critiques of Govt contractors really need to be grounded in first principles. Namely:

- should the government be able to wage war?

- should the government collect data? How much?

- how effective do we want these companies providing these services to be?

- how integrated do we want these different govt and non-govt tools and datasets.

Finally should these tools start or stop working when leaders you don’t like are democratically elected?

Palantir also did great work with hospitals and vaccines delivery during the pandemic and continues to do great work with hospitals.

Most of the critiques of Palantir come down to them being good at a job or mission the critic doesn't agree with.

For inspiration in this direction see Patrick Collison's great list: https://patrickcollison.com/fast

Highly Agree.

Speed of all kinds is incredibly important. Give me all of it.

- Fast developers

- Fast test suites

- Fast feedback loops

- Fast experimentation

Someone (Napoleon?) is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".

As long as there is some rigor and you aren't shipping complete slop, consistently moving very quickly fixes almost every other deficiency.

- It makes engineering mistakes cheaper (just fix them fast)

- It make product experimentation easy (we can test this fast and revert if needed)

- It makes developers ramp up quickly (shipping code increases confidence and knowledge)

- It actually makes rigor more feasible as the most effective rigorous processes are light weight and built-in.

Every line of code is a liability, the system that enables it to change rapidly is the asset.

Side note: every time I encounter JVM test startup lag I think someday I am going to die and will have spent time doing _this_.

Bluntly I have my doubts on how "AI-savvy" the Google execs are based on how flat footed they seem to be with respect to releasing successful and compelling AI products.

Eg. I don't want Gemini to summarize a google doc, thats what the title and first paragraph do...

I feel like this is a bit like click bait.

Don't get me wrong, my career has been enormously helped by Japanese developers. (Thanks Matz)

But "works better" is a hard claim when there are very few pure software tech firm in Japan that are also globally dominant (would love to hear of them if they exist).

I have never in my entire career at startups, consultancies, BigTech, or Fortune50s heard _anyone_ ever care about tabs/spaces or JS frameworks beyond "oh this approach is interesting, lets try it"

Additionally I don't think "The secret? They treat code like a Toyota Camry, not a Tesla." is the flex the author thinks it is.

Finally, development speed is incredibly important. Napoleon is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".

As long as its not complete slop and has some safe guards, consistently moving very quickly fixes almost every other deficiency.

- It makes engineering mistakes cheaper (just fix them fast)

- It make product experimentation easy (we can test this fast and rever if needed)

- It makes developers ramp up quickly (shipping code increases confidence and knowledge)

- It even makes rigor more feasible as the most effective rigorous processes have to be light weight and built-in or they go unused.

Code shouldn't be built to last decades, it should be built to be changed quickly and easily.

Every line of code is a liability, the system that enables it to change rapidly is the asset.

I like this approach, there are often calls for increased testing on big systems and what they really mean is increased rigor. Don't waste time testing what you can move into the compiler.

It is always great when something is so elegantly typed that I struggle to think of how to write a failing test.

What drives me nuts is when there are testing left around basically testing the compiler that never were “red” then “greened” makes me wonder if there is some subtle edge case I am missing.

Oops, I meant weakly typed as in JS or strongly typed as in Ruby. But decided to switch the Ruby example to Elixir and messed up the sentence

I like this. Very much falls into the "make bad state unrepresentable".

The issues I see with this approach is when developers stop at this first level of type implementation. Everything is a type and nothing works well together, tons of types seem to be subtle permutations of each other, things get hard to reason about etc.

In systems like that I would actually rather be writing a weakly typed dynamic language like JS or a strongly typed dynamic language like Elixir. However, if the developers continue pushing logic into type controlled flows, eg:move conditional logic into union types with pattern matching, leverage delegation etc. the experience becomes pleasant again. Just as an example (probably not the actual best solution) the "DewPoint" function could just take either type and just work.

But how are you going to monetize? Are you looking to raise? Moat seems low to me tbh... ;)

This is great. Props for making something fun.

I am confused by this, isn't Bisect just some git ergonomics with respect to flagging a checked out commit as a success failure and then checking out the next midway commit depending of if it was a success/failure to enable classic binary search?

It might be slightly more tedious but couldn't you just do the same thing manually and it would add just a couple minutes to the search and you would still save weeks? I like the ergonomics but only use it once every couple years.

In most major European cities I have been in the airport to train connection is pretty subpar unless traveling light.

There is typically no integration of the airport baggage handling with the train baggage handling. So you need to move everything with carts that you can't take on the train.

An international trip to Europe for a longer duration is also a significant trip and not something you want to "one bag". Add in jet lag, multiple young kids, car seats, stroller etc. and it quickly becomes easy to see why the train is cumbersome for the initial airport to lodging connection.

I don't understand what you are trying to claim. 1. Booking.com is owned by Booking Holdings which is an American parent company. 2. US GDP growth has been massively outperforming the EU since 2008.

I am saying tourism is not something governments should want to heavily optimize an economy for. No amount of taking money from people on vacation will translate into building a more competitive or innovative economy.

Sadly I have encountered this on multiple different kinds of European tech platforms. There is some deep cultural disconnect on understanding how/why American tech companies are successful.

Most often they seem to ape most of major US tech platforms functionality but critically somehow miss the "make something people want" and instead make something that:

- Sort of works? Has all the major screens but the whole experience just feels off and not well thought out.

- Is basically a way for locals to prey on tourists. Or is easily abused to scam etc.

Bluntly that is not a viable business model. Additionally tourism as a whole will not build a durable and innovative economy.

There is this distinct disinterest in serving the customer. Making the experience delightful, frictionless, feeling good is oddly foreign. I basically gave up trying to use local things unless I have to because when things go poorly customer support is basically non-existent.

I know Uber, AirBnb etc for better or worse. I don't want to deal with whatever surprising edge case or unexpectedly subpar experience is normed on the local platforms.

Apple is putting ads as pop ups inside the wallet app now… every social media app is crammed with them too. Browser is the easy fix.

I think there are a lot of offerings out there now. Maybe not to the minute with respect to battery life but Apples chip advantage is steadily evaporating. I typically don't need more than 8 hours of battery personally.

Have heard good things about framework computers. As a more efficient chip or battery comes out you just upgrade that component if your use case requires it.

Amazing. If someone had pitched this concept to the producers of "Idiocracy" they would have rejected it as too far fetched and ludicrous.

I think most major players have the same incentives and minor players don't have the economies of scale to make it work economically.

Also the longer I used my iphone mini and the rest of the world moved to comically large phones the more it became apparent that nobody is thinking about small screen form factors in design and when they do its only around ad placement.

I just don't see the value add anymore and the company appears to have lost its product vision and the design sensibilities are slipping. Apple is controlled by a geriatric board and a logistics expert and it shows.

I feel I am more frequently encountering software bugs, vaporware,(dESiGnEd fOr ApPle InTelLiGeNce), and ridiculous "innovation" (genmoji). I feel the hardware advances are not very relevant to me, I don't need VR or augmented reality. I want a computer to get out of my way and solve problems for me so I can spend time in plain old reality. The hardware upgrades I DO care about are ridiculously overpriced (Ram upgrades are abusively expensive).

While I prefer my computer to be a tool to get a job done and don't want the computer itself to be a hobby. I also do not want to be forced to use AI. I also dislike the rent seeking and toolbooth behavior of iMessage and the App store. Now that linux has more paved paths, things increasingly "just work" and hardware has basically caught up I don't see a good reason to support Apple's non-vision with my money.

My cynical take is that small phones don't exist because they are not the product. Similar to vape pens the product is the addictive substance the device loads. In this case its apps and ads. A smaller screen probably negatively impacts KPIs on many levels, at Google/Apple/Meta/X and on down through the ecosystem.

I understand that Apple did not make enough money to make it worth their while to continue the iphone mini line. However, it does seem like there is a profitable business for someone there given how beloved it was/is.

I only traded out my iphone 12 mini just recently for an iphone 16 pro (likely the last apple product I will ever buy but thats another story) and aside from the camera it is basically the same. Just heavier, awkward to hold and slightly worse designed.

No major player wants a smaller screen because it has downstream impacts on the pipeline of addictive material and ad pixels they can stuff into ocular nerves.

The flow here for me is if the code is doing the wrong thing I:

- Write a test that demonstrates that it is doing the wrong thing

- Watch it fail

- Change the code to do the right thing

- Ensure the test passes

And in return I get regression prevention and verified documentation (the hopefully well structured and descriptive test class) for almost free.

I don't think any amount of testing absolves the programmer from writing clear, intention-revealing code that is correct. TDD is just a tool that helps ensure the programmers understanding of the code evolves with code. There have been so many times where I write code and expect a test to fail/pass and it doesn't. This detects subtle minute drift in understanding.

I agree with that but I would say that if I required formal verification of that kind I would move the proof based rationale into the type system to provide those checks.

I would add Tests can be probabilistically exhaustive (eg property based testing) and answer questions beyond what proof based reasoning can provide ie. is this sorting of arbitrary strings efficient and fast?

I would lean towards types and property testing here using tools like Coq.

Interesting, could you show me a formal proof that can't be expressed in logic (ie. code) and then tested?

My thought here is that since proofs are logic and so is code you can't have a proof that can't be represented in code. Now admittedly this might look very different than typical say JUnit unit tests but it would still be a test validating logic. I am not saying every system is easily testable or deterministic but overall, all else equal, the more tested and testable a system is the better it is.

IME things that are very hard to test are often just poorly designed.