schrodinger

Depending on where you live it may not really be relatable to you, but living in NYC -- there are people that will intentionally jay walk on a green light and even _stare you down_ knowing that you will stop and let them pass.

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

It's easy to get caught up in your own hype when you're surrounded entirely by people who always tell you what you want to hear.

I’ve recently begun using my personal domain as my primary email address, with it forwarding to gmail so I can “get out” easily if I ever had a reason. That said, I’ve found Gmail’s service great, their spam filtering highly effective, (although I haven’t surveyed the competition lately so it’s possible their huge advantage no longer exists) and their features pretty user-friendly (eg the one-click unsubscribe as well as a page to view all your subs in one place). I have never felt like they _abused_ the immense amount of data they have about me nor used it for “evil” purposes; only to profit on relevant ads that are at least clearly marked and unobtrusive. I don’t like that they have so much data on me, but I’ve felt like they’ve been transparent about it, so it’s been on me for making a decision eyes wide open. As opposed to Meta and the shady shit they’ve been caught doing...

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…

I don't think that ads _have_ to be evil.

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.

FYI -- Because of this, Apple made a feature where if you click the power button 5 times, your phone goes into "needs the passcode to unlock" mode.

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.

Writing the code has never been the hard part for the vast majority of businesses. It's become an order of magnitude cheaper, and that WILL have effects. Businesses that are selling crud apps will falter.

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.

Write it in Go!

What a nice thought :)

I do—all the time. Why not?

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

FYI: did you know for (2) you can say "Hey Siri ask ChatGPT if Liam Neeson is alive" and it works perfectly?

Just don't buy what you don't like. There's no throat shoving going on.

It's an externality because the entity that sold it to you doesn't have to pay the consequences of dealing with the trash. OP said "dispose of it properly," which could mean a lot of things, all of which are better than leaving it on a beach.

What ads?

I'm confused—how does putting in a master switch for those who want to opt-out entirely from the AI revolution occurring at the moment not matter? Are you saying that new features will fail to respect it?

Voters: please reconsider your ups and downs. I think the “Are you an expert” question triggered a lot of downvotes when it was in fact asked in good faith to judge the person’s perspective of easy and hard.

I generally agree, but see some more nuance. I think feature-flagging is an overloaded term that can mean two things.

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 :)

Edit: “I’m sure you’re fine if your email is real” should be “…phone number”

(It’s too late to amend my comment)

As a hiring manager, I just want to give you a heads up that we are getting tons of fake applicants—like 5–10%—that end up being a real person on a video chat isn’t some AI assistant that uses a teleprompter interface to tell them what to say.

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.)

I see your point, but disagree on a practical level. Libraries are being used while you’re in “developer” mode, while programs are used in “user” mode (trying awkwardly to differentiate between _being_ a developer and currently developing code around that library.

Usually a program is being used by the user to accomplish something, and if logging is meaningful than either in a cli context or a server context. In both cases, errors are more often being seen by people/users than by code. Therefore printing them to logs make sense.

While a lib is being used by a program. So it has a better way to communicate problems with the caller (and exceptions, error values, choose the poison of your language). But I almost never want a library to start logging shit because it’s almost guaranteed to not follow the same conventions as I do in my program elsewhere. Return me the error and let me handle.

It’s analogous to how Go has an implicit rule of that a library should never let a panic occur outside the library. Internally, fine. But at the package boundary, you should catch panics and return them as an error. You don’t know if the caller wants the app to die because it an error in your lib!

The motivation isn’t there to create new languages for humans when you’re programming at a higher level of abstraction now (AI prompting).

It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly.

I hope it’s not true, but I believe that’s what OP meant and I think the concern is valid!

Genuinely curious — how did you isolate the effect of comments/context on model performance from all the other variables that change between sessions (prompt phrasing, model variance, etc)? In other words, how did you validate the hypothesis that "turning off the comments" (assuming you mean stripping them temporarily...) resulted in an objectively superior experience?

What did your comparison process look like? It feels intuitively accurate and validates my anecdotal impression but I'd love to hear the rigor behind your conclusions!

Bet you never thought you'd have a "when I was a kid" attitude… :)

and vice versa: https://news.ycombinator.com/item?id=45976597

I love this. As another poster brought up, plenty of people buy enjoyable cars and motorcycles for the pleasure of driving. Why not add a little spice to life?

Fair point perhaps, but was clearly intended as sarcasm:

> a society that glamorizes everyone driving the biggest trucks and carrying the largest rifles

This was very confusing!

I meant it’s easy to inspect your script’s logic — look it. Bunch harder to audit the code in dependencies though…

Sorry I was half asleep! Meant that you can easily look at the code in the script and audit what it does – you can just run `cat` in it and you’re done!

But it’s much harder to inspect what the imports are going to do and be sure they’re free of any unsavory behavior.

The script is just a cat or vim away from audit. Its dependencies on the other hand…

Rule 35 of the internet? Every discussion will eventually devolve into the United State's horrible usage (or lack thereof) of public transportation.

Having replied in good faith already, I also want to call out that your jab about trucks and rifles adds nothing to the conversation and is merely culture-war fuel.

> Please don't use Hacker News for political or ideological battle. It tramples curiosity.

> Eschew flamebait. Avoid generic tangents. Omit internet tropes.