Santiago Botero

Not surprisingly, another great article from @ploeh Fundamentals blog.ploeh.dk/2024/05/20/fun…

@headinthebox @nikobarli what about F# syntax? additionally, why do you think F# is not more broadly adopted?

dl.acm.org/doi/fullHtml/1… Unfortunately, Rx is often abused for singleton async programming where async await, couroutines, or cheap threads are the right solution. Also, not shown in the 2x2 is that adding backpressure to RxJava was a mistake in my opinion, since in that case you should use async enumerable. Wrt to LINQ, I think the C# syntax is too rigid and hence it is often easier to just use the sequence operations directly. The VB syntax was much more composable and you could stack arbitrarily high. But then MSFT deprecated VB.

One of my all time favorite business books is The Change Function (google.com/books/edition/…). It literally changed my life. Many people use the following "geek" function to predict the success of their disruptive innovation as the following product: P(success) = 10x better * "Moore's law" What you are building is 10x better and you bet on the underlying echnology to rapidly improve over time. There are countless examples of products/technologies falling into the "geek formula" trap. My favorite one is Haskell. Your code is 10x smaller than Kotlin and moreover it is pure, so you will have 10x fewer bugs. And once the new type-checker rolls out, it will even be better. Yet all the Haskell programmers on the planet easily fit in a 737-MAX. I also fell for it myself with LINQ, where I was delusional to believe that it could wipe out SQL, especially once we created LINQ bindings for any data source. Ha, ha. SQL is more popular than ever. The true formula for predicting success is given by the "change function" defined as the ratio: P(success) = perceived customer pain/perceived pain of adoption Customers just want your product to help them do their job without having to learn anything new. You may not think their pain is real pain, but that doesn't matter. And you may think that your product is easy to use, but if the user does not perceive it that way you are toast. Where the 10x better comes and "Moore's law" law come in is to apply address more pain and reduce pain of adoption. So just focus on the boring stuff and sneak it into the user's daily routine.

Holy shit, this article is ☄️🔥 If you read one piece this week, make it this one! @isburmistrov comes from Facebook, where he used Scuba, the progenitor to @honeycombio. He gives a whole 30 second tutorial in why wide events are everything to observability 2.0. open.substack.com/pub/isburmistr…

But more importantly: most of what burns people out is *not* working too many hours. It's things like, * seeing your hard work go unused * working on the wrong thing * long-running, simmering conflict * not being able to fix things that are making your job harder

Life goal: to have a current job interesting and meaningful enough that you want to optimize your technical choices for success in it, instead of its ability to carry you to the next one.

Preach. Or as @jamieedanielson said at kubecon, "if you can log, you can trace." And you should be.

@LerSfy le chap 1 n'est plus dispo, en revanche j'aime le début du 2, ça a un air a ton ancien blog. Je suis d'accord avec quelqu'un qui a dit que la conclusion tombe vite, ce serait beaucoup mieux d'avoir plusieurs histoire pour la conclusion.

@LerSfy très intéressant, l'intro et le contenu à venir !

@LerSfy encore mieux

@LerSfy j'achète de que ça sort !

@LerSfy ça fait peur

@JD_misc @LerSfy quelle fréquence serait considérée une habitude ?

FSharp.SystemTextJson version 1.1 is released! blog.tarmil.fr/article/2023/1… #fsharp #dotnet

@ericmaino amazon.co.uk/Philosophy-Sof… By @JohnOusterhout

If you believe you are following the Liskov Substitution Principle in a class hierarchy, but your naming conventions lead to classes named Abstract* or *Base, then you are not, in fact, following LSP. LSP described a subtyping relationship, which also applies to naming.

@david_whitney @ploeh @JohnOusterhout his*

@david_whitney @ploeh @JohnOusterhout Read the first one, a real gem! will read the one from @ploeh, it's blog is already gold material!

The two most important books about designing software that you should read today are; A Philosophy of Software Design by @JohnOusterhout and Code That Fits in Your Head : Heuristics for Software Engineering by @ploeh The two books I have cheered along to this year 🖤

@davidfowl Is this model able to handle simulations like those simpy is able to model?

Discrete events masquerading as a workflow should be expressed as such. Consider the following event-based model: #dotnet

Story points and velocity: the spherical cow of software jessitron.com/2022/12/22/vel…

Tiny utility functions: keep them local. DRY is for business logic, people jessitron.com/2022/12/19/imp…