Re: Push Ifs Up and Fors Down

My weird mental model: You have a tree of possible states/program flow. Conditions prune the tree. Prune the tree as early as possible so that you have to do work on fewer branches.

Don’t meticulously evaluate and potentially prune every single branch, only to find you have to prune the whole limb anyways.

Or even weirder: conditionals are about figuring out what work doesn’t need to be done. Loops are the “work.”

Ultimately I want my functions to be about one thing: walking the program tree or doing work.

Waterluvian, 15 hours ago

Re: At Amazon, some coders say their jobs have begun t...

To me it feels like part of the hype train, like crypto & VR.

I recently had the (dis)pleasure of fixing a bug in a codebase that was vibe coded.

It ends up being a collection of disorganized business problems converted into code, without any kind of structure.

Refinements are implemented as super-narrow patches, resulting in complex and unorganized code, whereas a human developer might take a step back to try and extract more common patterns.

And once you reach the limit of the context window you're essentially suck, as the LLM can no longer keep track of its patches.

English (or all spoken human language) is not precise enough to articulate what you want your code to do, and more importantly, a lot of time and experience precedes code that a senior developer writes.

If you want to have this senior developer 'vibe' code, then you'll need to have a way to be more precise in your prompts, and be able to articulate all learnings from your past mistakes and experience.

And that is incredibly heavy. Remember, this is opposite from answering 'why did you write it like this'. This is an endless list of items that say 'don't do this, but this, in this highly specific context'.

OptionOfT, 18 hours ago

Re: Frequent reauth doesn't make you more secure

Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.

Many (most?) companies still do it, despite it now not being recommended by NIST:

> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)

https://pages.nist.gov/800-63-3/sp800-63b.html

Or by Microsoft

> Password expiration requirements do more harm than good...

https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide

But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).

montebicyclelo, 13 hours ago