@collinsworth omg 100%. I used to have this conversation a lot with folks. It's true of a lot of things: the tech they use, the processes they follow, the way that they allocate time, etc.

Stay nimble, watch costs, and focus on what will make you and your team successful. 🔥

@collinsworth Having worked in a big (multi-billion dollar, hundreds of millions of concurrent users) I concur so hard.

Scale is a trap.

I am, at this point, something of an expert of doing a lot with very very little, and this is the skillset I am the proudest of.

@collinsworth There are. Ask the erlang/elixir folks. We have tales.

I can tell you the 99% result if you want. It gets killed. Because it does not fit the growth view of the world. And not spending money faster is a death sentence for a VC startup.

Also means managers cannot easily use metrics proxy, because you cannot ignore the complexity.

The biggest recent case is Bleacher Report

@collinsworth Quietly leaves this here:

https://codeberg.org/kitten/app

And this:

https://ar.al/2020/08/07/what-is-the-small-web/

And maybe this, to see where it’s at:

https://ar.al/2024/03/26/draw-together/

💕

#SmallWeb #Kitten

@collinsworth

Me.

I'm this case study.

I'm the guy who built a global >100gbps network spanning 8 locations on 3 continents, based mostly on SME FTTP, secondhand eBay hardware, and a couple of strategic colocated racks.

If you want this case study, talk to me.

[edit: now that VyOS is more mature, I probably would need half the hardware]

@collinsworth
Yes, and there will be examples of exactly this, scaling without infrastructure costs - so a single part time person can create an app that scales world wide without spending a cent on hosting.

#Autonomi is a secure, privacy focused platform that will change the rules, expectations and possibilities in favour of developers and users.

@collinsworth this is the way!

The inefficiencies in the industry is probably by design to generate more revenue out of training, cloud costs, etc.

@collinsworth
I think people use shortcuts when evaluating tech that's similar to how bikeshedding works.

Compare frameworks on benchmarks only rather than how they help structure applications, as the latter evaluation is much harder.

Use something that is used by big tech because they surely have thought it through and our tiny app is a temporarily embarrassed web scale app, right?

Nobody got fired for buying IBM is also a classic.

@collinsworth yes, that's extremely important. But then, the hard question is : how do you identify "what works" when you don't have the vanity proxy of "it is now a billions dollar company"? It's much harder, atomized.
Plus, often these kind of companies really don't have a public relation channel (perhaps b/c of there focus on other things).

That being said : I co-run rudder.io since ~15 years. It's a small company, but we're profitable since year 1, the product is appreciated, ND we're still able to massively evolve it for the better. Ford it qualifies for "tech that works without a army of staff eng"?

This also looks “so frontend development.”

For 15–20 years we’ve been looking at how big companies are solving their big problems, instead of learning how those of us with small problems (individuals and SMBs) best solve their small problems.

That’s our Occam’s razor why frontend devs know Bootcamp/Tailwind, jQuery/React, bundle/deploy, and have every 10-visitor site sit on all edge servers—but for whom HTML is `div` and CSS is broken.

The craft died in Big Tech.

#frontend #html #css #craft

@collinsworth My current hobby-horse is the 99%+ waste in how Apple and Amazon currently handle podcast feeds. 1 engineer day each and some thought could eliminate most of that without breaking the the tricky corner cases that they certainly deal with. And would lighten bandwidth and CPU load on 100k+ sites (and the Internet) at a guess. But no glamour in that work! No case study, unless to burnish their green credentials.

https://www.earth.org.uk/RSS-efficiency.html

#RSS #Amazon #Apple #podcast #efficiency

@collinsworth THIS THIS THIS.

Honestly, it was incredibly dispiriting to hear the words "we don't know if big websites will use this feature so arent sure we should develop it" from a member of the Safari team this week.

Like... can we please stop developing web tech *specifically for giant sites and corporate entities*. That is explicitly *not* what the web was built for.

It feels like such a betrayal.

@collinsworth @ash you can do a lot by picking boring technologies but all the cool blog posts on ci systems or whatever are written by people with tools teams.

Those boring tools lock you into other decisions. Use GitHub? You’re probably locked into the GitHub issue tracker as well (unless you want to do integration, so you need a tools team). And their ci. Etc.

And this is _good_. These tools scale cheaply because you make fewer decisions. But it makes them hard to adopt incrementally.