DanielHB

You are assuming a greenfield scenario, in large brownfield projects it is quite easy to degrade performance by innocent changes. That is usually when the perf goes to trash.

It takes a lot more work to keep performance good in a large project than just letting it degrade.

I remember using it to encode some videos for a school presentation. I think I needed to make it fit into a CD and play-on-double-click and Bink was the easiest tool to do it in.

From what I heard from Visual Studio folk it is surprising it is not orders of magnitude faster rather than "much faster".

Also I learned to program in Turbo C and Turbo Pascal with its debugger and nothing comes faster (at least nothing single threaded)

Casey mentions that at some point one of these great minds were upset that it was so difficult to write programs because they didn't have things like keyboards or screens. One of them even brings up exciting new developments in electronic typewriters that could be used to improve their workflows.

It is kinda funny that some world-renowed people who invented genius algorithms like quicksort and graph shortest-path were mulling over "hey would be nice if we kept related data together in a struct" and some people were raging over it saying "why you want to change how I work?"

Casey points out that many of the lessons they came to were so obvious that it just became how it is done that no one even remembers it was done in any other way. In the talk the laments it makes it really hard to track down who originally came up with these ideas.

Claude ran npm update (update all dependencies to the latest version compatible with the semver specified) in my repo without telling me when trying to fix some problems. Given that only updates the dependency lock-file I didn't notice and it caused several hours of debugging for me.

It is quite sneaky how LLM output can sometimes bypass human verification like that. No one is going around checking every single line change in auto-generated files. Someone could easily sneak a malicious dependency in there through some online tutorial that the LLM searches for.

Guake and Yakuake have this always-on-top terminal overlay mode which is really nice for this kind of workflow. Works exceptionally well with multiple workspaces I prefer one single big monitor with everything maximized and multiple workspaces.

iterm2 on mac also has a similar mode, but it is a bit finicky to set it up (it is really hidden in the settings).

I use git diff and ctrl+click the file+linenumber which opens my IDE. Works well enough. I use this macro here when there are a lot of changes:

  gdf() { git diff '*'$1'*'; }

  gdf fileName (doesn't need full file name)

  gdf folderName (all files in a folder)

The DPI thing is nuts, any high res monitor these days is unusable without some DPI adjustment.

when LLMs first became popular my first real use for them was to find information about AWS services. LLMs have read it all and can (mostly) synthesize what you ask if it is in the docs.

There is a subset of yaml which is like 99.9% of all yaml code that is fine.

And then you have whatever the hell OpenAPI uses.

You underestimate the cost of "optimization", sometimes it means actually rebuilding large parts of the system. I would not say it is the "easiest" part, but it is usually not what will kill your business though.

US bank accounts don't have IBAN? I thought IBAN numbers were part of the whole Swift system that Russia got locked out of. Shows how much I know about this stuff...

Yeah it is that old saying, the best person to wield power is the one that doesn't want it. High pay and bonuses get rats into the ship, low pay makes no competent sailor want to join your crew.

Yeah this is what I have seen in the orgs I been in too (although not as bad as you pointed out), I have also seen CEOs fail by inaction like you pointed out (not laying off people doing bad things).

Although I am more afraid of the middle manager who hides information than the CEO who doesn't act on it.

Why? If anything it makes complete sense:

1) Local inference means more general GPUs and less ASIC hardware. Only big companies can push ASIC because of the software required, meanwhile nVidia owns cuda which is the standard.

2) Local is less resource-efficient per chip (chips remaining idle much more, meaning more chips required).

3) End-customers have less bargaining power compared to hyper-scalers. Although this might change if customer hardware start behaving more like phones (SoC with everything packed in), but even then the SoC makers will likely still have less bargaining power than hyper-scalers. But then nVidia could potentially make the whole SoC too.

So overall local-inference users = higher profit margins for nvidia. They much rather have every business on the globe buy one nvidia rack (or every laptop have a beefy GPU) than have 5-10 hyperscalers buy a few hundred thousand.

I dunno most CEOs I have been under of seem to work really hard and try to get stuff done in a sane manner, it is usually the middle management that fs up.

CEO is, of course, partly responsible for having that middle management in the first place. However if I were the CEO I don't even know how I would be able to smell the rats with the top-down view that CEOs have (they can't be in every meeting and decision making of their subordinates).

If you have the right underlings (or inherit them) you might actually not need to do anything at all and succeed. Then again if you have the wrong underlings (or inherit them) then your job is hella-difficult.

This is not what I said, I said that Canada has internal tarifs between provinces while being in (albeit limited) free-trade agreements with other countries. Making some types of internal trade _more_ bundersome than foreign trade.

