> While going through the simulator, I was shocked with the response to some choices and situations. I was not aware that these things were so disruptive to some people.
Well, I guess the simulator did a good job spreading awareness that it is like that for some?
I have ADHD and while I'm medicated I cannot fathom some of the struggles or decisions that unmedicated me makes... like I struggle to have empathy for unmedicated me.
I imagine without such deep personal experience it would be much harder or impossible to understand or empathize.
> All that really matters is consistency. Let a team make some decisions and then just move forward.
Not so! Amount of tokens correlates to perceived code complexity to some. One example is how some people can't unsee or look past lisps parenthesis.
Another example is how some people get used to longDescriptiveVariableNames but others find that overwhelming (me for instance) when you have something like:
userSignup = do
let fullName = userFirstNameInput + userLastNameInput
userName = take 1 userFirstNameInput + take 10 userLastNameInput
saveToDB userName
Above isn't bad, but imagine variables named that verbosely used over and over, esp in same line.
Compare it to:
userSignup = do
let fullName = firstName + lastName
userName = take 1 firstName + take 10 lastName
saveToDB userName
The second example loses some information, but I'd argue it doesn't matter too much given the context one would typically have in a function named `userSignup`.
I've had codebases where consistency required naming all variables like `firstNameInputField` rather than just `firstName` and it made functions unreadable because it made the unimportant parts seem more important than they were simply by taking up more space.
> I promise after a week you'll just get used to whatever format your team lands on.
Arthur Witney formats like this:
C vt[]="+{~<#,";
A(*vd[])()={0,plus,from,find,0,rsh,cat},
(*vm[])()={0,id,size,iota,box,sha,0};
If your code was formatted automatically like that, do you think you'd get used to it after a week?
My point is there is meaning of how code is formatted and there is an effect on understanding for certain people.
I think that at a certain point of "reasonable" and for most "normal" people your statements hold true, but I don't want anyone to think that every person caught up on formatting is just doing it for bike-shedding or other trivial reasons.
I don't know what is actionable if what I say is true, but it feels important to say.
The unreadability of that example has approximately nothing to do with code formatting, which is generally understood to refer to modifying the textual representation of the code while leaving the actual logic more or less unchanged. Can you propose some alternative whitespace or indentation scheme which would make that example significantly more readable?
I give lots of feedback to Copilot in the hopes it makes the agents better in the long-run. I want them to read my code and train on it, along with the interactions with copilot, which is the next frontier in (post) training
The stereotype is that a big truck implies you're compensating. The only people who think an unimpressive vehicle means you have small bits are the people who think that an impressive vehicle means you have big bits.
> Google has been sued and lost for much lesser privacy infringements, like tracking users while in incognito, which if you read the suit is pretty absurd.
But those suits dont matter:
- the penalty they have to pay is laughably small
- consumers by and large dont know or dont care enough to switch away from Chrome.
The snap back to "now it's time to give your morning standup update" hit hard btw :)