111–120 of 178 posts
I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…
Earlier quoted context omitted.
Well, Javascript is the language that is able to run everywhere, so that's what frontend engineers have to target. There is some more flexibility now with Webassembly... If you are interested, look up Fable, Bolero, Elm, PureScript, ClojureScript, Grain...
All of them don't wash away JavaScript semantics, just because the source language is something else.
This was the case with CoffeeScript. But the examples I gave either work with Webassembly (Grain, Bolero), providing their own runtime, or do some work to hide Javascript's data model to a large degree (F#, Purescript, ClojureScript).
What stays the same is that you are dealing with the DOM, User events occurring there and a metric sh*t ton of asynchronous APIs.
Earlier quoted context omitted.
Not really. Redux doesn't even touch Browser APIs as far as I know. React uses a virtual DOM to avoid DOM unnecessary manipulation, which is slow and error prone. DOM manipulation could be seen as a week point of browsers, and by avoiding it, React is actually a very good ally. Javascript is a dynamically typed language and offers quite a bit of functional programming functionality itself. React and Redux use that to…
> React uses a virtual DOM to avoid DOM unnecessary manipulation, which is slow and error prone. While it may be the case that DOM is far from perfect, React is hardly the only way to avoid it. Even if for your use case avoiding DOM manipulation is necessary (which I strongly suspect is not true for like 95% of people who use React as the framework du jour), there seem to be significantly better thought out approache…
I do remember writing complex JQuery components. React felt like a liberation for me...
I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…
Earlier quoted context omitted.
> What if I wanted to make a program as slow and bloated as possible? That sounds like a very exact description of React/Redux.
We've built a React/Redux application[1] that people keep telling us is very snappy, and we definitely haven't optimized as much as is possible, so from my experience React/Redux is not inherently slow and bloated. [1] https://my.supernotes.app
The first page load is nightmarishly slow. I tend to avoid services that pull in that much data because they're nearly unusable in low bandwidth scenarios (e.g., lots of stores or other commercial buildings made from steel, if you wanted to check a note while travelling, if your customers are among the 5-10% of the USA without home access to top speeds of >1MBps, ...).
As something of an aside, you're hijacking keyboard shortcuts that you don't actually use (at least, they don't appear in the help menu and don't seem to have any effect).
Also, it might be worth considering the privacy of the friend finder. When I add a username you instantly tell me their name if they're on your platform, even before they accept my request. On the one hand that isn't much different from twitter showing your name and handle together, but on the other hand that seems like surprising behavior for a note taking app, even one with collaborative features.
I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…
The reason no one does this is because thr answer is constant "something might fail and add an arbitrary delay" once you hace committed to play the estimation game, you're committed to the delusion and reality checks dont matter. Just stop trying to estimate.
When I worked in security, the first question I always asked was, "how would I defeat this system". When I worked in reliability, my first question was always, "how can I break this?". And now that I'm founder, I ask myself, "how will my business fail".
I know that the executives at a lot of large public companies have an annual exercise where they spend a couple of days just thinking about how the company could fail, what competitors could do that would be disastrous, and then what they can do to mitigate those things.
I also teach my kids these kids skills. When they build something I ask how it might break, or when they are about to do something risky I ask them how it might go wrong and what they will do to make sure it doesn't.
I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…
I didn't used to take this seriously. Then one project I was on was delayed by several weeks when members of the team got jury duty, got injured, and had other medical emergencies in a rather short period.
We still got it done, but I got a lesson that month in planning.
I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…
nobody has permission to think about disasters when estimating project completion time I've been a part of a few large scale system implementations and we documented every significant risk to the project at the beginning and as we went if new ones presented themselves. This seemed to be a standard part of the PM's playbook, and I used to to save critical organizational capabilities when things collapsed: ------------…
I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…
Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.