gopalv

> Come back in a week and update us on how long you've spent debugging all the ways that the code was broken that you didn't notice in those 15 minutes.

I was a non believer for most of 2024.

How could such a thing with no understanding write any code that works.

I've now come to accept that all the understanding it has is what I bring and if I don't pay attention, I will run into things like you just mentioned.

Just about the same if I work with a human being with no strong opinions and a complete lack of taste when it comes to the elegance of a solution.

We often just pass over those people when hiring or promoting, despite their competence.

I was being sold a "self driving car" equivalent where you didn't even need a steering wheel for this thing, but I've slowly learned that I need to treat it like automatic cruise control with a little bit of lane switching.

Need to keep the hands on the wheel and spend your spare attention on the traffic far up ahead, not the phone.

I don't write a lot of code anymore, but my review queue is coming from my own laptop.

> Usually I don't nitpick spelling, but "mimnutes" and "stylisitic" are somewhat ironic here

Those are errors an AI does not make.

I used to be able to tell how conscientious someone was by their writing style, but not anymore.

> Is aging bad though? Seems like natures way of helping humanity evolve.

We're not undoing death, dying healthy would be better than aging the way we do right now.

Increasing healthspans as a society would be great in a more family integrated society rather than an individualistic one.

I'd love my retirement years to be spent helping my kids and grand-kids instead of the other way around.

A senior community that can stay involved actively has been part of the "it takes a village" until very recent times.

My favourite part of these research publications from the US Gov is the licensing.

All of the USDS work is published with "No Copyright".

The SAT filters however still do not support incremental building, which is one of bloom filters fun features when you use them in distributed databases (you can build N of them and then OR bloom filters to get a single one).

I imagine it will still be incredibly useful where you can iterate over them and do OR the old fashioned way, but at higher accuracy for the same size.

> make it work and make it right?

My mentor used say it is the difference between a screw and glue.

You can glue some things together and prove that it works, but eventually you learn that anytime you had to break something to fix it, you should've used a screw.

It is trade off in coupling - the glue binds tightly over the entire surface but a screw concentrates the loads, so needs maintenance to stay tight.

You only really know which is "right" it if you test it to destruction.

All of that advice is probably sounding date now, even in material science the glue might be winning (see the Tesla bumper or Lotus Elise bonding videos - every screw is extra grams).

> folks here would likely howl socialism with a 3rd place run by the city.

It is not socialism, the problem is the lack of that.

My city does a good job of running a 3rd place as part of their library, it is right outside the library in a big seating area meant for phone calls & talking in general.

But they have 3 full-time security staff, the police station is across the street and the social case workers have an office in the same building.

Outside of a decent coffee, the place has everything for me to walk in with my kids in the summer and work while they roam the hallways as if it was their own, meeting other kids from the same school district. There's even a no-cars allowed trail connecting the place for kids to cycle safely to.

However, take away the constant enforcement by security + social case worker hovering, this falls apart because it'll have the etiquette of a subway car.

The homeless are there btw, but they tend to be non-disruptive and mostly there to get help with something (like a cancelled EBT card).

> bangalore 2023 worked because entropy was high and friction was low

Go a whole decade+ back, it was the Leela coffee shop which opened till 1 AM.

> we maynot recreate that on a discord channel.

IRC + freenode did the same decades ago, back in the day when the computers wouldn't fit in a backpack - people would just lurk socially and not really join a channel for a purpose.

Most of #linux-india was a third place after midnight, though not a physical one.

> Don’t abuse rules to force a puritanical or tyrannical lifestyle

I really like the CGP Grey's "Themes" instead of calling a rule [1].

The concept of a "trends towards healthy" is much easier for me than "eat healthy".

[1] - https://www.youtube.com/watch?v=NVGuFdX5guE

> So the latent heat is conducted away by the cooling apparatus, it's just not explicitly stated, to sound more sensational.

In theory, if that makes it hotter than ambient air in the process, that would be a good thing - usually we have to cool things down below ambient air to get moisture out.

Not a good thing if you want to measure maximum moisture extraction, but cooling something to ambient temperatures is a much easier task.

> those rates amortize and distribute the cost of storm recovery

Not exactly when it is a farm out there away from a town.

My experience is from a different era (90s) and a different kind of farm, but I spent a bunch of summers in one, which had power outages whenever the monsoons picked up.

The trouble was that there was a single line feeding the farm from about 6km away, so if that went down a single farmowner complained - the rate payers who were in a denser urban area always got priority, because there were 600+ people who shared a transformer.

