giulianob

That's a wild statement to me. Even with spending significant time making plans with Opus 4.7 and GPT 5.5 on xhigh, I still find lots of poor decisions made when it actually goes to implement it. I find the quality of PRs hasn't dramatically changed either way because the better engineers will spot the issues whereas others will find what the AI is doing acceptable.

I'm having this exact conversation with senior leadership in my team. I'm looking forward to it and I might do a book club reading when it comes out!

I just started using OpenWrt on Incus via LXC and it works really well. The most difficult part was just learning the config file. It looks like upgrading OpenWrt (esp. on LXC) is the tricky part though so not looking forward to that. I considered moving it to a VM so upgrading it is easier but it runs so smooth on Incus.

I read the first part and I enjoyed it. I agree that us developers aren't great at communicating tech debt effectively. Managers are also not great at prioritizing it. I think the "debt" analogy has been a net negative as management often thinks "we'll just pay it later" but don't often see how much pain it's causing. So having a resource to help both sides on this topic is very valuable.

I just recently got sclerals for dry eyes and I'm still going through the adjustment process. Usually they are prescribed for keratoconus (misshaped cornea) and not something most people need. The doctor actually said it's more challenging putting it on someone without keratoconus (like me) because I am used to having fairly good vision with my glasses and sclerals aren't as easy to get right as glasses/normal contacts. They have been amazing for dry eyes so far though.

You mean `dotnet publish -r linux-x64 --self-contained` ? This will embed the runtime in the executable. You can also do trimming so it removes anything that's not used. Also, there's AOT but it's got a ways to go.

They recently updated it with an official vendor for a [PCB kit](https://www.peakcoffee.cc/product/gaggiuino-v3-kit-set-gaggi...) that (I believe) includes all of the internal components needed. I did the lego build w/ tons of soldering and ordering parts off Aliexpress. This new kit should make it much easier for newcomers. You still need to know what you're doing and it's not for everyone. A machine with similar capabilities is something like the Decent at $4k.

Wat... "Like" implies preference. You're using the word "story" to imply someone pulled it out of their imagination. What they said was "we currently have no plausible theories that doesn't require dark matter". These theories have to be consistent with other theories and observations.

I have coded on .NET in Windows/Mac/Linux. It works equally well in all environments. You can use VSCode, VS for Mac, or Rider. I use Rider in all platforms. It's an awesome IDE.

Source: I work at MS but have used .NET on other platforms at previous jobs.

Actually we haven't evolved to digest milk after childhood that well:

    While most infants can digest lactose, many people begin to develop lactose malabsorption—a reduced ability to digest lactose—after infancy. Experts estimate that about 68 percent of the world’s population has lactose malabsorption.1
    Lactose malabsorption is more common in some parts of the world than in others. In Africa and Asia, most people have lactose malabsorption. In some regions, such as northern Europe, many people carry a gene that allows them to digest lactose after infancy, and lactose malabsorption is less common.1,2 In the United States, about 36 percent of people have lactose malabsorption.1
    While lactose malabsorption causes lactose intolerance, not all people with lactose malabsorption have lactose intolerance.

https://www.niddk.nih.gov/health-information/digestive-disea...

Points are flawed. Whether you have them grow linear, exponentially, or fibonacci doesn't make a difference. The fundamentals are flawed. They cover it in their videos and in more depth their talks/books.

Estimating a single task is only really important to keep your cycle time in check and have the conversation about "should this task be broken down?"

Estimations from engineers shouldn't be used to forecast when a feature will really be done. That's where the model comes in and probabilities comes in.

Definitely my biggest gripe is story points + estimations. It's just completely flawed. We should be thinking more probabilistic (i.e. there's an 80% chance we'll get this done in 2 weeks). We should be doing that by running actual models on past work rather than gut feelings.

If you want to listen to a couple of guys I used to work with who really know what they are talking about, check out this series: https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...

Manufactured? you should really read the Mueller report and see that there was plenty of wrongdoing. Saying it was manufactured is pretending like all of the evidence, meetings, etc... didn't happen.

I've worked professionally on C# and Go. I've seen overly abstracted C# code but I also have seen Go code that was clearly missing good patterns and ended up a ton of spaghetti. The difference that I see is that C# gives you the tools to do it well whereas Go lacks many tools to make a complex code base nearly as maintainable as C#.

I've been using the opentelemetry package for C# to push tracing data to Honeycomb and it's really good. It takes a bit of learning but it's extremely powerful. Once you're over the hump it's very easy to quickly add new telemetry and its night and day difference to typical logs/metrics.

C# has gone completely open source and cross platform. .NET core was essentially a huge modernization of the entire runtime and ecosystem. It's becoming one of the most performant managed languages according to Techempower benchmarks.

You can also see just how much it's improving in some areas and the level of detail they're paying to it: https://devblogs.microsoft.com/dotnet/performance-improvemen...

Wow I'm surprised people are so eager to go back to the office and completely aren't valuing the potential freedom of being able to live where they'd like rather than where their work happens to be.

I'd say ref structs are more explicitly stack allocated since they're not allowed to be boxed. Stackalloc is used to allocate arrays on the stack (or rather a block of memory).

To be fair this is what Electron does too via the browsers. It's just doing it via the worse possible way by leveraging technology that's awful for building UIs. I'm a fan of flutter they're definitely onto something. I hope they can bring it to the desktop in a way that works well too.

You can just make sure to set the low processor mode and you're good. The latest 3.2.2 introduced some fixes which help as well. It will only draw whenever a component actually requests an update.

Just to clarify for those following along. Godot IDE is using the same UI components that you can use in your games. Godot 4 will support multiple windows. They're working on RTL I believe and it actually has a very robust code editor with debugger in the editor. Most of the points being raised here don't seem to be based on actual experience with the framework.

If you use the Godot editor you'll see it's already sophisticated enough for general purpose UI applications. Of course you can keep expanding the requirements until no software in the world meets them but if you know what you're building then it might be the right choice. The main benefit that you won't get with almost anything else is true control over how every pixel gets actually rendered to the screen. It's able to make cross platform applications which since you're in full control over how they're actually rendered gives you tons of control. Resource utilization is fairly low and again you have full control of the stack so it's as good as you're willing to make it. C# is supported nowadays which gives you access to a mature ecosystem of libraries.

Is it the right solution for all UIs? Clearly not but IMO the UI landscape is a mess at the moment for anyone who wants to be able to build cross platform applications. There aren't really any adequate solutions as far as I can tell.

Still don't need microservices. What you're referring to is just SOA which has been around for a couple of decades. Microservices typically outnumber engineers or aren't too far off.

That's what's actually fairly impressive about C# being #1 on plaintext. Both ASP.NET and Kestrel (the frontend server) are both fully in managed code.

Trimming is already supported and they're investing heavily into making it more aggressive. A web app was about 17mb in one of the demos at the conference that I saw. You can get it smaller if you make it more aggressive yourself but you may have to whitelist specific namespaces if it accidentally removes that you're using that it can't detect.

I'm actually a strong proponent of .NET core nowadays but I do agree some of the features being added don't seem to justify additional complexity OR just seem to overlap something you can already do in the language. I would prefer if they were a bit more cautious adding some of the features that are purely sugar.

Your average user has just come expect technology to suck nowadays. Go look around and many people are jaded by how poor things actually function.

Really look at any significant benchmark or what types of projects use which languages. The evidence is extremely clear and makes sense due to how computers work.