I work with music streaming, I don't really know how to judge what is low-ticket vs high-ticket. However it is a medium-to-high margin business.

Our free tier is time-limited but we still look at all tickets even from non-paying customers (in the hopes of converting them). A 1-hour intervention from a customer rep can result in a multi-year paying customer.

Language, payroll-rules and tax-rules alone can be enough to prevent a business from expanding into a market. Even when there is no foul intent, just different set of rules.

I am from Brazil and it is not unusual for companies to operate only within certain states because of this. Even though Brazil is a single country with a single language and mostly federal rules about things, there is still enough variance of laws from one state to another to cause problems.

Then you hear about Canada which has tariffs between its own provinces, but not to the US. Meaning some products are cheaper across the US border than across a province border. Figuring out how much to pay in taxes alone can be a blocker...

This is not an EU-only problem, any large single market will have friction in its internal divisions. It tends to be worse in the EU because the countries have a lot more sovereignty though (enforcement agencies tend to be local, not federal for example).

Android devices are unlocked, non-manufacturer OSes are still well outside of "easy" to install, much less get all features working.

The main problem is that people maintaining the OS build for your hardware is the same people making the hardware. If legislation forced to divest both into separate companies the support would last far, far longer.

Divorcing the OS from the hardware means stuff just lasts far, far longer.

Like just a few years ago it became impossible to run 32bit windows which effectively killed all OS software updates for hardware older than ~2005. Most application software followed.

On the Linux they just dropped support for the 486 and older versions of the kernel will likely still get security updates for a while.

The amount of pushback I get when I do a refactor to make a certain class of bug never happen again is huge...

Fortunately this kind of refactor is a lot easier nowadays with LLMs, but the QA is not improved and often what takes the longest.

I think about 10% of my SaaS company is in the support department, no outsourced support at all. We have about 50k paying customers.

You message support, some real person reads and gets back to you within a day.

> - An extended stdlib which ships versioned libraries which use semver rather than being perma-stable.

Half of the point of an stdlib is that it is a single shared lib so you don't run into the all-too-common problem of having multiple versions of the same lib in your program. Either you bundle all the stdlib multiple times OR you need to rely heavily on complex dead-code-removal which increases startup time (and still have a lot of duplicated binary blob from different versions peer dependencies).

This is why stdlibs almost never _actually_ remove stuff or make breaking changes, because that would make existing programs not compile on the new version of the compiler. This is why in Java you can still call Date methods that resemble the ones present in Javascript (.getYear(), .getMonth(), etc). They were deprecated in JDK1.1 (1997) and still available, today. The alternative is to go through a python3 moment at some point.

Semver the stdlib makes it not that much better than using 3rd party packages.

It is unfortunate, but if it weren't like that it would be pure nepotism everywhere. Hopefully we can move to better systems as corruption reduces.

It is getting to the point where you are better off getting an LLM to describe the PR changes in your preferred style (make it very short, make a table describing API changes, list renames in a table, etc, etc) than go to the one created by the reviewer. If only the reviewer could embed his prompts (like "make clear X" is happening) or his manual edits.

But to be honest I doubt most people who use AI for PR descriptions even bother changing anything.

I am from Brazil and highschool was hell because of college entrance exams. Everything we did was geared towards optimizing delivery time for exam knowledge/practice. We didn't even have PE after first year.

I was very lucky to be able to be engaged in that sort of environment, but at least 50% of my class was not.

It is unfortunate but it has a weird side-effect, the system really promotes ambitious people and endurance. Most of my "top-tier" uni class was middle class, the rich kids couldn't/wouldn't keep up. But that 50% of my high-school class really get the shaft in that system, but the ones that survived it were highly regarded in the job market by the degree alone.

Problem with dealing with binary files with git (or source control in general) is that you want to be able to see diffs, which is very dependent on the type of binary file you have.

I think you can create git plugins to show diffs in different formats for certain file-types (or even open a 3rd party tool to let you visualize it), but it is a lot of work. Most productivity tools don't have anything of the sort.

If you just care about storing the file git LFS + manual text-changelog per binary file works well, but it is annoying to get everyone on your team to work in this workflow (heck, getting everyone and all automation scripts to install LFS is already a pain).

I am not into the Ruby on Rails world, but I find LLMs much more effective with powerful type systems like Typescript. Especially if you nudge it to keep things strict and (statically) eliminate invalid states. Do they use similar systems (build-time typing) for Ruby?

When the LLM can verify its own output by running static analysis they produce better results. They also seem to understand type definitions and avoid going to the source which, in theory, should reduce context size.