To me React hooks look like they want to be a different programming language while still using js-syntax. It would be great if "useState", "useMemo" and the like would be first class citizens in a PL.
Hooks as they are have some non-obvious rules which can make them hard to understand / learn. Also debugging is not great (but that's true for react in general, imo)
You should check out Redux if React seems alien in its own language. This entire stack pretends to be something non-imperative javascript, but at the end of the day just offloads all the burden of writing few layers of abstractions by hand on developers.
Judging from the downvotes, a good portion failed at thinking about it. Answer:
In the 20th century, we commonly expressed the year by its last two digits, you know this is why we talk about "70s", "80s", "90s". It's a small number, not ambiguous, and it also happens to be "the number of years since 1900". So of course a computer in the mid to late 20th century would choose this base. IT means the number is convenient for display, but also works for the machine, because "years base 1900" is a valid machine model as well. And it became a popular time format others picked up.
Lo and behold, though, the world didn't end in 2000. What do we do? Well, let it go over 99 and we add "1900" to it for display purposes, so we can maintain BC.
There. That's why we didn't choose any other base from 4.3 billion years or whatever.
I've made the opposite experience (in germany). No company will ever fire anyone. If they really need to, they give you a generous leaving package. The only exception is if the company going bankrupt, in which case the state might help (Kurzarbeit or bail out).
sounds like an ideology lock-in. Let's hope you never get a problem which does not fit your current architecture well, or else you'll end up spending weeks or even months solving an otherwise trivial problem.
I've worked with "configuration-based implementations" and in my experience they are hard to work with (no debugging, incomplete documentation and implementation, little flexibility), require an staggering amount of infrastructure, are hard to test and will approach a programming language over time.
I agree with the concern, but we have had a very long time to refine our architecture. Some would call it an ideology lock-in, I would say we solved our problem domain in a deep and meaningful way and would prefer to stick with these proven approaches. Our entire codebase was rewritten approximately 4 times before we got to the point of being confident enough to push forward with a data-driven/configuration approach.
When you are writing the same business logic hundreds of times and only 10-20 discrete things are different between each implementation, it starts to make a hell of a lot of sense to expose those things as parameters to be configured. It's simple economies of scale at this point for us. Despite our small size, we are trying to get out of a "move fast & break things" startup mindset into a more stable "lets take this to 1k customers now" mindset (we provide a B2B application in a small market, so 1k is a huge target).
For us, our company doesn't become profitable until we can scale our operations by 5-10x without any more headcount. The only thing we could come up with that would allow for this is configuration-driven techniques in which entire customer implementations can be cloned as simple JSON contracts for purposes of bootstrapping the next customer. Developers are removed from most of the product implementation process, and can focus more on core product value which is now levered hundreds of times over due to being exposed as configuration contract.
I am NOT arguing that one should seek out to build a configuration-driven system from day one. That would probably be the biggest mistake you could make. You have to already have a mostly-functional product that people already want to buy/use before you can even consider this approach. Even then, you should probably expand your target market and inject a few more use cases & rewrites before you jump over that chasm. Having a squeaky-clean domain model that addresses all potential use cases is the bare minimum prerequisite, IMO.
if you write "hello" and they answer "hello", they are under some social obligation to answer rather promptly, whereas if you write your question first, it may simply get ignored. So I tend to write a short hello first.
possibly some other social factors at play here, but still, my experience.
That's exactly the problem, though. You're expecting prompt replies in an async communication medium. Ask your question and then they'll get to it when they have time. If they never reply when you do that then there's a larger issue, but that rarely ever happens. People expecting immediate replies in Slack is a big issue that leads to a lot of unneeded stress at work, and decreases everyone's productivity in the long run.
I dont expect an immediate reply, just within reasonable time. I i've made the experience that a question you ask upfront simply gets ignored and then forgotten.
When that happens to me, I'll give it a reasonable amount of time based on the importance of the question (which could be a few hours or a few days) and then gently prompt with "hey, sorry to bug you, wondering if you had a chance to look at my question?". That has never not worked out for me.
If it's such an emergency that it can't wait, then I can call them. But most of the things we think are emergencies aren't, and most things can wait longer than we think.
