
Ask HN: How to not forget your own code? - 0bfus_cate
I&#x27;ll jump right in. I&#x27;m a developer with 5+ years&#x27; experience with programming. One of the biggest challenges I face is I forget my code very quickly. This sometimes even applies to the logic used in the code. In the heat of moment while coding, I sort of enter a trance and come up with great logic&#x2F;algorithms. However, I will forget about it after 2 weeks. After developing huge modules, I forget details about the libraries used. I try documenting&#x2F;writing comments for other developers.<p>I also don&#x27;t perform quite well in technical interviews when I&#x27;m asked about my prior work experience and side projects. It&#x27;s quite embarrassing to forgetting implementation level details in which I have put heart and soul while developing.<p>The best way to state my problem is that I am more of a RAM than a Hard Drive. Any of you face this problem? Or any idea how to overcome this problem?
======
db48x
Memory is a funny thing. It's not anything like replaying a video again, where
you see exactly the same thing every time. It's a process of reconstruction
based on a much smaller set of data than a video.

Improving your memory definitely will help you as a programmer. For example,
improving your short-term memory will allow you to write better code on a day-
to-day basis because you'll be able to hold those complex details in your head
all day, while a better long-term memory allows you to recall your past
successes and reuse code from them.

Your memory will work best when it is reconstructing the events of a story,
which is why mnemonic devices are so often constructed as a story (even if
it's a nonsense story). You should try to memorize the process by which you
developed a program rather than the exact lines of code that you wrote. This
will enable you to essentially rewrite those lines of code as you need them,
by following the same process over again. At this level it's more like
procedural graphics than a video recording.

I think there's a video of Feynman stating this for math and physics. He says
that you never memorize every single formula or physical fact; instead you
triangulate them from each other. If you need fact A but can't recall it, then
you use facts B and C that you do recall to point you in the right direction
(which might be a proof, or a sketch of a proof, or key words for a google
search, or whatever).

------
Latteland
That's interesting because I often think I do some programming in a trance
like state. I don't write out giant steps, I sit there with headphones (to
block out my stupid open office noise) and just keep working on something. I
think the answer to your problem is not that complicated.

First, add comments. Describe what you are trying to accomplish, and then the
algorithm, and put a few notes throughout your code. You should be developing
big projects in components and test the boundaries.

For interviewing, you have to go back and study what you did. For your case, I
suggest spending half an hour writing up a bullet point list of what you did
after you finish a big project. You shouldn't write about any proprietary or
internal algorithms about your company, but you can write a short list of the
problem you solved (merging a large number of sorted runs with limited memory
and xyz...), problems you faced (memory leak, or speed wasn't fast enough so
you ...). Study a few of these as you move around jobs.

------
itronitron
Forgetting what you did two weeks ago is a good thing, it gives you a fresh
set of eyes and a more objective view of your own code. If you document the
main points of the software while you are writing it then that will save you
some agony later on.

Regarding technical interviews, the only thing you can do is pick a few
examples that you want to retain and regurgitate as needed. If the interview
is getting too focused on implementation details then it may be that they are
trying to find a reason to not hire you and they will likely never be
satisfied. If you find yourself in that situation again then I recommend
slowing the pace of your answers way down so that you have time to think.

------
rococode
It feels like there are two separate questions here, I'll try to address both:

1\. How to remember how code you wrote a long time ago works

As you mention, documentation is key. It honestly doesn't have to be super
proper docs where you end up with 5x more documentation than code. Even just a
couple comments here and there, especially on code that was tricky to figure
out, will be super helpful in the future.

It also helps to have consistent naming and organization conventions - not
just capitalization or underscores but the words you choose to name certain
things and the pattern in which you modularize code. This is useful for
avoiding accidental rewrites of code you wrote in the past and helps you
navigate the codebase. It's always nice to think something like "hmm, I don't
remember where the rest of this is but I probably would've called this
ScreenManager" and then find out you really did have a ScreenManager file.

Realistically, you're always going to be forgetting old code. The key is to
structure your code in such a way that it's easy to "explore" if you ever need
to dig up an implementation detail or add some new functionality. If you have
more logically complex code, keep at least single-liner comments that lay out
what's going on. Get used to IDE commands you have like "Go to definition" \-
even if you've forgotten, most of them time you'll be able to refresh yourself
after seeing all the relevant code.

2\. How to explain a codebase you haven't worked with in a while to an
interviewer

In my experience, you typically will not need to actually explain specific
code to an interviewer. You don't need to say, "well I used a HashMap for this
and then a LinkedList for that". What you do need to explain is concepts that
you implemented, like "the clients established websocket connections to the
servers to get real-time updates in the form of a byte stream".

I find that large projects can generally be broken down into a set of
interesting features. You can keep track of these features in a separate file
and just list one or two things about how they were implemented, and refresh
yourself before an interview.

\---

tl;dr (I know I tend to get rambly)

\- leave single-line comments as often as possible

\- hop around your codebase with go-to definition when you forget how things
work

\- keep a list of features you implement for each project for interview prep

