* If the cold war had turned into a hot war, almost all of Germany would have been nuked. The expectation was not to be able to stop the soviet invasion, but to nuke them in western Germany.
EDIT: The reaction of the state also caused an escalation. The constitutional court blocked governmental overreach: https://www-bpb-de.translate.goog/kurz-knapp/hintergrund-akt...
This also lead to the anti nuclear movement being about more than just nuclear plants, but rights for citizens.
If it was only "my" system without any integrations, I might agree.
But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ...
Upwards there is an ERP integration (and some other systems).
Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese.
The ERP has the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.
Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.
Sometimes the on-premise network stops working for whatever reason and data is lost.
Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."
So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.
And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.
Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.
There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.
Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.
"It’s about attention and understanding. To keep my attention, I must go beyond ‘read code’ like a passive observer of agents from afar. To really connect with the architecture of the system, it helps to truly experience the code"
I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subconsciousness makes most of the decision ("this just feels right"). But for this to work you have to train it. And this does only work in a very limited way with code reviews or reading documentation. It requires repetition and deep focus.
When there is an issue in production with this mental model you will be able to point to the cause of an error message instantly. With generated code you'll search for a long time with your slow, conscious part of the brain.
For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works. Otherwise this will always be problematic.
Keypoint: "Co-founder Larry Ellison has fallen behind the Google co-founders, Amazon’s Jeff Bezos and Michael Dell on the list of the world’s richest people."
Yes, this is the important question of our time. Who is highest on some imaginary list of value?
My problem with AOP has always been that it makes the simple case trivial and the hard case much harder.
Looking at transactions: The 99% solution is trivial: Every service call is a transaction. AOP can save me a few lines for every method and things look much cleaner.
But then comes the huge excel upload that is performance critical. Batch more service calls to fetch additional information in the background, commit every so-and-so records in a loop depending on the data size, do a custom roll-back if things fail.
And suddenly this whole separation of concerns breaks down and creates a huge mess.
The simple case saves a few minutes, the complicated case causes weeks of depression. Not a good tradeoff from my experience.
An LLM adding to the confusion by only sometimes getting things right and explaining that the separate documents are always valid, except when they are not, well, sounds like a fun experience.
Nuclear in 2006 was 160TWh. Coal in 2025 was 93TWh. So a big portion of nuclear would have been replaced by renewables by now anyways (natural gas has a different role in the grid and cannot be replaced bu nuclear).
Also a lot of coal plants have been / are used in district heating in addition to electricity. Replacing them is much harder and takes longer than nuclear which is electricity only. Shutting those down was never a short term option.
Calling it the worst decision ever is really funny, when it really is just a question of the order of the transition to renewables. And much of that order was dictated by technical needs.
Heat pumps and electric cars are so much more efficient than ICE engines or gas heating. This is why the share doesn't change a lot. Even looking at consumption in Norway: https://robbieandrew.github.io/EV/img/NORenergy_road.svg You don't see the electric share going up a lot. Still oil consumption is collapsing-
I write code. On a good day perhaps 800-1000 "hand written" lines.
I have never actually thought about how much typing time this actually is. Perhaps an hour? In that case 7/8th of my day are filled with other stuff. Like analysis, planning, gathering requirements, talking to people.
So even if an AI removed almost all the time I spend typing away: This is only a 10% improvement in speed. Even if you ignore that I still have to review the code, understand everything and correct possible problems.
A bigger speedup is only possible if you decide not to understand everything the AI does and just trust it to do the right thing.
I guess everyone dealing with legacy software sees code as a cost factor. Being able to delete code is harder, but often more important than writing code.
Owning code requires you to maintain it. Finding out what parts of the code actual implement features and what parts are not needed anymore (or were never needed in the first place) is really hard. Since most of the time the requirements have never been documented and the authors have left or cannot remember. But not understanding what the code does removed all possibility to improve or modify it. This is how software dies.
Churning out code fast is a huge future liability. Management wants solutions fast and doesn't understand these long term costs. It is the same with all code generators: Short term gains, but long term maintainability issues.
That is a completely different level. I expect a Junior Developer to be able to completely replace me long term and to be able decide when existing rules are outdated and when they should be replaced. Challenge my decisions without me asking for it. Being able to adapt what they have learned to new types of projects or new programming languages. Being Senior is setting the rules.
An LLM only follows rules/prompts. They can never become Senior.
A Junior programmer is a total waste of time if they don't learn. I don't help Juniors because it is an effective use of my time, but because there is hope that they'll learn and become Seniors. It is a long term investment. LLMs are not.
I didn't want to put the usability of the motor into question or go into a complete evaluation of advantages/disadvantages :) This was just an explanation that weight trimming the motor might be very much worth the effort - even if it somewhat "insignificant" compared with savings that are possible in battery weight.
The issue with this type of motor is that it is part of the unsprung weight since it is inside the wheel. This is probably why savings here matter a lot more (or at least in a very different way) than the battery weight.
"In the era of AI and data-driven enterprises, reducing architecture debt will no longer be a technical choice. It will be a strategic differentiator that separates the companies that can transform from those that will fall behind."
Yeah. Whatever.
How is AI even related to architecture debt in software? By vibe coders forgetting to specify "decent architecture" in their prompt?
Same for data driven. For most companies data driven just means focusing on one more or less relevant metric, but ignoring all rational arguments on topics cannot be measured in an easy way. Leading to short term thinking and optimizing for a metric instead of for business success. Not great, but still not a lot to do with software architecture.
And as much as I'd love software architecture to be a strategic differentiator: It really is not. Companies need software that is good enough. Good and consistent architecture just lessens the developers pain in dealing with it (and technical/architecture improvements are much more fun to do, since there is no customer with strange requirements). There are many companies out there with horrible software quality that still succeed.
And gas plants are what is closed to H2 and can be switched over easiest. But H2 is only viable once renewable production exceeds demands during long stretches of time. Otherwise it is always better to use the energy directly or use short term storage (batteries) which are also growing exponentially: https://battery-charts.de/battery-charts/
Sorry, you are all emotion and provide wrong statements. What I wrote directly contradicted your statements and proved them wrong, but now you say they are missing the point? Reducing fossil fuel consumption by 50% within 10 years is an achievement. There are always things that could be done in a better way. But let's be real here.
That is kind of the point of having an integrated grid.
But 19TWh. While producing 470TWh. 4%. That is not ... a lot. And in 2022 Germany exported 5.5TWh and had to restart coal plants when the French nuclear plants were in trouble. So what? That what a grid is for.
"Several commentators, business leaders and academics have identified that 1970 deal as a significant fork in the road of the Cold War, as it established a mutual basis for economic cooperation between Russia and western Europe."
There are certainly different opinions on that.
Gas imports started long ago and in the cold war that approach was working to some extend.
> Germany didn't avoid nuclear by switching to renewables. It does so by burning coal and building gas-fired power plants.
That statement is plain wrong:
https://energy-charts.info/charts/energy/chart.htm?l=en&c=DE...
In 2013 about 300TWh of electricity came from fossil fuels, 92TWh from nuclear. In 2024 153TWh from fossil fuels and 0 from nuclear. So fossil fuels declined by 147TWh while nuclear only by 92TWh. Claiming that fossil fuels replaced nuclear is ridiculous, even after repeating it hundreds of times.
You can claim that keeping nuclear could have sped up the transition, but the inflexible nuclear plants could also have prevented people from investing in renewables, since the economics are worse if there is energy that is supplied permanently regardless of the price. Nuclear and renewables don't mix well.
As a diabetic having alarms is the most important thing. Measurements are not that accurate (neither is the finger prick method: If sometimes get a difference of 20% comparing two measurements from both hands). But also the "ok" range of 3.8 mmol/L to 10 mmol/L is quite large and levels can rise/drop 20% in minutes. So it is still quite helpful.
With the CGM there is also an additional delay of about 15 minutes in the measurements. Mostly you want to be triggered when something strange happens and then you do a manual measurement to confirm.
A false alarm of low blood sugar is annoying, but it is a lot better than collapsing. You can relax a lot more if you know you will get an alarm.
The battle of brokdorf was also in the 80ies: https://www.helmut-schmidt.de/en/publications/detail/the-bat...