It's a good idea, probably less wasteful than heating up an entire room. You could achieve similar results with just a hot water bottle under a blanket in your lap (you are not immune to hot water bottle propaganda).

I don't think I can easily access one because they are not a thing in Europe, so I never tried one, but I did try the hot water bottle thing, and thanks to that I keep my home at 15°C in the winter without trouble, so I halved my gas bill.

They look comfy if you are supple enough to handle sitting on the floor with your legs stretched under the kotatsu I guess. My back and legs would hurt for sure, since I can't sit comfortably on a floor.

I was looking for one for a while, but a lot of Météo France's data has been behind paywalls for a long time until some open data laws changed that, so an official machine-readable format is not what they would tend to provide. Now that feeds considered to be obsolete for the general public because they all moved on to social media and newsletters, it's very unlikely that they are going to consider starting one.

Fortunately I have been going down a rabbit hole (for five minutes a month of course) on an XML standard for alerts that I have seen in use by various weather services or disaster management agencies, which will someday lead to a whole bunch of RSRSSS posts on that standard and its uses. And that got me to find the closest thing to an official feed we can have, since it is provided by a service of the European Network of National Meteorological Services: RSS 2.0, Atom

It reports all warnings in English for all departments. While the website does allow to view the details for each department, that's not handled in the feeds, so you will have to use your feed reader's filtering features to pick what you want.

There is way more involved in programming than just the coding: writing specifications, learning about the problem domain and the users, doing database design, user interface design, API design, software architecture, code reviews, manual testing, automated testing, technical documentation, user documentation, project management, internationalization, regulatory compliance, community management (mostly for FOSS), accessibility design, accessibility testing, deployments, monitoring, and more.

There also are tons of different types of programming that require different skillsets and priorities: web frontends, web backends, web APIs, distributed computing, mobile apps, games, desktop apps, command line tools, drivers, open source libraries, IoT, scientific computing, etc.

In some of those activities and domains, you will also need to split further on the operating systems, programming languages, DBMSes, cloud providers, spoken languages, countries, target users, and whatever else.

Many still think programmers can do everything in every domain and technology at once, when this actually involves hundreds of different skills. This is one factor in many that make muggles non-technical people expect all computers to not work and to only hinder their lives.

So the term programming is quite unclear, and you will first have to split this up into many parts and figure out which of those you want to actually master. I'm not saying you can only master one of these, I'm just saying these likely need to be handled separately. I certainly don't think you will live long enough to master them all though.

You also need to define for yourself what mastering means. Whether you see programming as an art form, as a science, as a field of engineering, as a job, or as something else I didn't think of, can change that significantly.

Then, what you should actually do really depends on what you picked, and I don't know everything about every option.

If you are trying to code a resilient server, you could first write it while assuming that everything will always go right. Then you could bring down a database that your program relies on, then start your program. If it fails, fix it, and try again. When your program at least gracefully handles this situation, you could try to start it while the database is running, and nuke that database while the program is running, which could introduce more failure modes. Or you could cause deadlocks, introduce random lag, or make the database read-only. And continue with other dependencies and other failure modes that you can imagine from your code.

If you run out of dependencies that you can mess with, try to dig deeper into the dependencies that you are not seeing; what if you just lose power then restart? What if you remove some kernel module that your program needs? What if you time travel (change the system clock or go through leap seconds)? What if you run your program in every locale? What if multiple instances of your program are running? Did you try to run a static analyzer to see if it complains about something that could go wrong? Did you try to run every single tool you can get your hands on that could help with resilience, to see if they complain about other things?

When you think you have done all you possibly could on this poor piece of code, update it. Add some requirement, something that requires changing that code, not just working from scratch, and test again. Did you reintroduce bugs? In my experience, updating existing code requires more skill, especially when it comes to other people's code or old code, and that's the thing we should be doing the most if we want to improve our coding.