ToJans

This feels like Gigerenzer has read my mind. Two weeks back I blogged about a simple heuristic to model uncertainty in software estimates [1], and I received confirmation from several people that my proposed technique might be spot-on: estimate your happy path, figure out how many dimensions your uncertainty has, and multiply the happy path estimates by (sqrt PI ^ dimensions)

[1] https://tojans.me/posts/software-estimates-done-right/

The short description is a bit too short; this is mind blowing!

Redbean is a portable, single file executable webserver which also acts as a zip-file for the static content it hosts, and runs on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS without any recompilation...

You can manage the static content using standard pkzip tooling! Now that's what I call thinking out of the box!

Edited: some rewording and breathing space

In my experience - I have done a lot of pre-sales for an IT service company - the use case for blockchain can usually be solved with classical, cheaper and simpler solutions by having a central trusted authority for storage (like a third-party service provider), and appending using digital signatures.

For me personally, blockchain is a solution looking for a problem in most cases...

Haskell functions are pure, which means they can only access/use what is in their parameters, so unless you pass in some extra context (typically using a monad or an effect), you do not have access to the "outside world".

I can imagine that this has been a huge effort, and kudos to the team, but this is a solved problem; there are ample methodologies to resolve the big ball of mud.

IMHO the shopify team could have saved a lot of time by getting some schooling about strategic DDD, and consulting one or more DDD experts to draw a first version of their context map.

FYI the frustration usually happens between phase 2 & 3 of the dreyfus model... When you realize that you assumed you were an expert, but you were wrong... So keep practicing/learning at that tipping point, afterwards it starts to get interesting... (Similar to the hype curve, "the dip" by Seth Godin etc..) Edit: typo

You become an expert by leveling up in knowledge, let's take a poker game for example:

   0: learn the rules
   1: what do I have
   2: what might the others have
   3: what might the others think I have
   4: what might the others think that I think they have...

You have to evolve through each level step by step, and develop an intuition before you can go to the next level... There are different levels of abstractions in thinking, and experts tend to have been at all levels. To have the best odds of winning, you need to determine the level of your opponent, and pay exactly one level higher.

You can find more info on a similar school of thought by googling for "dreyfus levels of skill acquisition", which explains the 5 levels you have to go through to master something:

   0: What are the rules
   1: I know the rules
   2: I understand how the rules work
   3: I understand how the rules work together
   4: I see patterns and develop an instinct
   5: I understand why the rules are there, and would know when to deviate

If your mind is no longer preoccupied with thinking about the rules, you can start doing other things with your brain, which is why practice is so important.

I actually had a talk a decade ago about this: https://www.slideshare.net/mobile/TomJanssens1/getting-bette...

Edit: updated my last poker rule; it has been a while, and I am typing this on my mobile..

I would suggest having a sensible DAG example in your flows on your homepage. Right now, you are not showing off your USP.

Isn't this strongly related to monads?

Just a short remark: this reminds me of Cobol.

I see quite some similarities with low-code systems, 4GLs, smalltalk etc, so AFAIK the market is there... Please take into account that your target audience probably is not on HN. If I would be you, I would target web agencies, that can use the dark platform as a competitive advantage, if your system allows you to build stuff faster... IMO it does not make sense to learn all these new paradigms for a small project, you really need scale for this kind of investment from your customers... Right now it feels like you are building a solution that does not know which specific problem it is solving...

The author is considering the wrong context.

Services get more fine-grained every year, and composition of these services is where the money will be made in the future. AI might resolve some of the issues with finding the right services for the right use cases & even integrating them.

Custom, home-made services will be a conscious choice, and might be composed of other services that are publicly available or not. Everything else will use off-the-shelf services.

My .02€

On a side note: IMHO this article contains one of the most accessible explanations I have seen about monads.

This post feels like looking in the mirror to me

"all models are wrong, but some are useful" George E.P. Box.

I like the way he presented his explanation, and his approach to finding a solution.

However, listening to some of the songs I would say that he needs to find a better model, or like mister Burns would say: "Smithers, continue the research!".

As an "infrequent developer", I usually piggyback on others to find best practices, in case I have a bigger project. For the tiny ones it simply doesn't matter.

