undefined | Better HN

0 pointsTade01mo ago0 comments

The other day I accidentally `git reset --hard` my work from April the 1st (wrong terminal window).

Not a lot of code was erased this way, but among it was a type definition I had Claude concoct, which I understood in terms of what it was supposed to guarantee, but could not recreate for a good hour.

Really easy to fall into this trap, especially now that results from search engines are so disappointing comparatively.

0 comments

smilliken1mo ago

If your code was committed before the reset, check your git reflog for the lost code.

shimman1mo ago

Yeah, git reset --hard is something I do like once a week! lol

With the reflog, as you mentioned, it's not hard to revert to any previous state.

ajdegol1mo ago

Guess you’ve sorted it but it might be in the session memory in your root folder. I’ve recovered some things this way.

ejpir1mo ago

have you tried to recover it with git reflog?

https://oneuptime.com/blog/post/2026-01-24-git-reflog-recove...

jatins1mo ago

> but could not recreate for a good hour.

For certain work, we'll have to let go of this desire.

If you limit yourself to whatever you can recreate, then you are effectively limiting the work you can produce to what you know.

rileymichael1mo ago

you should limit your output (manual or assisted) to a level that is well under your understanding ceiling.

Kernighan’s Law states that debugging is twice as hard as writing. how do you ever intend on debugging something you can’t even write?

satvikpendem1mo ago

It's simple, they'll just let the LLM debug it!

This is why I believe the need for actually good engineers will never go away because LLMs will never be perfect.

Tade0OP1mo ago

Exactly. It's a force multiplier - sometimes the direction is wrong.

Same week I went into a deep rabbit hole with Claude and at no point did it try to steer me away from pursuing this direction, even though it was a dead end.

jatins1mo ago

> Kernighan’s Law states that debugging is twice as hard as writing.

100%, but in a professional setting you often work with code _not_ written by you. What if that code is written by someone well above my ceiling?

j / k navigate · click thread line to collapse

0 comments

smilliken1mo ago

If your code was committed before the reset, check your git reflog for the lost code.

shimman1mo ago

Yeah, git reset --hard is something I do like once a week! lol

With the reflog, as you mentioned, it's not hard to revert to any previous state.

ajdegol1mo ago

Guess you’ve sorted it but it might be in the session memory in your root folder. I’ve recovered some things this way.

ejpir1mo ago

have you tried to recover it with git reflog?

https://oneuptime.com/blog/post/2026-01-24-git-reflog-recove...

jatins1mo ago

> but could not recreate for a good hour.

For certain work, we'll have to let go of this desire.

If you limit yourself to whatever you can recreate, then you are effectively limiting the work you can produce to what you know.

rileymichael1mo ago

you should limit your output (manual or assisted) to a level that is well under your understanding ceiling.

Kernighan’s Law states that debugging is twice as hard as writing. how do you ever intend on debugging something you can’t even write?

satvikpendem1mo ago

It's simple, they'll just let the LLM debug it!

This is why I believe the need for actually good engineers will never go away because LLMs will never be perfect.

Tade0OP1mo ago

Exactly. It's a force multiplier - sometimes the direction is wrong.

Same week I went into a deep rabbit hole with Claude and at no point did it try to steer me away from pursuing this direction, even though it was a dead end.

jatins1mo ago

> Kernighan’s Law states that debugging is twice as hard as writing.

100%, but in a professional setting you often work with code _not_ written by you. What if that code is written by someone well above my ceiling?

j / k navigate · click thread line to collapse