The generator ran a lot when winds knocked power out, but the generator only ran when there was a big power need like running the well pumps or one of the winnowing mills. Even the winnower had pedals, because work doesn't stop.

Every bathroom had a light with a 30 minute battery in it, which came on when the power went out - I guess if they had LEDs those same batteries would be 6 hour lights.

They would have killed for solar + storage, because shipping fuel in for the generator was one of those annoying things you had to keep doing over and over again.

> Titanium is mostly better where corrosion

Until we mix metals and have galvanic corrosion, where an Al + Ti system corrodes exactly where the metals touch.

It's not titanium that will corrode when you have an aluminium frame bike with a Ti bolt at the bottom bracket.

> recognise the shape of a scored note, minim, crotchet, quaver on a 5 x 9 dot grid

Reading music off a lined page sounds like a fun project, particularly to do it from scratch like 3Blue1Brown's number NN example[1].

Mix with something like Chuck[2] and you can write a completely clientside application with today's tech.

[1] - https://www.3blue1brown.com/lessons/neural-networks

[2] - https://chuck.stanford.edu/

> Postgres can handle tables of that size out of the box

This is definitely true, but I've seen migrations from other systems struggle to scale on Postgres because of decisions which worked better in a scale-out system, which doesn't do so well in PG.

A number of well meaning indexes, a very wide row to avoid joins and a large number of state update queries on a single column can murder postgres performance (update set last_visited_time= sort of madness - mutable/immutable column family classifications etc.)

There were scenarios where I'd have liked something like zHeap or Citus, to be part of the default system.

If something was originally conceived in postgres and the usage pattern matches how it does its internal IO, everything you said is absolutely true.

But a migration could hit snags in the system, which is what this post celebrates.

The "order by" query is a good example, where a bunch of other systems do a shared boundary variable from the TopK to the scanner to skip rows faster. Snowflake had a recent paper describing how they do input pruning mid-query off a TopK.

> Really hope this doesn’t change them too much.

My guess is that this team gets rolled into Online Tables tech, which would make product sense.

https://docs.databricks.com/aws/en/machine-learning/feature-...

> had to chuckle at the 20k IOPS AWS instance, given even a consumer $100-200 NVMe gives ~1million+ IOPS these days

The IOPS figure usually hides the fact that it is not a single IOP that is really fast, but a collection of them.

More IOPS generally is done best by reducing latency of a single operation but the average latency is what actually contributes to the "fast query" experience. Because a lot of the next IO is branchy from the last one (like an index or filter lookup).

As more and more disks to CPU connectivity goes over the network, we can really deliver a large IOPS even when we have very high latencies (by spreading the data across hundreds of SSDs and routing it fast), because with the network storage we pay a huge latency cost for durability of the data simply because of location diversification.

Every foot is a nanosecond, approximately.

That the tradeoff is worth it, because you don't need clusters to deal with a bad CPU or two. Stop & start, to fix memory/cpu errors.

The AWS model pushes the latency problem to the customer and we see it in the IOPS measurements, but it is really the latency x queue depth we're seeing not the hardware capacity.

> Just roll it into property taxes and call it a day.

It's what my district does and the benefits are obvious - there's no "gimme your lunch money" kids who have it hard at home & trying to supplement their diets.

The school even hands out a free breakfast, which serves as monitored childcare for the parents who need to drop their kids off before 8 AM, to get to work. The highschool also gives out double servings for kids who come off the morning sports practice sessions.

The cynic in me says the biggest beneficiary will be the US Army, who can reliably look for a stream of well fed kids from families which aren't doing well enough to pay for college.

An OLTP solution fixes a lot of the headaches about the traditional extract-load-transform steps.

Mostly a lot of OLAP starts when the data loads in Kafka logs or a disk of some sort.

Then you schedule a task or keep a task polling this constantly, which is always prone to small failures & delays or big failures when schema changes up.

The "data pipeline" team exists because the data doesn't move by itself from where it is first stored to where it is ready for deep analysis.

If you can directly push 1-row updates transactionally to a system and feed off the backend to write a more OLAP friendly structure, then you can hookup things like a car rental service's operational logs into a system which can compute more complex things like forecasting of availability or apply discounts to give a customer an upgrade for cheap.

Neon looks a lot better than YugaByte in tech (which also talks postgres protocols) and a lot nicer in protocol compatibility than something like FoundationDB.

Alloy from Google feels somewhat similar, Spanner has a postgres interface too.

The postgres API is a great abstraction common point, even if the actual details of the implementations vary a lot.