The advantages of being an "infrequent developer" is that you grow an intuition on how to get started with something completely new (cfr. Taleb's anti-fragile), and that you learn a lot from cross-contamination.

Also, others might refer to frequent/infrequent developers as specialists and generalists.

(Edit: reformulation of some Dunglish sentences)

"the chase is better than the catch"

Once you can afford something that was way out of reach before, you buy it and after the first few moments you realize it is not as great as you expected. Do this a few times, and you'll learn what is important. The more wealthy people I know do have a slightly above average car and house, but IME the biggest difference is that they have far more extreme - both in amount and in price - experiences, i.e. weekend trips, fine wining and dining etc.

IME Vue is so well designed, that I hardly have any issues with it. If I do, my go-to reference is the official documentation.

You shouldn't base your usage assumptions on the amount of questions asked; Vue just doesn't require so many questions...

Imagine you are a one percenter: your network will be very large, so why would you take the risk of engaging with someone you don't know, if you have plenty of other one percenters in your network who might have a proven track record?

I am wondering why the author didn't opt for a language/platform with a mature PDF and GUI library?

If I read the article correctly, it would have halved his development time...

TL;DR: this is an approach that simplifies the production of light field cameras (cameras that measure both color and angle of incoming light beams): instead of building a grid of microscopic lenses, you use a "random" piece of opaque plastic like scotch tape, and figure out how it modifies incoming light using a calibration phase.

I think that computation expressions would allow him to do the same in F#?

My Haskell is a bit rusty, but I think the Haskell example could improve A LOT by using monad transformers or a free monad?

Ok, looks like I misunderstood. Thank you for clarifying...

Nitpicking: from an architectural point of view, I don't see why you would opt for "build you own cloud on top of Amazon", as opposed to leveraging the Amazon stack, especially because the author points out it is a small team.

Maybe it's a resource issue, or they need some things that cost too much money on Amazon, but the author should at least justify why kubernetes was chosen.

My apologies for ranting about this, but I've seen this approach way to much, wasting valuable company dollars.

Take it like a man!

Just kidding... Get some good cycling pants, make sure your bike fit is ok, and apply ample amounts of xyz after the ride in delicate areas (for most xyz is chamois cream, but I'm using coconut oil instead).

After a while you get used to it...

Mens sana in corpore sano.

I was losing grip as well this summer, so I started road cycling: only a few km at first, but now I have no issues with doing centuries (i.e. 100km).

I can't give you any guarantees because I wasn't exactly burned out yet, but it helped me big-time, and I've lost some weight and built some physique while doing it.

Some might say there's a nice metaphor in cycling further each time, but you can be the judge of that.

My mind might be rambling 24 hours per day, but when I get on that bike, it takes about 15 minutes and I'm fully Zen again...

Maybe cycling isn't your thing, and you might prefer running, walking or even putty-golf, but try to find something physical and do it for at least 1 hour, 3 days per week...

This might be a bit off-topic, but after gaining some experience, teaching something to others is one of the best ways to reflect on the things you learned and gain new insights. You have to do it first, but teaching stuff will probably provide you with some deeper insights.

With all do respect, I think the author is missing an important point: he is talking about communication, but he seems to be the only one talking... IMHO you should first figure out why it's needed, and optimise for it's use case. F.e. if it's only used once a year and a simple merge+sort takes half an hour, it wouldn't be worth implementing it yourself.

IME good (10x?) developers are way more efficient because they reason from first principles: don't start from the solution space, but from the problem space, and optimise based on constraints and requirements.

When you are learning something new, you will make mistakes. Some mistakes can be cheap, but others can be really expensive. If you do not know what I am talking about Google for "advanced beginner" and "Dreyfus curve of skill acquisition".

I get several job offers per year from my professional network, because I have been doing some things in the past where mistakes were bound to happen. Due to my expertise I am more likely to finish certain projects within time/budget/scope than others.

While it might be a long stretch, compare it to road cycling: who might have the best chances to finish a century (100 mile ride) within a reasonable time:

- someone who has read a lot about road cycling

- someone who has finished several centuries successfully

Practical knowledge tends to be way deeper than theoretical knowledge, and usually gives you the ability to judge whether the theory applies in a certain situation, or it does not.

You can not become a master chef by looking at TV shows, you need to walk the walk...