No association with Jetbrains, and despite having a license, don't even use their AI support much myself (mostly using CC, with IDE integration for diff viewing). But if you haven't tried it recently, probably worth a revisit if you're open to Jetbrains products.

Coding was never the most valuable skill a software engineer contributed. Socially-capable engineers are going to be far more likely than PMs to 'shine' when agents can write code and engineers are afforded more time to engage with busines/customers/stakeholder/domain experts.

If my experience is any reflection of the norm, the avg PMs greatest value has never come from effectively determining the value or requirement of a product or translating requests/feedback to meaningful deliverables. It's been in providing cover (time) for engineers that could do the same job better, but are irreplaceable in the development process and so are more rare/valuable spending time doing development. When engineers no longer need to write code, they are a more direct line to effectively solving "Product-Led" business needs with technical solutions than a typical PM will be.

I feel this as well, but I also think it's desirable. Java is slower to add features because the bar is quite a bit higher (especially with regard to backwards-compatibility).

I'd much rather have long previews and occasional removal of previews than have a language that becomes bloated and kneecapped by past rushed decisions.

There's Kotlin, Scala, Groovy, etc, if you want to run on the JVM with languages that offer more features (and footguns). I find the balance OK, personally.

I'd much rather them pull the `STR.` templates than push it forward knowing its not ergonomic in practice.

1. ISPs limiting 3rd party VOIP solutions to avoid competition with their own VOIP solutions

2. Comcast blocking bitorrent communication was pretty obvious case of ISP preferentially limiting traffic

3. Verizon blocking text messages it didn't like the political message of

4. Verizon blocking 3rd party tethering apps, limiting users from using the bandwidth they pay for because they want to prevent competition

5. ATT prevented Facetime over their network unless users paid a higher subscription, even though users were already paying for data

6. Verizon limiting bandwidth for arbitrary reasons during natural disasters (first responders communication hampered due to limits justified through 'we don't need to follow net neutrality anymore')

Those are a few, there are MANY more examples in the US alone. Ya, some or many have been rolled back due to public outcry, but they shouldn't have happened to begin with. Allowing ISPs to determine which traffic is allowed based on their own self interest is just a terrible idea. Just because you haven't been harmed by it yet doesn't mean much, especially not in a country where the majority have only one or maybe two broadband ISPs to choose from. It WILL be abused, and we know this because it already has.

ISPs should be dumb pipes and not much more.

I do agree intellij is memory hungry with multiple projects open and a variety of languages involved, but RAM is cheap enough (and VMs/Docker/K8s hungry enough) that I just don't buy a machine with less than 32GB anyway, so I give intellij up to 6 GB and never give it another thought.

I don't do much android development, but do find Android Studio to feel clunky and slow at times, guessing because of the heavy integration with Android dependencies and emulation, but not really something I know enough about to comment with any sense of authority.

There are definitely reasons why a microservice architecture could make sense for an organization, but "we don't have good application engineers/architects" should not be one of them. Going to a distributed microservice model because your teams aren't good enough to manage a modular monolith sounds like a recipe for disaster.

edit: sorry, this was already said by multiple other people - apparently had an outdated thread in the browser, those comments weren't there when I hit reply!

https://openwrt.org/toh/netgear/r7000

We package Ignition as a docker image, an installer, or just a simple zip archive you can decompress and launch, so it's easy to self-host or deploy to a cheap cloud tier. The biggest downsides are that there will be a bit of a learning curve to using it (as with any new tool), the documentation being focused on commercial use cases, and similarly, we don't offer first party drivers for common home protocols (zigbee, zwave, etc). But we have pretty good docs, a free online learning platform, and pretty active forums. 3rd parties have written various drivers for home use.

I'd love for more in the home automation/maker space to know about and use it. We don't monetize maker edition in any way, and so don't really promote it, but I'd love to see the home userbase grow (and hopefully by extension, the hacker/maker community who might be able to help contribute to drivers and other resources).

It's an open platform built on the JRE, with a public sdk and example modules (plugins) and related tools available on github.com/inductiveautomation. The software is in use to automate virtually every industry, so it's fairly well tested (at least to the extent that a toolkit can be).

Maker Edition info is available at: https://inductiveautomation.com/ignition/maker-edition

Disclosure : work for inductive automation, but otherwise don't have a financial interest in people using Ignition Maker Edition or anything of that (aside from any side effects that come from broader adoption in general). My selfish interest is in a larger home use community so there are more cool projects to check out, resources to share, open source modules published, etc.

All statements here are my personal views.

Not all criminals are deterred by threat of prison, and not all prisoners can be rehabilitated. For those people, jail is simply a mechanism to remove a known threat to society.

In this TB case, jail isn't a threat, it's a consequence that will improve the safety of innocent citizens.

https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...

Yes, it's a minor additional step at first, but it's like 15 minutes tops, and after the first time you do it, you simply copy the xml from project to project if you want to use the same settings.

That said, I loved the keyboardio so much that I recently received the updated model 100, and love it more than the original. The hot swappable switches are great, and the layout is really efficient for me (admittedly, took a frustrating few weeks to get proficient).

Knowing what I do now, I'd personally choose the keyboardio 100 over the kinesis 360, but I'm glad there is another flexible high quality split kb on the market.