> But let’s talk about my unfair advantage – my Lyon family mafia. I was living with my brother Bob and his wife. Bob was working at Xerox SDD developing the Xerox Star workstation. And my brother Dick was at Xerox PARC with an Alto on his desk

Sometimes, I feel like the whole downwards trend having a single kid loses the family aspect of my previous generation - I meet enough people who don't have uncles, aunts, nieces or nephews for nepotism (literal) to work sideways on.

Nobody to pull them up and nobody to pull up in term. Not dynasties of tiger children, but simply support in minor ways.

I got into Linux because my uncle's brother in law worked in computer repair when I was 14, back when India still needed to fill in an export control form to download software. Another uncle sent me extra 32Mb of RAM from Dubai and a modem which wasn't a winmodem (& my dad hated him for the phone bills).

> We were just managing a house mortgage with 3 full time incomes. Interest rates then were well above 10%.

This is a great write up about a pull-style volcano SQL engine.

The IR I've used is the Calcite implementation, this looks very concept adjacent enough that it makes sense on the first read.

> tmp2/test-branch> explain plan select count() from xy join uv on x = u;

One of the helpful things we did was to build a graphviz dot export for the explains plans, which saved us days and years of work when trying to explain an optimization problem between the physical and logical layers.

My version would end up displayed as SVG like this

https://web.archive.org/web/20190724161156/http://people.apa...

But the calcite logical plans also have that dot export modes.

https://issues.apache.org/jira/browse/CALCITE-4197

The 32x virtual memory to physical memory ratio plays into relocation and colored pointers (i.e pointers where some bits serve as flag bits).

Putting the actual data layouts in 44 bits out of 64 is a neat trick which relies on the allocator being aware of the mappings between physical and virtual addresses.

> they also outperform human expertise directly

When measured statistically.

This is not a takedown of that statement, but the reason we've trouble with this idea is that it works in the lab and not always in real life.

To set up a clean experiment, you have define what success looks like before you conduct the experiment - that the output variable is defined.

Once you know what to measure ahead of time to determine success, then statistical models tend to not be as random as a group of humans in achieving that target.

The variance is bad in an experiment, but variance jitter is needed in an ever changing world even if most variants are worse off.

For example, if you can predict someone's earning potential from their birth zipcode, it is not wrong and often more right than otherwise.

And then if you base student loans and business loan interest rates on the basis of birth zipcodes, the original prediction does become more right.

The experimental version that's a win, but in real life that's a terrible loss to society.

> is it possible to make a musical instrument that is more acessible "to everyone"

Isn't that what MIDI did for music?

The next best composer might not know a single instrument, but make great music every day.

The intention guides the result, not limited by the actions.

> what it actually means is that this magic battery doodad needs to provide 90-95% of the performance of its existing, mature competitor

The problem is mostly that it does the battery draw when parked.

Solid electrolytes are coming some day soon, so that we can let it freeze without killing the cells.

Right now, the Tesla is hard to use in a winter sport season unless where you're driving has a charger or underground parking near a plug point.

I can drive up hill to a nice ski resort, spend 3+ days taking the bus with all your shoes on without touching the car.

With the batteries, they'll just run down when parked, so I cannot park it for a whole week outdoors like I can do with my Subaru.

And with the low battery + low temps, it will not charge back up going downhill so the expected range drops massively by the time you're downhill.

Once you navigate to a charger, the car starts running the heater and driving down range further.

Watching the car battery eating its own range while driving to "Donner pass road" on your way out of Tahoe or Reno feels rather appropriately horrific.

> Cheaper knowledge work increases demand for knowledge work.

This is Jevon's paradox.

> So the number of workers required might actually increase.

The increased demand for work turning into new jobs for existing workers, that is where the question is more complex.

This has gone the other way too in matters of muscle - people who wouldn't have been employed before can now be hired to do an existing task.

When you go from pulling shopping carts to an electrical machine that pulls carts for you, now you can hire a 60 year old to pull carts in the parking lot where previously that job would be filled by teens.

This is all a toss-up right now.

In an ideal world, I will be paying less for the same amount of knowledge work in the future, but as a worker I might get paid more for the same hours I spend at work.

My hours are limited, but my output is less limited than before.

> some of the tedious boiler-plate code is taken care of.

For me that is the bit which stands out, I'm switching languages to TypeScript and JSX right now.

Getting copilot (+ claude) to do things is much easier when I know exactly what I want, but not here and not in this framework (PHP is more my speed). There's a bunch of stuff you're supposed to know as boilerplate and there's no time to learn it all.

