chipdart

> The assumption of stack ranking is that the good people will survive each round of purging.

It's my understanding that Amazon does not do stack ranking.

What they do is more insidious. They force people out in a process that consists of promoting people as a pretext to apply harsher performance evaluation criteria while comparing your performance directly with veteran, well established engineers.

To make matters worse, you have a limited influence over your career. You are evaluated based on your performance in your role which is dictated by the project you are assigned to. SDE1s are de-facto barred from switching teams, SDE2s can switch teams but can be a liability, SDE3s are few and far in between and have limited career options, and on top of that there's only principal engineer, which is already a role that needs full support and commitment from executives.

The rule of survival was move up to SDE2 as fast as you could, and afterwards judiciously switch teams each year or so to a) avoid being held liable for your past work, b) ensure you were working on a team thay was unlikely to be subjected to cuts, and most of all c) do your best to not be considered for a promotion to SDE3 as that would mean you would be held personally responsible for each and every single failure and short-coming of the projects you'd be assigned to.

In short, they push people up and out. The average tenure is shorter than 3 years. Let that sink in.

> Yeah but the people implementing it are prob more interested on you moving to VS (...)

Wasn't support for submodules first added to Clang and CMake?

Also, I don't think you fully grasp the scope of this change. Some projects are still stuck on C++1 to avoid having to pay for the technical debt of upgrading the compiler. This is a flag flip away.

For modules, you need to rework your whole build system and Eve rearchitect your projects.

Think about that for a second.

> I don't understand why educated people expect that an LLM would be able to play chess at a decent level.

The blog post demonstrates that a LLM plays chess at a decent level.

The blog post explains why. It addresses the issue of data quality.

I don't understand what point you thought you were making. Regardless of where you stand, the blog post showcases a surprising result.

You stress your prior unfounded belief, you were presented with data that proves it wrong, and your reaction was to post a comment with a thinly veiled accusation of people not being educated when clearly you are the one that's off.

To make matters worse, this topic is also about curiosity. Which has a strong link with intelligence and education. And you are here criticizing others on those grounds in spite of showing your defitic right at the first sentence.

This blog post was a great read. Very surprising, engaging, and thought provoking.

> Just because I included an rvalue constructor doesn't make it C++11.

Actually, it does. I mean, does it compile when you pass -std=c++98?

> This library was originally written in C.

Doesn't matter. If it uses C++11 features, it's C++11.

> I feel perfectly comfortable calling C++11 "classic" or even "baroque" compared to what people are doing with C++ in 2024.

Irrelevant. You can go the Humpty Dumpty way as far as you want to go and call anything any way. It doesn't matter. If you use C++11 features, it's C++11. If it's C++11 then you're discussing modern C++. You don't need to use all bells and whistles to quality.

> I just wrote a new server instead.

I'm sorry, this makes no sense at all. Why would anyone write a new server just because a small component was taking a minute to build?

> Compile time is largely a "developer problem", but so is the usability of a library.

Compiler time is way more than a "developer problem". It's an operational problem that ends up permeating to software architecture and development practices, and ultimately affects how the whole project is delivered and deployed.

> Hey that is not true, at least last time I tried I spent considerable time trying to integrate a bare metal load balancer from a 9 stars github repo plugin because apparently exposing the port is not recommended.

You sound like you tried to put together an ad-hoc ingress controller without knowing what an ingress controller is and why abusing NodePort is a mistake in the context of a cluster.

You can check this out to go through the basics.

https://kubernetes.io/docs/concepts/services-networking/ingr...

> Also having the master and the node in the same server can be problematic because by design it shouldnt be like.

You should look at the problem to see if an approach makes sense. If you're using vanilla Kubernetes on a one-box deployment then you're abusing a large-scale high-scalable cluster management system by shoving it into a single box. It can work, but most of the resources will be wasted on managing your cluster of one node.

There are plenty of Kubernetes distributions that are designed to handle well small clusters, and even one-box systems. Minikube, microk8s, and even k3s come to mind. I'm partial towards microk8s because installing it is just a matter of installing a single package from the distro's official repository.

> It's not a show stopper though since everyone should have a c++11 compiler now (...)

I think the point of pointing out it's C++11 is that it's not "classic C++" as it's using "modern C++" features. Thus it's a mystery why it would be referred to as classic C++.

> (...) and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files.

If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently? That means you can build it in parallel along with the whole project, and in the end you just link the resulting binaries.

> It makes it easier to turn them into the same unit of deployment.

They are not the same unit of deployment. That's an impossibility.

This critical mistake is at the core of this monorepo nonsense. It's a cargo cult, where people believe that storing code for multiple projects in the same source code revision contol system somehow magically turns distributed systems into a monolith and solves deployment issues. It does not.

