1. Stumble upon some specific problem with a web framework we use.
2. Jump straight to stackoverflow.
3. Sbd had a similar issue, nice.
4. Sbd wrote a very concise answer, nice too.
5. There's my nickname under the answer. Oh, wait...
Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.
Monthly I pull out useful things into notes about that topic. Run into a weird problem with spring framework? Copy out the relevant info into springframework.md.
I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.
On internal tools I do do that but that's a smaller number.
Worse is stuff like car and fridge repair. I have no idea what forum I find qqs on.
"Sby" would've made way more sense. Or heaven forbid we use one more character to make the nearly obvious "sbdy."
I really thought this only happened to me :-)
Why create my own silo of documentation when I can just put the answer where I'm likely going to find it (Stack Overflow).
In a wider sense, you also want to explain why something is NOT done. Ie why certain other ideas don't work, or why we don't offer certain features.
B: Take a look at this shit code that I found.
A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this.
B: ...
A: Well?
B: Apparently you wrote and I reviewed/approved it.
Use "git annotate" instead.
Basically, not everyone works for Google.
Not that that needs to be said, no matter the company (if it's of any decent size.)
Git blame quickly gives you the commits you are likely interested in, then you can use them as a starting point for your git log digging.
I was working on an extraordinarily bad codebase, and stumbled upon some modular, reusable code that made my life way easier. I wondered who wrote this rare gem in that pile of shit, and checked `svn praise` for a change.
It was me.
It would have been the highlight of my then short career, if not for the fact that it meant there were no other semi-competent people on that project.
I've definitely run into this phenomenon of independently landing on the same design twice because of the same edge cases. At some point back in 2005 or so, I was working on a collision detection component for a physics engine. This was 1-2 years before the Box2D engine, so there was a significant lack of any open source options, so I was rolling my own stuff that was quite similar to Box2D (but Box2D was written much better).
One year later, I came back, looked at the code, thought "this is unreadable!" refactored it, and sure enough, stuff was falling through floors. I went back to my old code, found several comments discussing edge cases having to do with discrete time step problems, and concluded that my old code was in fact the right approach, it just didn't put comments about edge cases high enough in the call stack.
When you know that certain information should not be used in a correct solution, a more abstract approach can make sure that information stays hidden.
A really simple example: for-loops in Python 'leak' their index variable. Stick that loop inside a local function, and then you know that you can not accidentally make use of the index variable later.
A more complicated example is deliberately coding to an interface that carefully exposes only what should be exposed. Eg using a map or filter higher-order function.
// rather than use the API we parse a scrape here with a
// regex because we signed up and it doesn't have half the fields we want.
a lot of people would refactor by seeing if they can put the API call in there, but this wastes massive time you could avoid if you knew the reason for this in the first place. and maybe the API still doesn't have it, and so you put the API call in, you try to remember the reason for the scrape, and then you realize that all this is still the best way to do this, you just have to update the regex to continue to match. work that could have been saved by a simple comment telling you the reason it looks this way.
1. Found some extremely cool code, marveled how amazing it works
2. Realized I wrote it as a teenager
3. Got depressed, questioning my life decisions
Communication, especially with your future self, is an important skill.
As in "42", the first bit is more difficult.
story of my life
This has happened more times than it probably should:
1. Arrive upon some code I wrote at some point in the near or distant past.
2. Review it to get some idea of what I was trying to do
3. Laugh at my young self for being so naive
4. Refactor or Rewrite
5. Re-realize the edge-cases and difficulties
6. Remember this being a problem
7. Refactor And Rewrite
8. Either `git reset --hard HEAD` or end up with a similar solution, but with better comments
Once in a while, I end up with a [simpler | faster | clearer | otherwise better] version, which makes this process worth while - even with the false positives.