Serialization is the canonical example. Being able to turn
struct MyStruct {
int val = 42;
string name = "my name";
};
into
{
"val": 42, // if JSON had integers, and comments of course
"name": "my name",
}
is incredibly powerfuly. If reflection supported attributes (i can't believe it shipped without, honestly), then you could also mark members as [[ignore]] and skip them.
The question is whether something belong in the language or in a library (possibly the standard library).
A guiding principle of C++ is that if something can be implemented cleanly and efficiently in a library, the language should not be extended to support the use case.
Now boost.pfr is exceedingly clever, but relying on speculative pack expansions or using stateful metaprogramming hacks is not something I would call clean and efficient, so proper reflection is warranted.
It is powerful, but I'm not sure it is a good idea. Other languages have it, and there is lots of experience in all the ways things go wrong in the real world. I'm inclined to say you should hand write this code because eventually you will discover something weird anyway.
Can you give an example of a language ecosystem that went with reflection-based JSON serialization/deserialization and then went on to regret it? I can't think of any, and don't agree with your conclusion. It works great, and manually writing serialization and matching deserialization code is terrible, annoying, error-prone work.
I disagree. Rust's defacto default is serde, golang comes with batteries included, dotnet/java have had it for _years_, and all the dynamic languages do it.
I think this is a very bad take -- once you write it by hand you have to manually keep it in sync with the actual struct and ensure you made no mistakes. Reflection guarantees 1-1 future-proof mapping with the actual C++ struct, avoids boilerplate, and ensures that the serialization logic is correct.
The protocol is important though, not the internal structure. When you only have exactly one version of a program talking to the same version of itself you don't care. However when you are mixing versions or worse programming language (and thus can't mix structs which are implementation details of your language) the protocol is what matters.
That is if you are worried about doing this by hand reflection is not the answer, something like protobuf where your data structures are generated is the answer.
I completely understand your point. Then again you might be able to use reflection to verify that your manually rolled implementation actually serializes all fields.
That demo was an absolute disaster for me on Firefox on mac. It just fundamentally didn't work - the voice wasway behind my pointer, there were multiple agents speaking over each other saying conflicting things, and it couldn't even move the crab to the bottom right of the image. Embarassingly bad I would say!
To be fair that’s an AWS problem not a lambda problem. If you replace lambda with EC2 the only thing you save in is lambda and step functions(and maybe api gateway but now you need to pay for a load balancer or a public IP), the rest you need to pay for anyway.
It’s flexible but slow. we ran our C++ CI/CD on AWS at a previous company, and we used spot instances with volumes attached and detached dynamically. The performance was absolutely abysmal because in effect you’re running compilation across a networked file system, no matter what AWS says your throughput is.
Our 64 core spot instances on windows were taking 8-10x longer than our developer machines with the same core count, and there was a bunch of engineering went into the scaling, queue management, etc. if we’d just had a single bare metal machine from hetzner we could have saved money _and_ reduced our iteration times.
At my previous startup: because AWS gave us a bunch of credits and helped us design the infra. It meant we ran for free what they designed for free.
At a previous bigger company, getting procurement to sign up to a new provider requires writing a business case, justifying the spend and then getting multiple competing quotes and speaking to their sales teams. Signing up to a new service takes _months_ even for $10/mo as they’ll negotiate for bulk discounts and the best possible terms for something that will literally cost less per year than one of meetings they hold to discuss the “value”. Meanwhile on AWS I can click a button in the marketplace and it gets thrown in the AWS account which is pre approved spending.
Many a big company migrated because they have those very same slow procurement problems with internal data centers. I saw multiple cloud migrations because internal friction was at a level that the price didn't matter: 6 months for the smallest VM kind of thing. Very adversarial relationships, often with very poor incentives, as the service setup costs for other business units were way inflated, but then the maintenance costs didn't pay enough. Paying 3x-4x more a year for just a semblance of reliability was seen as a big plus.
Exactly. I want to set up elastic search - I can either have procurement go through their sales, or be up and running via the marketplace in less time than it would take me to fill in the RFQ form to send to procurement.
If you let it go that far then you were going to blow it one way or another - it’s not an excuse to totally ignore the cloud spend but it’s a n excuse to defer it to a later date. If your successful, fix it, if your not then AWS aren’t getting paid anyway!
They use TOTP for 2FA (industry standard), which doesn't require a phone.
Their help page lists a bunch of 2FA app options, all of which run on phones, so it's understandable to think a phone is required. (I'm disappointed they don't list the app I use, which is Aegis Authenticator.)
But actually you can use any TOTP app, and they don't all need a phone. For example, macOS (desktop) has built-in TOTP 2FA as part of the password manager.
> But there are fewer and fewer reasons not to try Linux
Does my existing hardware connect to the internet and go to sleep when I close the lid? Does the hardware I can buy from major retailers do the same thing?
I know these are _technically_ vendor problems and not Linux problems, but I’ve got enough things to figure out without adding “what chipset does this high end laptop use” to the mix
The problem is that you're buying hardware designed for Windows, putting Linux on it instead, and expecting to have no issues whatsoever. I don't think that's practical.
When you try to run Windows on hardware designed for Linux, you run into similar fiddly problems. Exhibit A, the Steam Deck.
If you want a laptop that the manufacturer explicitly designed to be Linux compatible, the recent Frameworks are worth a look. Or System76.
No, the problem is I’m buying hardware that’s readily available to me.
The cheapest framework laptop I can assemble in the UK at the time of writing this is “estimated” at £1226. System76 seems to be us based and the pricing is similar. When I search for Linux laptops on Lenovo, I get chromebooks, dell’s cheapest option is £1399 and I can’t actually figure out what’s going on with HP.
> putting Linux on it instead, and expecting to have no issues whatsoever. I don't think that's practical.
I’m not looking for perfection - windows and Mac are both chock full of issues. But I do expect the basics to work.
You can just buy any regular reasonably popular laptop hardware it’s almost certainly going to work just fine with Linux.
You don’t need to buy a Lenovo that is Linux specific. They’re all just going to work.
This assumption that Linux is going to have hardware compatibility problems is super outdated.
And in the age of AI and
YouTube reviews it’s really not that hard to figure out if any old computer has decent compatibility. AI also makes initial setup and troubleshooting a lot easier.
> I started my first software job out of college in July of 2023. In January 2026, two and a half years later, I secured my second promotion, earning the title of Senior Software Engineer.
> certainly there are hard lessons that I have yet to learn in my career - but my company does not hand that title out like candy
> had (and still have) an excellent mentor <..> he had just been promoted to Senior SE. He was two years out of school himself.
I'm sure OP is a great engineer, and earned their promotion (genuinely, I am). But it sounds like his company hands out titles like candy.
As others have said titles are meaningless but I've worked with enough recruiters to know that they do have some sway on non-technical people..
Senior Software Engineer after 2 years is common. It’s a signal that someone has been promoted one step past the level right after college.
Some companies do it differently but honestly this is one of the more consistent ones I’ve seen based on years of reviewing resumes. I’d never penalize someone for not having a Senior title on their resume unless I knew the company’s leveling system.
I don’t take Senior Software Engineer to mean the person is a highly advanced engineer with loads of experience though.
Everyone who reviews applicants knows that leveling systems are very different depending on the company. What you should read these articles as is: The person managed to go through their first leveling up process at work. The title for the next level happens to be Senior Software Engineer at this company.
The title could have been Software Engineer II, Software Engineer Lebel Lvl 44, or anything arbitrary. The title is not the point.
They promoted an engineer 18 months out of undergrad to senior. They said it to indicate growth potential at the company, but I saw it as a big red flag.
Ha! It's funny I didn't notice that juxtaposition when I was writing it.
Understandable take. One counterpoint I would offer (with no proof, so take it or leave it) is that what I mostly see is engineers get passed up for promos that I feel they deserve. I think a large part of that is cutbacks - they haven't done layoffs, but around the time I started, they started cutting benefits, cutting RSUs, and my manager literally told me "due to budget constraints they are going to scrutinize promos very heavily going forward."
But! I don't work at a FAANG or an AI firm or anywhere with an extreme performance culture either. So regardless of YOE, if you're skilled, motivated, and a little lucky, you can really shine...
Typically it is expected that a software engineer gets their first promotion between 12-24 months. At the 6-12 month timeframe the managers will be having discussions around if they are on track, what they need help on (everyone needs a little help), or if there clear performance warnings going on and we need to take action of some sort.
I will congratulate everyone on their first promotion, it is worth celebrating, not everyone can do this job. But this first promotion is given to everyone who can actually do the work.
Get someone good, in a greenfield project, the right start timing aligned with promo committee time, add in some luck, and sure two promos in two years are possible.
Seen this before and the worry is that they are learning is the game of the promos system, not engineering. I would have to sit them down and ask them how many years away from being the CEO do they think they are. The next promo will come slower no matter their skill and even slower after that and one day the promos will probably stop. The validation that they might be addicted to will get harder to obtain over time. Not getting a promos shouldn't "crush" you. If they assume that merit is always rewarded they should ask their boss how promo committees actually work. Many people don't get promos for reasons unrelated to merit.
The second question is where is the engineering? Only two years into a long career there is a lifetime to learn and explore. If they only chase promo they are going to burn out very quickly.
If I release a video and send an email newsletter at the same time, which one caused the traffic increase? Should I invest in making more videos of sending more emails?
If you insist on knowing, include a different url in both that goes to the same place and use your damn server logs. You don’t need google analytics and whatever.
presumably you control the urls you are sending in the email. As a result if you want to use query strings that's fine. The issue only arises when you use query strings to implement tracking on someone else's site instead.
reply