> You're right about atomic deployments being difficult and sometimes one can control that risk by the order in which you change things.

No. That is false. Atomicity in a distributed transaction is not achieved by shuffling operations around. Specially those you cannot control.

> Is that even such a bad thing? Given the choice between cutting expenses on food/drinks and firing people, (...)

The whole point is that if you're already faced with the choice if cutting coffee or firing people, you will already fire people regardless of how much you cut in coffee. It's futile and specious reasoning, which at most only work as signaling.

> Let's say I agree with you and that TLS termination is not a container orchestration responsibility.

It isn't. It's not a problem, either. That's my point: your comments were in the "not even wrong" field.

> (...) It seems like any distinction you make is going to be arbitrary and basically boil-down to "no true container orchestration system should care about..."

No. My point is that you should invest some time into learning the basics of deploying a service, review your requirements, and them take a moment to realize that they are all solved problems, specially in containerized applications.

> I'm aware of Traefik, I ran it for a little while in a home lab Kubernetes (...)

I recommend you read up on Traefik. None of your scenarios you mentioned are relevant to the discussion.

The whole point of bringing up Traefik is that it's main selling point is that it provides support fo route configuration through container tags. It's the flagship feature of Traefik. That's the main reason why people use it.

Your non sequitur on Traefik and Kubernetes also suggests you're talking about things that haven't really clicked with you. Traefik can indeed be used as an ingress controller in Kubernetes, but once deployed you do not interact with it. You just define Kubernetes services, and that's it. You do interact directly with Traefik if you use it as an ingress controller in Docker swarm mode or even docker-compose, which makes your remark even more baffling.

> I'm impressed at both what Kubernetes and k3s have done. (...) If Traefik is as it was years ago,(...)

Kubernetes represents the interface, as well as the reference implementation. k3s is just another Kubernetes distribution. Traefik is a reverse proxy/load balancer used as an ingress controller in container orchestration systems such as Kubernetes or Docker swarm. The "level of complexity" is tagging a container.

Frankly, your comment sounds like you tried to play buzzword bingo without having a clue whether the buzzwords would fit together. If anything, you just validated my previous comment.

My advise: invest some time reading on the topic to go through the basics before you feel you need to write a blog post about it.

> Most people dont need rolling release, 24/7 availability, auto scaling, etc..

That's perfectly fine. That's not the reason why you are better off running your apps in Kubernetes though.

You are better off running your apps in Kubernetes because it handles everything you ever need to effortlessly run containerized apps. You don't even need to install tooling or deployment tools or anything at all. You can have a single kustomize script that defines your services and deployments, have in place an ingress and Let's Encrypt, and you're done. You don't need to bother with anything else. Just run kubectl apply and go grab a coffee.

Is this something no one would ever need?

> Using Kubernetes where it's not needed is just that - wasting your time and making your life harder.

I think this is a very ignorant and misguided take.

Kubernetes is a container orchestration system, just like Docker swarm mode or even Docker compose. If you need to deploy sets of containerized apps into your own VMs, you can pick up any Kubernetes implementation. You don't even need Helm or anything. Plain old kustomize scripts will do. Some aren't even longer than a docker-compose.yml.

More to the point, Kubernetes is an interface. One that you can use in local deployment and in major cloud providers.

You should really check your notes because your comments contrast with the realities of actually running a service.

> Before you say that I just need to research more: (...)

All your appeals to authority are falsified by your claims.

I, on the other hand, actually use Kubernetes both professionally and in personal projects, as well as Docker swarm mode, and can tell you I'm no uncertain terms that none of your points have any traction in reality.

> I still claim that there are production usecases that are better served by docker-compose.

I'm sorry, but your comments simply sound deeply uninformed and misguided.

I mean, it makes absolutely no sense to comment on using docker compose in production when Docker swarm mode is far more capable and Docker swarm mode stacks already share most of the schema with docker compose. You literally have virtually nothing to do to adapt a docker-compose script to launch a stack.

Unbelievable.

> The point of statistics (one of many) is to figure out how many observations we need.

No, you're missing the whole point. Think about the problem about survivorship bias. Imagine you are at a M&Ms factory. You decide you want to assess what's the color distribution of M&Ms by sampling the colors that come out of the production line. You somehow make the mistake of sampling the production line for the peanut core M&Ms right out of the pipe that produces yellow M&Ms. You sample away and after hours you present your findings: 99.9% of yellow M&Ms have a peanut core. Based on your findings, you proceed to boldly claim that having a yellow core is a critical factor in producing yellow M&Ms. You even go as far as to rationalize it, and claim that yellow represents peanuts, and if anyone wants to create yellw-colored candy they need to start by adding peanut to the mix.

