apenwarr

16 ms·

91.
by apenwarr 8y ago
I thought his intention was to refer specifically to the group of haters who are lying. There are many people in that group who have strong incentives to do so. That’s to differentiate them from the larger but separate groups of liars, and
92.
by apenwarr 8y ago
The approach recommended in the talk is to use relative size estimates instead of absolute size estimates, which removes the possibility of over-estimating (or under-estimating) or sandbagging. During the conversion phase from relative size
93.
by apenwarr 8y ago
No offense taken. The wifi project was indeed very hard, but I think we moved the world forward at least a little bit. If you're really interested, you can find out more about how we did it in my recorded talk here (although the slid
94.
by apenwarr 8y ago
Of your proposed motivations, I’ve been accused of all three but it’s probably the third one :) — the author
95.
by apenwarr 8y ago
You’re unlikely to experience bufferbloat at gigabit speeds, for the simple reason that your buffer will empty at gigabit speeds, which is about as fast as you can fill it.
96.
by apenwarr 8y ago
apenwarr has very little to do with OnHub. That said, OnHub is a wifi/firewall/router, and the bloat is in your modem, not in the router. OnHub can’t fix that unless it uses a configurable token bucket like in the article.
97.
by apenwarr 8y ago
If you click through to the actual paper at the bottom of the article, the methodology here is just astonishing: they start by, without evidence, asserting that the main thing fork() does is to insert and remove processes from a list of pro
98.
Techniques for vertical storytelling(webtoons.com)
163 points by apenwarr 8y ago|23 comments
99.
by apenwarr 8y ago
Here’s a tool showing basically all the factors affecting maximum speed with traditional tcp: https://wand.net.nz/~perry/max_download.php In short, the higher the loss, the slower it goes. The longer the rtt, the more
100.
The four motivators (2016)(apenwarr.ca)
78 points by apenwarr 9y ago|14 comments
101.
by apenwarr 9y ago
That's actually a misrepresentation. TCP actually works pretty well on crowded networks; a major feature of TCP is to avoid congestion collapse. It doesn't always fully saturate busy/lossy networks, which is an area for imp
102.
by apenwarr 9y ago
It's being actively discussed at the IETF. Here's a doc that's last updated 2018-01-28: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
103.
by apenwarr 9y ago
This is a pretty disappointing article. It's really comparing a particular implementation (or maybe multiple implementations) of TCP congestion control, implemented in kernel space, with a particular implementation of QUIC congestio
104.
by apenwarr 9y ago
You and your S.O. are conflating gender identity, physical gender, and expression. Basic transgenderism is very simple: the uncanny feeling that your physical gender is wrong. You have male parts but they don’t feel like they should be ther
105.
by apenwarr 9y ago
You're right, those two points are inadequately covered in the article. Thanks for reading so carefully :) Story point size: the usual thing to do is to have "baseline tasks" (which the whole / almost the whole team did
106.
by apenwarr 9y ago
If you look at the first Central Limit Theorem slide in the original article, it compares story precision vs precision of unestimated bugs. The short answer is that if your stories are big, not estimating them causes more error (weeks or mo
107.
by apenwarr 9y ago
Yeah, this is why I don't prefer the common "effort vs time" distinction. Instead I like to think of "relative size of task," which is a very easy concept for most people to intuitively understand. It's fairl
108.
by apenwarr 9y ago
I think we agree here, except on definitions. To me, potential "methods" are the list of things you describe: taxes, classrooms, teachers, home life, baseball bats. And also the ones I described: teach to the test, fraudulent sc
109.
by apenwarr 9y ago
I know what you mean, and in general I try to follow that advice. In the particular case of project management though, I'm frustrated by the huge amount of too-short and contradictory advice floating around on the Internet; adding one
110.
by apenwarr 9y ago
In my opinion (and you should take it as an opinion :)), the "good parts" of Agile are the same for both software and non-software projects. Estimation, strict prioritization, and (automated) progress tracking are the keys to any
111.
by apenwarr 9y ago
The way I like to do it is to keep multiple backlogs, broken down roughly by feature group (ie. groups of things that might eventually become a milestone or story of their own). Then when I decide to prioritize a given story, I can go to
112.
by apenwarr 9y ago
What all these wrong-goal examples have in common is that people have tried them over and over, and they never work the way you want. The reason they never work is that they don't specify the method. As one of my favourite Deming quo
113.
by apenwarr 9y ago
I quite liked the tl;dr, except that it left out how most of the article is "...and why". We've all heard the advice, but the article is trying to explain why the advice is true. I think an ideal summary would mention that.
114.
by apenwarr 9y ago
No, I've never seen it enforced by tools. Physical (index cards) kanban boards have an implicit space limit though, and this is one of the too-seldom-acknowledged reasons why they work as well as they do. Unfortunately the software c
115.
by apenwarr 9y ago
That's basically what the entire article is about. The (very) short version is it really is possible to predict when things will be done, but if you tell the engineers or negotiate with the engineers (ie. turn it into a deadline), tha
116.
by apenwarr 9y ago
I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.
117.
The four motivators (2016)(apenwarr.ca)
1 points by apenwarr 9y ago|0 comments
118.
by apenwarr 9y ago
Of course. That's why you need regulations, not billionaires, in both cases.
119.
by apenwarr 9y ago
Removing the calls to existing malloc on an embedded system would be trivial. Just point it at a predefined RAM area instead. It uses malloc only so you can play with it on a full featured OS, not because they left something out.
120.
by apenwarr 9y ago
Look up "buddy system allocator." The algorithm is super fast and easy to understand and implement. It was also the one used in the very first Linux kernels (probably for those reasons).

More ›