soonnow

To add a b it of context. They do not want to confiscate housing. They do want to pay landlords, though below current (very high) rates. Also this would only apply to private real-estate companies not individual owners.

And they can't govern alone, so I think it's unlikely that this plan is actually implemented as originally planned. The likely coalition would contain 3 parties.

As a former manager, I am sorry, but the last paragraph just sounds like normal rookie team members.

Including myself as well. It's how you grow into the role.

I'm the same as you. Very specific tasks. Just now I spent two hours in a conversation with claude code to change 5 lines of code that change a significant semantic.

On the other hand my buddy is spending $10k in tokens a day on agents to build something. He's a very smart guy, former developer so it's not just AI psychosis talking.

Still trying to figure it out. Not that I have $10k to spend.

Yeah I heard a similar thing recently at a presentation. At that point wouldn't it be easier to just send the prompt around?

I see even smaller companies ask for that. Less about cost, European companies have a deep mistrust of US companies at the moment. I see companies a tenth of your companies size ask about local models.

I just want to point out you are saving 3 characters on the last one while making it a fair bit harder to understand. fileName is perfectly fine. fName could be firstName, fileName, finalName, foundName...

We used a small embedded db in our desktop product only for durability and SQL semantics. After we got multiple database corruptions we switched to a small file based store written in Java with simple DB semantics.

Looking carefully at what happens when data is lost we found that it's basically all recoverable.

This lead to an amazing performance, as data is flushed only when necessary. We flush only every 10 seconds now or when the write through cache is full.

My lesson learned from that is to carefully think about the actual requirements when it comes to transactions and having loose constraints may be the quickest way to speed up performance.

For many applications even a second or two of lost data may not be a big issue.

I think AI is going to be the driving force behind technological innovation for at least the next 10 years. And the US has that market cornered expecially with the CHIPS act. I think that will drive growth in the US and be more relevant than the reserve currency status.

Can I just say that aside from the presented facts. I really liked the reporting. It clearly explained what the study showed and what the studies didn't show.

I think science reporting should be more like that. It's ok to have an article that says well we found a link but we are not clear yet on what's the exact cause, but we know what's not the cause

Aside from the clickbait-y headline of course.

I'm using C# and Java professionally. I've been using for a long time while I'm newish on C#. Also I'm on a older version of .net vs. a modern Java. Honestly to me the language doesn't feel that great. It always feels sluggish, to work with, like I'm fighting against the language. And then there is the ecosystem, Spring Boot is just such a breeze to get a web app running with all the integrations you could ever want being just there. Add in Lombok and Apache commons and it's a real pleasure to develop in Java for me.

But these executables are quite huge, are they not?

It offers the benefits of bitcoin (as a money transfer mechanism) without it's downsides.

For example it reduces the costs of international transfers as well as the ease of doing them. Swift transfers are not fun and easy to get wrong and fairly expensive.

And with Bitcoin you'd end up with the currency exchange twice and then the gas or transfer fees.

Also payment in bitcoin fluctuates so you'd have to write the invoices in BTC, which is not that useful. But companies writing invoices in USD are common enough.

Your comment is fascinating especially since I've been thinking about digital transformation and what it means for businesses a lot, lately.

I would like to make one point that I would highly recommend in respect to a lot of people unhappy with Agile methodologies.

I suggest picking a method, let's say Scrum and really implementing it as recommended. Get a coach if necessary. Try to experience it first before making changes. I think for example the self organizing team has to be experienced rather than read.

Only once you have done it, by the book, start making changes and improve the process.

Don't fall into the trap of reading about Scrum, thinking well I don't need retrospectives they are dumb and do your roll your own thing.

Understand what Agile is, rather than follow some cargo cult interpretation.

This will lead to dark agile, or agile in name only, where you do waterfall but with daily standups.

Which I think explains a lot of the unhappiness people experience with Scrum.

> Rather than giving some finger in the air estimate, you need to explain that until the precise requirements are known, solution devised, and backlog estimated, you can't give a precise estimate

You make a lot of good points but I disagree with this one. I understand the need for business to know how much a project will cost, but I don't think there is any other way than finger in the air. Or rather looking at a project of similar scope and going from there.

The core of agile, for businesses, in my opinion is to deliver business value in the shortest amount of time. Changing requirements are not a bug but a feature of Agile. But you can't estimate for the unknown.

Let's say you are building an app for a bank that allows customers to leave comments on merchants as an option, three menus down. Turns out your customers love that feature and the bank decides to promote that feature.

This business agility is at the core of digital transformation and it should not be discussed away as not being part of the original requirements. Rather it should be embraced.

But you can't estimate the unknown. And I have in my life never seen a project that didn't have wild changes in requirements along the way.

So in my opinion you may as well throw out a number based on experience. Deep estimation based on Excel sheets and task completion times are not gonna improve on the result.