Flarnie @Flarnie@mastodon.technology

Hey web devs - please make your apps work across browsers, because if we don’t, and Chrome becomes a monopoly, then we won’t have any alternatives when Google makes a harmful decision like allowing blocking of “use source”.
https://mastodon.technology/@Flarnie/107258819275685082

So far, from what I see, NFTs are -
- scams
Or
- DRM
It looks grim.

Chrome team just landed a patch that lets sites block “view source”.
https://mastodon.social/@mhoye/107254323194914300

Boosting this to Twitter too bc it’s important.
Don’t fall for an NFT scam.
https://twitter.com/foone/status/1457749433844568066?s=21

“this idea that code should be self-documenting is a good prod, .. in the direction of .. packing as much into that type system as it can handle. So, don’t have a function .. that goes from a string to a string, and say with a comment that the string input is a Social Security # …’[Instead] make a structure, like a Social Security number type that has validation, .. use that as the input to this function.’ Then, yeah, when you read that function, you get a much better idea …of possible outcomes”

Back to the topic of docs/comments -
“ “the idea that you can write software that’s so clear, that it doesn’t need any documentation, hinges upon some delusion about how clean you can make the abstractions. I think you can always fantasize about having an extremely fancy type system which would capture more of the properties. ..,But that really is a fantasy. There are no realistic type systems that do a good job of this.”

Caveat - some folks abhor meetings and discussion and just want to write code, and they’d rather do 3 rewrites than have a discussion up front.
That approach can work if you can write code really fast. The code review and revisions become the architecture process.
But for most engineers a little discussion up front is more efficient.

I do admire when an engineer keeps a positive and open attitude during code review, and is willing to jump up and rewrite code if the review surfaces problems.
I also see it as a systemic failure if they repeatedly have to do many rounds of revision in code review - doing a short discussion before writing the code can ensure the architecture is not way off and all reviewers are aligned.

“And the better you get at writing, I think, is often about just having a tolerance, the way a distance runner has a tolerance for the miles, to the revision process. And that is exactly the same as a programmer. …that willingness to dive back into the same … piece of work over and over and over again, I mean, that’s the mark of quality, that’s what produces quality.” - That one is interesting.

“People I think sometimes think, “Well, no, I should just write my code so it’s really clear and then I don’t so much need to write the documentation.” And I think this is almost never true. In reality, when people sit down and think through documentation, they end up having a deeper and better understanding of the code that they’re writing themselves.” - that’s a key point.

Thanks @penryu for sharing this podcast about writing documentation.
Sharing bc it was a good read, and addresses some of my recent thoughts about writing comments in code.
https://signalsandthreads.com/writing-technically/