That's what I said. Parent said

> There's value in having your backtrace surfaced to end users

> You can even do what I did in the first program I ever wrote and use php code as a storage format.

__halt_compiler() is fantastic for this (mixing code + data). I've done it a few times.

Might be better to think of the LLM as the student, and you're an imposter tutor. You're trying to assess the kid's knowledge without knowing the material yourself, but the kid is likely to lie when he doesn't know something to try to impress you, hoping that you don't know your stuff either. So you just have to keep probing him with more questions to suss out if he's at least consistent.

https:// please.

...which is probably why it's required.

Otherwise the service would have to presume. Which either excludes http:// or https:// probably the first.

I've ran into this when writing an url shortener and decide that without the protocol, I'd just put https:// in there. So that people could still add webcal://, ftp:// ssh:// and http:// in there if they wish.

My manager gave me gruff the other day for adding a TODO that I had no intention of ever doing. TODOs are like a get out of jail free card. Don't want to do something the reviewer is likely going to call out? Just add a TODO.

That's why some people insists on having a name with each TODO, and some even want a name and a date.

some TODOs are actually WOULDDOs

I still find them helpful when the change is outside the cope of the current task. I especially like the ones that include both a reference to a Jira ticket (or similar), and an explanation of why, or any gotchas:

    # TODO: (CAFE-1256) Refactor steamed-liquid stuff to support non-dairy options
    #     We don't currently support non-dairy coffee additives, but once we do 
    #     we will need to ensure that the steamed-liquid transport 
    #     also alerts when users have a dairy allergy.

This is a lot of stuff to add for some things, so we might not want it everywhere, but it helps explain to a reader why we don't currently have it built (product doesn't need X yet), but also has hooks to existing (planned/canceled) tickets and is easily greppable (e.g. "non-dairy" or ticket name).

I've declared quality bankruptcy. Decisions are now driven by user needs. Did I half-ass that feature? Yes. Is anyone actually using it despite crying it's essential? No. Then it's not getting cleaned up. Are they not using it because it's shoddy? I guess we'll never know.

> Always write the simplest thing you can, but no simpler.

I don't think so. Time and time again the client will insist on stuff like "the customer only needs a single email address/phone number" but you're going to pay for that one later if you do the simple thing and add an "email" column.

Same for addresses.

And a whole bunch of other stuff...you need to normalize the heck out of your DB early on, even if you don't need it now. The code you can mostly make a mess of, just choose a good tech stack.

> You're going to pay for that one later if you do the simple thing and add an "email" column

You'll only pay if the project survives long enough for that new requirement to actually surface, which often it won't.

Go down the simple path to start, and refactor to a more complex solution when it makes sense to do so. If experience tells you the client is definitely going to ask for it later, add a “break condition” that tells you when you need to upgrade. You can put entry points into the code - comments, interfaces - to make it easier to do the upgrade.

In many many cases this doesn't work and it crashes and burns the whole project/startup company when its necessary.

Sometimes messing up your fundamental architecture means that you hit a refactoring your company won't survive (while your competition grabs all the customers who wanted that feature your architecture doesn't allow).

This is where experienced lead engineers earn their worth - they understand which parts cannot be fudged and fixed later and need to be there from the get go.

Normalise the DB from the get go (doesn't really require much effort), then charge for the fact that "actually we have a customer who has 2 email addresses".

I've come to understand the difference between programmer and software engineer, but what's the difference between (software) developer and programmer?

Maybe it's only in my head, but for me, programmers work 99% of the time with code, while developers also spin up servers, cicd pipelines, domain dns stuff, and more stuff that are not strictly source code.

Developers build software whereas programmers merely flick the switches on an Altair 8800 /s

Just drop the flat fee. Stripe is 2.9% + 30c. If they did 3% and no flat fee, then on $1 you'd get 97 cents instead of less than 70. I assume the CC companies are charging a flat fee too...unless that's just Stripe's own thing.

Hopefully the work was underway for awhile already, and maybe they just launched it now because the damage is already done?