Beats 90% of Canadian software engineer salaries. If I wasn't tied down with 2 border collies, a chicken, a cat, and, uh, wife and kids, I'd jump to that in an instant. German quality of life is still pretty good despite all their complaining.
Yep, at least in my case (Spain), given the price of the houses and that banks are giving mortgages for 70-80% of the value, tops, you better have 100K in the bank for the down payment if you want to live in a relatively big city. So even with a good salary, is difficult to buy a house.
I think I feel the same in the sense that AI now allows me to choose more carefully what I'm actually working on and offload boring other tasks to the AI. Of course, it only works as long as the deadline allows it.
> As I've more reliably produced reasonable quality code with automation I've found my joy coming from coding solutions to my own day-to-day problems and less to do with solving the problems I'm employed to solve.
Wait a week with your judgement - most likely, Google is just bench-maxing very hard.
If you look at the previous Flash models and the announcement on Google I/O, it was an absolute disaster. Reality diverged very much from the marketing (supposedly great benchmarks).
It’s really not at all at the same level as other European cities. It’s so bad that basically every year high up officials write a Brandbrief (urgent appeal) to either Deutsche Bahn or Ministry of transport that the situation is unbearable.
Having lives in 3 different German cities, it’s by far the worst and most unreliable.
In contrast to the US, many people exclusively rely upon public transport and eg a drivers license costs north of 4K € (approx 5k USD), in addition to much higher gasoline prices - making a car way less affordable.
Indeed, it's the underlying principle of "division of labor".
Karl Marx' coined the term "Alienation" for describing most of the negative societal/human consequences of this principle, leading to isolation of humans "from themselves" (their natural will to construct something whole meaningful, not just complete a task in a process, but also isolation between humans themselves)
off topic, but related to the recent github alternative discussion:
Wow, this gitlab instance looked so much cleaner/simpler and less clunky than my past experiences! Also loaded really fast on first page load as well as subsequent actions
Gitlab has been better than github in almost every aspect for a few years already, I don't understand why anyone still bother with github at that point
Sure, I've cancelled my Max 20 subscription because you guys prioritize cutting your costs/increasing token efficiency over model performance.
I use expensive frontier labs to get the absolute best performance, else I'd use an Open Source/Chinese one.
Frontier LLMs still suck a lot, you can't afford planned degradation yet.
The ‘design everything as a publicly accessible API’ directive seems to play to this as well. If all your data / services are available and must be documented then a lot of communication overhead can be eliminated.
For anyone who doesn't know what you mean, here's an archived copy of Steve Yegge's post about this directive + other musings comparing Amazon vs Google (which is how a lot of us came to find out about this, via Yegge's write-up): https://news.ycombinator.com/item?id=3102800
Copied the most relevant snippet below
---
So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.
His Big Mandate went something along these lines:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn't do this will be fired.
7) Thank you; have a nice day!
Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.
#6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Armgy Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word "hardened interface" a lot. Rick was a walking, talking hardened interface himself, so needless to say, everyone made LOTS of forward progress and made sure Rick knew about it.
Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount while effecting this transformation. There was lots of existing documentation and lore about SOAs, but at Amazon's vast scale it was about as useful as telling Indiana Jones to look both ways before crossing the street. Amazon's dev staff made a lot of discoveries along the way. A teeny tiny sampling of these discoveries included:
- pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting.
- every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service.
- monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum.
- if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where.
- debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.
That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers.
This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally.
At this point they don't even do it out of fear of being fired. I mean, they're still afraid of that; it's pretty much part of daily life there, working for the Dread Pirate Bezos and all. But they do services because they've come to understand that it's the Right Thing. There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it's the right thing because SOA-driven design enables Platforms.
That's what Bezos was up to with his edict, of course. He didn't (and doesn't) care even a tiny bit about the well-being of the teams, nor about what technologies they use, nor in fact any detail whatsoever about how they go about their business unless they happen to be screwing up. But Bezos realized long before the vast majority of Amazonians that Amazon needs to be a platform.
You wouldn't really think that an online bookstore needs to be an extensible, programmable platform. Would you?
> You wouldn't really think that an online bookstore needs to be an extensible, programmable platform. Would you?
Well, we were making it a platform in small ways long before that edict from Bezos. But because it used to be only an online bookstore, the footprint was a lot smaller.
1. the external interface was ... HTTP
2. the pages were designed to be easily machine parsable
3. you could queue up search queries that amzn would run on its own hardware, and notify you of the results asynchronously.
Sure, this didn't look anything like the things Yegge is describing, but the idea that "it's a platform, dummies" was some new revelation is misleading.
Thats quite competitive for a base salary, as high as max ICT5 Staff base at Apple Munich.
reply