I generally prefer not to estimate story points or anything similar, but sometimes we have no other option - be that because of stakeholders' expectations, development team's habits, etc. So, if we have to estimate for any reason, then at least let's not put more than a little bit of effort into this activity. I'll explain why I think so using an example which I find to be a really nice metaphor... or maybe something more than just a metaphor.
My kids developed a strong interest in the Roblox games. We had to establish a time limit on the use of our home laptop. Once the limit was set and put into daily use, the kids started to invent, day by day, ways of utilizing the limit in a manner that was most efficient for them. Let me give you a sample of what they came up with during the first week:
Concurrency is hard. Even for those who have been through a university course of concurrency, the alignment of theoretical knowledge with implementations in mainstream languages is hard. I want to tell you about a couple of basic scenarios where mutli-threading may seen like a promising idea to increase a program's throughput and what constraints come very quickly into play, making it more difficult than it might initially seem. I want to do it in an approachable manner, so that anyone with only a basic experience in programming can understand and take advice.
