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

The team that makes the decision to change issue management systems and not to back up the data is rarely the team most affected by that decision.

Frankly even if the store was on breach of its consignment agreement, that seems like a case corporate would have against the prior owner (and one it would be hard to prove damages in), but not one that would give them any rights to the property of the lego collection owner.

The answer has always been “I asked Bob and Bob half remembered you worked in it once”, without any attempt to look for info, in my experience :(

When I get that, I just repeat the question "where did you look in the docs?", or just "go look at the docs now" if they're really dense. I can't help them until they have a better answer.

It takes a few tries before they internalize that they need to have a doc link before expecting my help. Once they do, I might take the next step to saying "here's the answer; can you update the docs so the next person doesn't have to ask?" And it might take a few tries before that sticks too. My goal is to eventually turn them into someone who evangelizes the docs themselves.

When I write peer reviews for my colleagues, I describe their attitude toward documentation. If that's "they refuse to open the docs, frequently wasting their colleagues' time", it's not gonna go well. If it's "they make nice doc edits after I ask them", a little better. If it's "they proactively maintain the documentation", better still.

Of course all this is for stuff that one could reasonably expect to be documented. Help thinking through a design problem or debugging their in-progress PR is generally a different situation.


That's when you direct them to the docs.

People rag on StackOverflow for being mean, but it was a good training ground for developing habits that satisfy the social contract of professional spaces.


Usually not so bluntly in the first email but I’ve seen a few emails in my spam that seem likely to have been leading that direction.

Well if they want to stop all improvements to their electric car industry that is letting them out compete European, Japanese and US manufacturers, solar panels have clearly not been important to them, and their rocket programs don’t need anyone working on transfer orbits and god forbid anyone describes the materials they test as “diverse”…

Headphones are a big one for me. By their nature, the cords are often going to get snagged and tugged on and are pretty much guaranteed to fail before the headset itself does. I'm pretty happy my current Sennheiser headphones have detachable headphone cables, though the shaky ground the company itself is on makes me wonder if I should stock up on a few...

My $300 Sennheisers have a detachable cable. My son's $99 Sennheisers have a detachable cable. My $25 almost-noname headphones have a detachable cable.

I think a detachable cable is a widespread option, as long as the headphones are large enough to make accomodating it easy.


Having been often called by coworkers to assist them with their git problems, I can assure you they don’t have a git mental model.


When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.


The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires.

Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.


Are you me? I do feel like I'm starting to forget git as a result of my happy jj use. Thankfully some repos use git submodules, which keeps me at least a little connected

I recently had to do a flight without my headphones, because they had discharged because the switch had got jostled and activated in my luggage. 10 years on, we're still running into the disadvantages of losing 3.5mm headphones, so of course there's complaints.


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

Search: