People jay walk when there's no traffic all the time, that's totally fine. This is a totally different act of passive aggression.

That said, I’m open-minded and obviously thinking about this given moving to my own domain.

What’s the evil behavior you’ve experienced? I’m down to move off if I’m oblivious to something…

When I look at Google, I see a company that is fully funded by ads, but provides me a number of highly useful services that haven't really degraded over 20 years. Yes, the number of search results that are ads grew over the years, but by and large, Google search and Gmail are tools that serve rather benevolently. And if you're about to disagree with this ask yourself if you're using Gmail, and why?

Then I look at Meta or X, and I see a cesspool of content that's driven families apart and created massive societal divides.

It makes me think that Ads aren't the root of the problem, though maybe a "necessary but not sufficient" component.

Whenever I'm approaching a border crossing (e.g. in an airport), I'm sure to discreetly click power 5 times. You also get haptic feedback on the 5th click so you can be sure it worked even from within your pocket.

But your hypothetical manager who needs employee scheduling software isn't paying for the coding, they're paying for someone to _figure out_ their exact needs, and with a UI that fits their preference, ready to go in no time.

I've thought a lot about this and I don't think it'll be the death of SaaS. I don't think it's the death of a software engineer either — but a major transformation of the role and the death if your career _if you do not adapt_, and fast.

Agentic coding makes software cheap, and will commoditize a large swath of SaaS that exists primarily because software used to be expensive to build and maintain. Low-value SaaS dies. High-value SaaS survives based on domain expertise, integrations, and distribution. Regulations adapt. Internal tools proliferate.

I also use en dashes when referring to number ranges, e.g., 1–9

First, my philosophy is that long-lived feature branches are bad, and lead to pain and risk once complete and need to be merged.

Instead, prefer to work in small, incremental PRs that are quickly merged to main but dormant in production. This ensures the team is aware of the developing feature and cannot break your in-progress code (e.g. with a large refactor).

This usage of "feature flags" is simple enough that it's fine and maybe even preferable to build yourself. It could be as simple as env vars or a config file.

--

However, feature flagging may also refer to deploying two variants of completed code for A/B testing or just an incremental rollout. This requires the ability to expose different code paths to selected users and measure the impact.

This sort of tooling is more difficult to build. It's not impossible, but comparatively complex because it probably needs to be adjustable easily without releases (i.e. requires a persistence layer) and by non-engineers (i.e. requires an admin UI). This becomes a product, and unless it's core to your business, it's probably better to pick something off the shelf.

Something I learned later in my career is that measuring the impact is actually a separate responsibility. Product metrics should be reported on anyway, and this is merely adding the ability to tag requests or other units of work with the variants applied, and slice your reporting on it. It's probably better not to build this either, unless you have a niche requirement not served by the market.

--

These are clearly two use cases, but share the overloaded term "feature flag":

1. Maintaining unfinished code in `main` without exposing it to users, which is far superior than long-lived feature branches but requires the ability to toggle.

2. Choosing which completed features to show to users to guide your product development.

(2) is likely better served by something off the shelf. And although they're orthogonal use cases, sometimes the same tool can support both. But if you only need (1), I wouldn't invest in a complex tool that's designed to support (2)—which I think is where I agree with you :)

(It’s too late to amend my comment)

Usually by that point you catch them, but your recruiter screen might not etc. So now all the main HR tools are using “age of email” as one possible signal to detect fraud.

I’m sure you’re fine if your email is real (in my experience they all resolve to Onvoy LLC instead of a real cell provider), but just something to watch out for. Wouldn’t want to get overlooked because your email is brand new.

(If you’re curious about motive as I was, since of course it’ll be obvious when you start—in a lot of cases it’s that procuring an offer letter helps you obtain a visa.)