chriskrycho

8 ms·

31.
by chriskrycho 3y ago
They started a rewrite-from-scratch of all the apps, including mobile, using a custom in-house server-driven UI framework with a Kotlin DSL backing it, without so much as doing a proof of concept to find the tricky parts first. And by “st
32.
by chriskrycho 3y ago
This is a reasonable take, and I mostly share it. None of us were especially happy about that plan! However, and I alluded to this on the episode, it wasn’t actually a five year plan to get to a very specific endpoint. It was, instead a 3–
33.
by chriskrycho 3y ago
For what it’s worth I don’t think what you’re describing here is the same thing I meant by “finger guns” at all! What you’re describing looks to me like good incremental development. With my “fingers guns mode” phrase, I really had in mind
34.
by chriskrycho 3y ago
LinkedIn actually chose Ember well before React had won, and definitely before it had become the new “no one gets fired for buying IBM.” That all preceded my time there, but the evaluation was late 2014 and the LinkedIn.com web app rebuild
35.
by chriskrycho 3y ago
This is a great summary. Obviously I bring my own perspective to this, because, well… it happened to me, and I “lost”. But my read was that the folks I disagreed with and ultimately parted ways with were falling into the bucket you label ‘t
36.
by chriskrycho 3y ago
There's an element of truth to this! I alluded to this (and Adam totally reasonably cut even more of it for time) but I definitely was not as effective organizationally as I could have been; that is one of the major things I learned fr
37.
by chriskrycho 3y ago
Might have been a lack of clarity on my part. When you split, you are actually choosing "what goes first". The issue workflow-wise today is primarily a lack of tooling designed to represent this process visually in an easy way.
38.
by chriskrycho 3y ago
Ah, you’re right. I will try to clarify that in edits tomorrow or Monday. Thanks for flagging it up!
39.
by chriskrycho 3y ago
I initially thought the same but have come around. The problem at this point is the lack of tooling that understands and supports it. You could, quite reasonably, say they should have made a different choice based on what works best with to
40.
by chriskrycho 3y ago
This is a fair criticism. I struggled with how to organize that section and I might go back and add an example of what I meant, or even pull that phrase out (it’s actually from a much earlier version of the piece when it was more experienc
41.
by chriskrycho 3y ago
The first couple weeks there was definitely some friction, especially because having the working copy be a commit itself takes some real getting used to. Once I got over that and learned that I did not need to name every branch and could ju
42.
jj init – getting serious about replacing Git with Jujutsu(v5.chriskrycho.com)
142 points by chriskrycho 3y ago|110 comments
43.
The Wizardry Frontier(v5.chriskrycho.com)
3 points by chriskrycho 3y ago|0 comments
44.
Typing fast is about latency, not throughput(two-wrongs.com)
271 points by chriskrycho 3y ago|220 comments
45.
A better explanation of the Liskov Substitution Principle(hillelwayne.com)
4 points by chriskrycho 3y ago|0 comments
46.
by chriskrycho 3y ago
Note that while a lot of people do it this way, my blog post this discussion is notionally about on expressly argues that that’s exactly what not to do!
47.
by chriskrycho 3y ago
This is true, but: it’s far easier to get there once you have gotten types in place in the first place—because that kind of domain modeling very often entails non-trivial refactoring work. Our guidance to folks when I was at LinkedIn was th
48.
by chriskrycho 3y ago
The specific thing you’re asking for there is possible but non-trivial if you try to do it at runtime with tools like Playwright; more importantly it’s more overhead than you really need, and runtime types are often not exactly the same as
49.
How to Do a TypeScript Conversion(v5.chriskrycho.com)
103 points by chriskrycho 3y ago|45 comments
50.
by chriskrycho 3y ago
Author here: This specific example is a perfect case of the thing the post calls out! API boundaries are one of the most important places where we need to maintain invariants about our code base, one of the most important places that it
51.
Where DRY Applies(v5.chriskrycho.com)
1 points by chriskrycho 3y ago|3 comments
52.
An Observation on Programming Pedagogy: textbooks and practitioners(v5.chriskrycho.com)
3 points by chriskrycho 3y ago|0 comments
53.
Oxidizing OCaml: Data Race Freedom(blog.janestreet.com)
6 points by chriskrycho 3y ago|0 comments
54.
by chriskrycho 3y ago
This is a totally reasonable response! So let me elaborate a little on how these things can be true at the same time. 1. Imagine a scenario where there are two versions of an API: one is bug-prone, the other is “correct by construction”—you
55.
by chriskrycho 3y ago
The trick is that in many cases the value delivered is invisible and unmeasurable. How do you quantify “time saved by not having bugs”? But that is what great maintenance does. Or, the same for “time saved by a really well-designed API that
56.
Use web components for what they’re good at(nolanlawson.com)
99 points by chriskrycho 3y ago|70 comments
57.
Compile-Time Checked Truth Tables(blog.ploeh.dk)
72 points by chriskrycho 3y ago|19 comments
58.
Optimize the Expensive First(two-wrongs.com)
2 points by chriskrycho 3y ago|0 comments
59.
Goals and Failure Modes for RFCs and Technical Design Documents(medium.com)
1 points by chriskrycho 3y ago|0 comments
60.
Removing Randomness with LDDB(bryce.co)
1 points by chriskrycho 3y ago|0 comments

More ›