The museum has been closed for a while due to… a fire. :( Fortunately not too much damage was done and they say it will reopen at some undefined point in the future.
The dinos are getting a bit of love too at the moment it seems (was there last weekend and there is some construction going on the island and the lake around it.
A lot of people don't realize that all these so-called issues with TCP, like slow-start, Nagle, window sizes and congestion algorithms, are not there because TCP was badly designed, but rather that these are inherent problems you get when you want to create any reliable stream protocol on top of an unreliable datagram one. The advantage of QUIC is that it can multiplex multiple reliable streams while using only a single congestion window, which is a bit more optimal than having multiple TCP sockets.
One other advantage of QUIC is that you avoid some latency from the three-way handshake that is used in almost any TCP implementation. Although technically you can already send data in the first SYN packet, the three-way handshake is necessary to avoid confusion in some edge cases (like a previous TCP connection using the same source and destination ports).
They also tend to focus on bandwidth and underestimate the impact of latency :)
Interesting to hear that QUIC does away with the 3WHS - it always catches people by surprise that it takes at least 4 x latency to get some data on a new TCP connection. :)
Quick look: GSLB (via Akamai) for low latency, tricks like using CSS sprite to serve a single image in place of 20 or so for fewer round-trips, heavy use of caching, possibly some service worker magic but I didn't dig that far. :)
Basically, looks like someone deliberately did many right things without being lazy or cheap to create a performant web site.
An important dimension that is not really touched upon in the article is development speed over time. This will decrease with time, project and team size. Minimising the reduction rate may require doing things things that slow down immediate development for the sake of longer term velocity. Some examples would be test, documentation, decision logs, Agile ceremonies etc.
Some omissions during initial development may have a very long tail of negative impact - obvious examples are not wiring in observability into the code from the outset, or not structuring code with easy testing being an explicit goal.
Even as a solo developer, I can swear by decision logs, test and documentation, in that order. I personally keep a "lab notebook" instead of a "decision log" which chronicles the design in real-time, which forms basis of the tests and documentation.
Presence of a lab notebook allows me to write better documentation faster, even if I start late, and tests allow me to verify that the design doesn't drift over time.
Starting blind-mindedly for a one-off tool written in a weekend maybe acceptable, but for anything going to live longer, building the slow foundation allows things built on this foundation to be sound, rational (for the problem at hand) and more importantly understandable/maintainable.
Also, as an unpopular opinion, design on paper first, digitize later.
Right, an important part of keeping in mind other future developers working on your codebase. You 6 months later is that other developer once the immediate context is gone from your head. :)
This is not true - one day you will be dead. Hopefully that day is a long way away but it will eventually come around.
It is good to keep this in mind and spend some time coming to terms with this. If you do, the problem this article talks about will naturally fall away.
Realise and acknowledge the limitations to your ability to act. Then consciously make a choice as to what you spend your limited time on and don’t worry about the rest.
In my experience it only works if you pull in juniors into strong teams and keep the proportion of juniors reasonably small. You also need to have a process in place for training them - it’s not enough to rely on ad-hoc mentoring from peers.
If you get the ratio wrong, with too many juniors and weak technical leadership then you will end up in a very bad place in your code base.
In terms of value, even if juniors are half the cost, it is much wiser to hire one senior instead of 2 juniors for the same money.
> it is much wiser to hire one senior instead of 2 juniors for the same money.
Maybe in terms of pure productivity, but if you can match hiring to roadmaps you can give them more approachable/further from revenue work for which seniors would be an overkill. Etc. I'm just saying anyone with a simple explanation is only telling you part of the story.
Besides, hiring is expensive. If you say live near a university, you have an edge in finding talent.
> give them more approachable/further from revenue work for which seniors would be an overkill
My experience suggests there is no such thing. There is work that seniors might not want to do, but if you hired well then they will be professional enough to do it, if it really needs to be done. And it takes some experience to determine which “non-revenue generating” work (e.g. tech debt) actually needs to be done, to advocate doing it to the stakeholders and to actually do it well.
Juniors need a lot of supervision and that is not free. Which is not a reason not hire them in the first place, just that that it should be done mindfully.
>which “non-revenue generating” work (e.g. tech debt) actually needs to be done
This mentality is part of the problem. You can't fundamentally treat juniors as a profit center. Especially in more niche fields. They need to be trained and schools don't cover your specific pipeline.
maybe it doesn't "need" to be done, but some refactoring work will pay off to turn your juniors today into seniors tomorrow. If you can only think in productivity charts, then you don't hire juniors.
The Subway has recently been refurbished and looks nice. :) https://www.crystalpalaceparktrust.org/pages/crystal-palace-...
The dinos are getting a bit of love too at the moment it seems (was there last weekend and there is some construction going on the island and the lake around it.
It’s a very nice park to visit. :)
reply