It’s one of those tools that’s well designed and you don’t need a thousand line configuration file to be productive. The modal editing style is also an improvement over vim/neovim because you do selection -> action rather than action -> selection. Lastly, it’s written in Rust, which is not a plus purely because of that but because it’s a lot easier to contribute code changes to or tweak a modern Rust codebase.
Pretty much every engineer needs to use Vim/vi when logged into any server, so from that point of view, this shouldn’t even be a question. I don’t think knowing how to use a modal editor in 2026 is a flex anymore, it’s just standard. But if you’re planning to commit to modal editing as a lifestyle, you should be using Helix, not Neovim.
Why quantitative? I have friends at most major tech companies and I work at a startup now. You shouldn’t write by hand what can be prompted. Doesn’t mean the hard parts shouldn’t be done with the same care as when everything was handwritten, but a lot of minutiae are irrelevant now.
Well, on the surface it may seem like there’s nothing being created of value, but I can assure you every company from seed stage to unicorns are heavily using claude code, cursor, and the like to produce software. At this point, most software you touch has been modified and enhanced with the use of LLMs. The difference in pace of shipping with and without AI assistance is staggering.
I empathize with this cause circumstances often force us to move to a less than ideal location, but with everyone doing RTO again since 2 or 3 years ago, you slashed a huge percentage of the job opportunities out there.
I would say you can take opposite route as well. Become even more of a T-shaped engineer than you were before. For me that meant transitioning to vertical roles (i.e., performance engineering) rather than backend engineering. Sure, an AI can understand every level of the stack but reasoning up and down at every level of abstraction still has a human element to it (at least for now).
>http-request-validator is infinitely superior to “zephyr”
Is it though? How are you going to differentiate between 10 different variations of http-request-validator repos on GitHub? I think both have their downsides, but making the name super generic sounding is arguably worse. What I don't like about names like zephyr is that they're purely marketing-driven; people end up picking a zephyr over a http-request-validator purely because the name is sounds "cool" to them, even though http-request-validator might actually be the better library. And don't even get me started on people naming their projects random Japanese words.. it's like the equivalent of nicknames that Thai people use, which are just random English words like Ice Cream or Thank You.
Maybe the happy medium is, like you said, names that contain a hint as to what they do, like Actix (actor model). But TBH you kind of still have to look it up to know what it does, there's no way you're just going to infer that. Maybe later on it helps you remember what it was for though.
IMO you should just transfer internally to a Deep Learning related team. That’s the path I’m taking, and while I wait for my new start date, I’m reading the important research papers etc. It shouldn’t take you as long as you think.
>Any software developer can access GitHub and StackOverflow - can they do it in a single shot as quickly as GPT?
I think the answer to this question is yes? If the developer can find a working example that they can copy paste (which is what GP is saying GPT-4 is essentially doing).
It’s actually just as likely for GPT-4 to have pasted a broken code example than a working one; it doesn’t understand if the code is correct.
>It seems like Asian cultures are much less likely to treat housing as an investment
Isn’t China one of the most prominent examples of using real estate as investment? There’s even whole ghost towns of apartment buildings that are constructed for this purpose.
I would advise not looking at libraries as a beginner; because they’re meant to be as generic as possible, they tend to abuse the type system and are overall a lot harder to parse for a beginner. Stick to reading the Rust code for standalone programs.
Yeah, gRPC is mainstream at this point -- much better to generate API clients when you can, instead of hand-rolling your own, especially as the number of engineers and teams in an organization grow.
I think most people just use the AWS Console. By the way, compared to regular CloudWatch, CloudWatch Insights has faster searches and a SQL-like query language, so it's better to use that if you can.
Right. Then it might be worth applying to cloud software engineer roles in general, and be sure to ask your interviewers about what sort of architecture they work on. In your case, seems like you’ll be more keen to work on those teams that have multiple services, not those that have monoliths.
Kind of? I mean, if you’re working on an infrastructure or platform team, and building some distributed database or data pipeline, that would be more “distributed systems”, in the strict definition of the term. However, I doubt there are very many teams working on these sorts of problems —- it’s a very specific niche.
Edit: I might have misinterpreted your comment. The actual architecture of scaling by adding more hosts is quite common, if you’re processing independent messages.
Are you sure you’re specifically interested in Raft/Paxos/consensus algorithms? Distributed systems is more general than that. A lot of software engineers working on cloud services are basically doing distributed systems, if they are building multiple interconnected services. Where I work, our team has 10-15 services that communicate with each other, with databases, caches, and with other dependencies/consumers. This could also be considered distributed systems.