Hacker Newsnew | past | comments | ask | show | jobs | submit | macintux's commentslogin

> If I ask "how y'all doing?" I want to know how you and yours are doing.

I just want people to stop asking me how I'm doing if they don't care.

It took me an embarrassingly long time to figure out that "How's it going" is a greeting, not an interrogative, and I want that change undone forever.


What's interesting is you may reply, "hey, how are you?", and lots of people may be satisfied with that. Neither party actually answers how they are, yet the handshake is complete.

I refuse out of principle, but agree, that works.

I just use "Howdy".


Which is short for "How do you do?"

Good point! I guess my principles only extend so far.

Don't forget to end the conversation with "God be with ye". Or "A Dios".

Another resource I found in HN discussions: https://latypoff.com/tree-calculus-visualized/

Extensive discussion (202 comments) about 15 months ago: https://news.ycombinator.com/item?id=42373437

The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.

And for old enough code, the author may not be available, or more likely doesn't remember.


Fine, but none of that is in a normal commit message, lets be real...

Which circles back to why it's important for leadership to tackle this

Yes, but not in the form of commit messages, the parent comment described things better suited to jira tickets, documentation etc.

It feels like we're trying really hard to stretch the utility of commit messages here...


Yes, we are on our third ticketing system on our team with dead refs to old issues. PR without a commit documenting why you need a change does not normally get approved and helps a lot also at present and future review time. Lots of value for new devs to see how thinking went and why something exist and not something else etc.

Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.


So rather than commit messages that stay in the repo you want the information in a place where its lost by the next buck tracker migration?

Look, I'll make this easy to understand. The parent comment that this stems from said:

> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.

If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.


Mainly I was pushing back on: the code is the "truth"

I don't feel that is an accurate statement for any complex system.


I don't like complex systems, and I work hard not to create them.

Sure but code can't capture everything. Maybe with enough comments I guess, but not code alone. For example, code won't tell you that this feature was timeboxed hence this edgecase was not supported

And a commit message would convey that?

It could, or maybe the ticket does.

You'll at least need the discipline to include the ticket ID in the message. Links to documentation are ok, but they will likely rot and even if they don't the content may change such that it no longer accurately reflects the commit changes.

Unless something has changed (or I'm simply clueless), it's not quite so trivial to ask where my phone was on January 30th. Camera surveillance is not time-limited.

It’s quite common for cell phone carriers to provide law enforcement with historical records of which towers a phone was connected to at specific times. Also the phone itself stores detailed location history, including which wifi networks it connected to, allowing police to get someone’s movements if their phone is seized as evidence. Police can even use battery temperature history to get an idea of whether the phone was on someone’s body, outside in the heat/cold, etc.

None of that sounds as straightforward as a dragnet would be. Most require a target to be identified.

Crime would go down if everyone was executed. Your question is not the only one that matters.

On shared use trails, I suspect your voice might give out (especially given the headphone status of most pedestrians) and a bicycle bell is less ambiguous than a voice, which could be a fast walker, a runner, or a bicyclist.

I've periodically toyed with the idea of adding a locomotive horn to my motorized vehicle, but I'd be afraid that using it would cause an accident.

Ticketmaster failing to recognize that someone might want to use a ticket in physical proximity to the event is not the user's fault.

Exactly. Ostensibly, one would assume that getting closer to the place you have a ticket for wouldn't flag the use as "suspicious". To have OP demand that everyone use the app, but then blame the user for... traveling to the venue? Wild.

I’m suddenly grateful that I use my iPad, so they can’t use that signal on me.

They can see how long you stop scrolling, too.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: