My experience (as someone who spends too much time on my phone) is that a smartwatch helps avoiding me getting sucked in by my phone.

It’s much less usable and I hate constant notifications on my wrist, so I’ll usually have it on mute and do a quick check at my notifications occasionally to see if there’s anything urgent (usually work or a message from my wife).

I’ll mostly ignore my group chats on WhatsApp and emails, and there’s no risk of me getting sucked into group coversations with friends, YouTube or the Internet (I don’t have social media apps on my phone so that’s not too much of an issue), which is where the real time sink is for me.

> for example, the same several lines of code duplicated across distant parts of the codebase dozens of times, and with inconsistent names which make the duplication hard to notice or track down

While I think there’s merit in deduplicating these situations, one pitfall is introducing coupling and tangled dependencies when DRYing.

There are ways around this of course, but I’ve come across a number of instances where deduplication has led to unnecessary coupling between modules.

I’ve found Angular updates to be mostly painless since they’ve automated most of the migrations using `ng update`.

That said, I do wait 2-3 months to give time for dependencies to update.

My apologies, I assumed your lawn was Open Course.

Lol, it is, help yourself to an apple from the tree too (the birds seem to have had them all though).

Curious if anyone familiar with Drupal’s AJAX implementation (at least how it was in v5-7, I haven’t used Drupal v8 onwards) back in the day and has used this can offer a comparison?

A sense a lot of familiarity

Ah… IB must’ve been why I found the discrete mathematics subject at university so much easier than my peers did - I’d already been exposed to a lot of it.

We do this occasionally as a tech spike - if there’s a lot of uncertainty or if we need to evaluate between a couple different approaches, we’ll dedicate 2-3 days to hacking away with the aim of lifting the “fog of war”.

Can you elaborate on what’s problematic with this test? Testing that the component does what expected based on input is telling me the component is working as expected.

The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.

Part of the complexity of integrating a form library with a ux library is passing all of the correct properties around between the two. In this case, I wasn't doing that correctly and it resulted in a bug where disabled was not being set correctly. Someone filed a bug. The bug was fixed and a test was written to ensure that this doesn't happen again in the future.

You can read the history here: https://github.com/lookfirst/mui-rff/issues/455

If you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. Not all code gets 100% coverage and sometimes things get missed. That is ok. What is not ok is skipping tests because you might forget something and therefore think it isn't worth writing tests at all.

I consider buggy code the act of developers writing the code at least 2x instead of 1x. If you or your company is paying someone $X a year to write code once and they are actually writing code more than once, then I would highly suggest you look for new people to work with because that is a terrible return on investment.

If your developers are writing tests, along with their code, then the code is far more likely to be correct and better thought out and less buggy than code that was just hand tested as they developed it. Speaking of that 2x example, I'd rather pay someone 2x the amount of time to write code, with tests, than the other way around.

> if you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it.

We all write bugs, we're human and it's hard to think of everything all of the time.

My point was, when we make a thinking error that causes us to write a bug, that same thinking error means we also don't write that test that could find it. If you had thought of writing a test for the disabled thing when you wrote the code, you also would have written it correctly because you would have had that case in mind then.

Now you have a test, but because someone reported the bug and you fixed it. Now it's almost certainly not useful to have anymore.

I believe in automated tests, but for tricky logic mostly.

If you practice test-driven development, the mindset is slightly different.

Humans can't think of everything all the time - TDD guides you to think about one thing at a time.

No one is sitting there adding a disabled prop on their component that then disables an input for no reason. You had intent when writing it. It's possible that a co-worker distracted you, or you went for a break, or you went down another rabbit hole, and ended up skipping disabling the input based on the prop.

If you're practicing TDD, you would have written a failing test before creating the disabled prop. That test will continue to fail until the productive code has been written. It helps to protect against those thinking errors in the first place.

I am all about TDD, but in this case, I'm integrating two third party libraries that have many many features.

There is almost no way to even know what features they have, especially over time. Imagine that MUI added disabled in a new release and now my project isn't implementing it during an upgrade. TDD wouldn't have caught that.

An example where it’s helped me personally is when migrating from Angular Material to Ant Design. The test cases gave me confidence the expected behaviour was preserved

Very good example. Tests are all about 'delta'. Changes over time. They bring confidence over delta.

Is this an issue with observables or an issue with RxJS allowing you to shoot yourself in the foot?

A saner API (as shown in the proposal) has some obvious benefits in handling certain use cases without necessarily devolving into the crazy streams one sees with RxJS.

Any plans for supporting Jetbrains IDEs?

Focusing on VS Code for at least the next few weeks, but we've planned from the start! You can read more here (https://continue.dev/docs/how-continue-works), but the Continue server abstracts over the IDE APIs, so it will be easier to support any IDE, even letting you run Continue in "headless mode" from the a Python script, the CLI, or in CI/CD.

I use both pycharm and Webstorm, so an extension would be great! On the plus side, since they are all basically reskins of IntelliJ, one plug-in should work for all of the jetbrains suite.