I then alert you to the fact that you made a critical failure in analysis when confusing partial observations of post-facto results with causality. Your answer:

> The point of statistics (one of many) is to figure out how many observations we need. If someone wins the lottery 10 times with their system I will assume that they have a good system (if they have a lot of losses as well it means the system isn't perfect, but it still works), but if you only win once and never enter again I assume it is survivorship basis.

You're sampling M&Ms out of the freakin' peanut M&M production line. If you fix your mistake, you'll get all kinds of M&Ms. You do not fix your mistake with higher sampling. Your mistake is that you're unwittingly filtering out an important subset of the problem domain, and proceeded to do a faulty analysis on the subset you picked.

> I'd say its 100% production ready.

That's fine. Some people also manually launch containers individually with Docker as their production system.

They'd be wasting their time and making their lives needlessly harder, though.

They already have tools that do all the legwork for them. Why not do the research and opt to force a square peg into a round hole?

Research Docker swarm mode, reverse proxies like Traefik, and Let's Encrypt. Kubernetes can be even easier with implementations like microk8s, which are a snap away from any Ubuntu installation. Look at what you're doing and figure out the right tool for the job. Don't just whine about how you're doing something wrong and it's the tool that needs to change to fix your own mistakes.

> For many people self-hosting implies a personal server; it's not really "development" but it's not "production" either.

There's Docker swarm mode for that. It supports clustering too.

It's nuts how people look at a developer tool designed to quickly launch a preconfigured set of containers and think it's reasonable to use it to launch production services.

It's even more baffling how anyone looks at a container orchestration tool and complains it doesn't backup the database they just rolled out.

> In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular.

...and proceed to put pressure to shitify it by arguing it should do database backups, something that even Kubernetes stays clear from.

The blogger doesn't even seem to have done any research whatsoever on reverse proxies. If he would have done so, in the very least he would have eventually stumbled upon Traefik which in Docker solves absolutely everything he's complaining about. He would also have researchdd what it means to support TLS and how this is not a container orchestration responsibility.

Quite bluntly, this blog post reads as if it was written by someone who researched nothing on the topic and decided instead to jump to

> This company is done.

This is hard to understate the importance of this. If a company feels obligated to cut spending by cutting small expenses on consumables, such as coffee or even free fruit programs, then they are at a level of going through the proverbial couch cushions hoping to find a coin to meet the budget.

My answer was not touching on the topic of identity. I'm referring to the relationship between cause ad effect.

> At what point do we conclude the lottery isn't as random as they claim if one person keeps winning.

The whole thing about survivorship bias is that you make a critical failure in analysis when confusing partial observations of post-facto results with causality.

It's not about interns, it's about roles.

L6s are tasked with interfacing with higher-ups, such as product owners and senior managements. They coordinate with principal engineers to design and deliver critical features. They help communicate and coordinate tasks with SDMs about the work that other SDEs need to do to reach goals.

By design, they are normally one senior SDE per team, and a single principal engineer per organization. They are there so that senior managers and executives can discuss plans, goals, and roadmaps. You definitely do not need a team full of interfaces.

> (...) and they keep winning

That's the textbook definition of survivorship bias. It's like a lottery winner boasting about his winning strategy that everyone else is just not able to learn.

> I would think that about 20-30% are “senior”.

I think your assumption is way off. From what I've gathered, each team typically has a single L6 engineer (some have zero), and each independent organization has a single L7 engineer. We're talking one senior engineer per 9-12 engineers, one principal per around 50 engineers.

Senior engineers tend to have a 1:1 correspondence with software development managers, whereas principal engineers have a 1:1 correspondence with senior managers.

> I would think that about 20-30% are “senior”.

You should check your notes, as they are way off. Even if you Google the topic you get 15% senior engineer, 2% principal engineers. I know for a fact that flagship organizations within Amazon have a single principal engineer, 4 or 5 senior engineers, and around 50 L4-L5.

And by "TikTok" implies state-run propaganda campaigns.

> Can you show me an example of successfully doing what you claim you do?

In theory technically nothing prevents me from doing that, but I use it for professional work. Do you understand what you're asking?

> I am unable to get these things to do anything useful.

My experience is widely different than yours. I use Copilot extensively to explain aspects of codebases, generate documentation, and even fill in boilerplate code for automated tests. You need to provide the right context with the right system prompts, which needs some effort from your end, and you cannot expect perfect outputs.

In the end it's like any software developer tool: you need to learn how to use it, and when it makes sense to do so. That needs some continuous effort from your end to work your way up to a proficient level.

> People on this site love to talk about “muh productivity!”, but always stop short of saying what they got from this productivity boost: (...)

I don't understand what you're trying to say. I mean, have you ever asked that type of loaded question on discussions on googling for answers, going to Stack Overflow, or even posting questions on customer support pages?

But to answer your question, I spend far less time troubleshooting, reading code to build up context, and even googling for topics or browsing stack overflow. I was able to gather requirements, design whole systems, and put together proofs of concept requiring far less iterations than what I would otherwise have to go through. This means less drudge work, with all the benefits to quality of life that this brings.

> Somehow I feel the project was held as a hostage, waiting for a ransom (which was paid eventually).

This situation only happens when you hand the responsibility of managing a critical domain to a single person, and you forget about it for ages.

This is hardly a "hostage" situation, specially when the reason flagged is lack of support. I mean, this scenario only happens due to lack of support to begin with.

> That pretty much makes all internal APIs and code like Public APIs as a product (...)

No. Different versions are not different products. They are the exact same product, provided in a way that delivers features in a way that won't break clients.

> (...) adds a huge costs in terms of initial API designs (...)

Obviously not. From the producer side, all it takes to support versioning is picking up your versioning strategy and sticking with it. This can mean providing an endpoint through a different path parameter, reading a request header, or even get the version through a query parameter.

Does it take you much design work to add a "v1" in a URL path? How about reading a request header? Does passing a query parameter require meetings to review designs?

Some frameworks even explicitly support versioning as a high-level concept and make it a part of their routing strategies. Copy the source file of a controller to another folder, change it's namespace to avoid conflicts, add a tag to the class, done. You just released a new version of your API.

> (...) assumption validations, because you can't make any mistakes at all.

You somehow managed to get it entirely backwards. With versioning, you can afford making all kinds of mistakes all the time. Breaking interfaces is no longer w concern. You release your changes to an upstream dependency/producer with zero use, downstream dependencies/consumers can gradually switch as their test plans allow, and if any problem is detected then this can be worked out before either consumers go live or producers receive production traffic.

More importantly, you have your old stable versions ready to roll back.

> To put the opposite view: Versioning could be done with individual functions in the code for example but we don't do that - we just update all the places that call it.

I think you're a bit confused. There are code repositories, and there are units of deployment. Those are not the same things.

Storing multiple projects in a single repository does not magically make them a single unit of deployment, even when you deploy them all with a single pipeline. When you have multiple projects, you always have multiple units of deployment.

In your example, you focused on a scenario that does not apply: individual functions that are a part of the same unit of deployment. Your example breaks down when you pack your hypothetical function in separate modules that you deploy and consume independently. Even if you do not explicitly tag a version ID to a package, implicitly your module has different releases with different versions of your code delivered at different points in time. If one of these deliveries has a breaking change them your code breaks. Explicitly specifying a version ID, such as adding git modules pointing at a specific commit, is a technique to preserve compatibility.

Where it is very obvious your example fails is when you look at scenarios involving distributed applications with independent units of deployment. This means things like a SPA consuming a backend service, or even a set of producers and consumers. Even if they are all deployed by the same pipeline, you either have forced downtime or you will always have instances of different versions running in parallel.

The SPA+backend is a rather obvious example: even if you do a deployment of a backend and frontend at the exact same time as an atomic transaction that ensures both are available at the precise same tick, don't you still have users with the browsers loaded with instances of the old SPA? They will continue to have it open until they hit F5, aren't they? If you released a breaking change to the backend, what do you think will happen to users still using the old SPA? Things will break, won't they?

Atomic deployments do not exist, however. Looking at services, you have no way to ensure you can deploy new versions of services at precisely the same tick. This means even with monorepos you will always have different deployments of those services running in parallel. Monorepo proponents fool themselves into believing this is not a problem because they count on experiencing problems at best only briefly during deployments, and that the system eventually reaches steady state. This means things like erratic responses, distributed transactions failing, perhaps only a few corrupt records going into the db, etc. If everyone pretends these problems are normal then there is no problem to fix.

Except this negates each and every single hypothetical advantages of a monorepo, and rejects any argument supporting it. Once you realize you're not actually eliminating problems and you are only buying forced downtime, no matter how small, and taking that hit out of willful ignorance. As a tradeoff, you're buying yourself operational problems and lack of flexibility due to the misuse of revision control systems.

And all for what? Because someone heard Google uses monorepos?

> Bugs can and will happen, eg. when A depends on B and some developer accidentally makes a change to B that will pass B's tests but only break in A's use case. In monorepo case such bug can be noticed before the broken code hits master.

I don't see what point you tried to make. So A breaks when someone breaks B. That's ok. You spot the error the moment you try to update A, well before you commit any code. You file a low-priority ticket and go on with your life because A is still good in production.

> Knowing when no one uses older versions is also hard (...)

Not really, it's the easiest part of the whole thing and a non-issue. If you manage a package this does not even register as a problem. If it's a service you have request metrics.

What is the problem, really?