I am not learning a thing though, other than how to steer the AI. I don't even know what SCSS is, but I can get by.

The UI hires are in the pipeline & they should throwaway everything I build, but right now it feels like I'm making something they should imitate in functionality/style better than a document, but not in cleanliness.

> During the times when you aren’t on a high-visibility project, I recommend carving out your own lab days or 20% time. (Maybe start with 10% time and work your way up.) This is a great way to rack up quick, bullet-point wins that can go on a promo packet or a resume.

Working for extrinsic incentives often fail to keep up - it is very hard to be motivated to do something because it will go on a promo packet after the first year when a packet doesn't happen.

Doing things for fun is great & that's what I do, also usually a step removed from my core expertise where I can do less damage in general.

But fun tends to have its own "flow" which might insulate you from other signs of organizational stress.

I've had these sort of "fun side quest" blow up in my face because I didn't realize there was a spotlight on me.

If you can't observe the spotlight coming down high on up, the same quirky day jaunt into some old code can be seen as "hard to direct".

This was also a side-effect of being a remote worker in 2005, because if I was in office I might have noticed there is a shift in tone.

> that branch prediction got better in the ‘10s and a bunch of techniques that didn’t work before do now.

They got better than they had any right to be, but then we found out that Spectre & Meltdown were vulnerabilities rather than optimizations.

For example, a switch based interpreter was fast as a CGOTO one for a brief period between 2012 and 2018, but suddenly got slower again as the CPUs could no longer rely on branch prediction to do prefetching.

This is mostly the real reason why interning gets used, to avoid long string comparisons over saving memory as such.

Interned strings tend to not have a good cleanup mechanism, in a system where a lot of them are churned through. So often they tend to actually use more memory as data patterns evolve in a system.

I use the same trick when parsing json, where a large set of rows tend to have the keys repeated & the conversion to columnar is easier if the keys are interned.

> The paper examines a world people will pay an AI lawyer $500 to write a document instead of paying a human lawyer $500 to write a document

Is your theory that the next week there will be an AI lawyer that charges only 400$, then it is a race to the bottom?

There is a proven way to avoid a race to the bottom for wages, which is what a trade union does - a union by acting as one controls a large supply of labour to keep wages high.

Replace that with a company and prices, it could very well be that a handful of companies could keep prices high by having a seller's market where everyone avoids a race to the bottom by incidentally making similar pricing calls (or flat out illegally doing it).

Impatience is one of those selfish virtues.

Most of everything in the article is about the speed at which a human moves.

This is not about the machine, but it is indirectly about it - if I hit a sub-optimal build step, I will spend time speeding it up because the difference between a 45s build and a 90s build is that I will start typing a comment on HN instead of seeing if it worked.

In the real world, usually faster is better, because the world we operate in keeps changing - the decisions you made have a shelf life and your execution speed limits how often you deliver what is right or what would have been great six months ago.

So, I do everything in my power so that I can do things faster.

Lastly, I only have a fixed number of hours left on the planet - going faster is better than going longer at a task, because my goal is not to work 8 hours & go home, it is to finish my work and get back to my life.

Oddly enough, sometimes going faster can look paradoxical. I work only about 6 hours a day, but they are placed in such a way that I am at maximum velocity & flow during those hours.

I cannot keep that up beyond a couple of hours, so I work 10 AM to 12, eat a long lunch & get back to work at 2. Work from 2 through 4, go chase kids from 4:30 to about 9:30 PM. Work another 2 hours from 9:30 to 11:30, to be in bed fast asleep before midnight.

This means the hours I work are the fastest times of my day, while about 3 days a week 9 AM to 10, I am at a coffee shop reading a book.

I might be finishing lunch & then playing pool from 1 to 2 PM, so it does look to a lot of people that I am moving in a leisurely speed at work, but the only speed that matters is when you actually sit down and start thinking/typing.

On the way, whatever tool or processes I use that are slow or repetitive gets improved or automated, because again I want to be done at 4:30 before my brain goes into "driving in traffic" readiness.

The "make sharp tools" is a side-effect, not the core process which drives productivity.

> LLMs are a lot better than my backend engineers who don't even try but not that much better than someone who's skimmed the docs.

LLMs are basically at the skill-set of "Googled something and tried it", which for a lot of basic things is mostly what everyone does.

If you can loop back the results of the trial & error back to the model, then it does do a pretty good simulation of someone feeling their way through a problem.

The loop is what makes the approach effective, but a model by itself cannot complete the process - it at least needs an agent which can try the recommendation (or a human who will pull the lever).