Hacker News Reader

Hacker News

Comment by enobrev | Hacker News Reader

Parent Full thread

enobrev

> code that I wrote myself is hard to read

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.

View on HN

Semi-related story of mine:

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...

I'm getting the statement about once a quarter at work of:

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.

Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.

I have a giant dev file (well, 2 really: 1 for personal, 1 for work) that I use as a scratchpad. Anything I work on goes there. Makes it easy to find things.

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.

It drives me nuts when you find a forum post and they never reported back. Or it's a terse "I figured it out."

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.

I try to at least move the problem forward. However does anyone have a way they make sure to close those things out and circle back? I mean other than just doing it?

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.

Wisdom of the Ancients

https://xkcd.com/979/

Or it say "Google it" and thats how you ended up there.

I've found a good way to do that is running a personal blog. In fact, I write as if the audience of my blog will be myself in the future. It's nice to help out others who face the same problem tho.

I'm sad that I cannot share my experiences the same way :-( 99% of my "interesting" bugs are almost all Xbox One/PS4 related, so I can't write a blog post about "how I found out that Sony's implementation of file read is not compatible with regular stdio" - it's hugely interesting but this stuff is NDA'd to such an extent that I wouldn't risk writing openly about it - but I'd love to.

It's a recurring theme with me, though a bit different where my name is under step 3, and I only realized that when I tried to upvote the question and couldn't.

THANK YOU!!!

I really thought this only happened to me :-)

Have experienced this too. Haha.

Heh, that happened to me too... I loved it.

Does "Sbd" stand for something, or is that your username?

Somebody

Uh, OK. Never seen that before.

"Sby" would've made way more sense. Or heaven forbid we use one more character to make the nearly obvious "sbdy."

The abbreviation "sth" occurs here a lot, probably because of people who learned English with the help of dictionaries that use "sth" as an abbreviation for "something". I suspect "sbd" also comes from the same source.

SO is my notebook.

This.

Why create my own silo of documentation when I can just put the answer where I'm likely going to find it (Stack Overflow).

This is probably the primary actual use case for comments. Explain why something is done the way it is; to justify to those who come after why Chesterton's Fence [1] should apply in this case.

[1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

That someone being me not knowing why in hell would I write this monstrosity... git blame + some archeology work to get jira ticket number (I put issue numbers in commit message/branch name) and from that I know why.

Yes, naturally "those who come after" often includes the future you.

Much of my life as an older dev includes balancing my relationship with my past, current, and future selves. Be kind to your future self; be compassionate of your past self. And don't forget, they really are different people ;)

Same idea should apply to laws. The why gets forgotten a half century later because the problem was solved but not well documented. Because the problem is no longer happening, they think the law must no longer be necessary.

As a counterpoint, we often end up with laws, traditions, and social mores that long outlive whatever rationale they had for them in the first place. (Assuming they had a rationale, and weren’t just based on fear and superstition).

Yes.

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.

Here's what happened to me(A) and a friend(B) from a former workplace of mine(open-source project):

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.

This is really funny. So good. I ask all the time, "Who wrote this shit??" knowing it was probably me.

That is the only time I dare ask it. When else do I dare? Someone might take it the wrong way otherwise.

Honestly, this is usually a good sign. I'll code at the edge of my current skill. Six months from now, I hope I can look at that code and consider it primitive from where I hope to be then.

I've had that happen several times, but once I actually did the inverse.

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.

The "who wrote this?" mentality is a trap that's good to avoid. Get comfortable with different ways of writing something that, while they might have different tradeoffs, accomplish the same thing, and try to see past that. Understand that most code wasn't written by anybody--lines 1 and 3 were written by Alice a year ago, line 2 was written by Bob 2 years ago, and line 4 was written by Alice yesterday. `git blame` is very useful for seeing the change in context, which can give a lot of insight into why it's written that way, but usually the author isn't very useful to know, unless you're planning to ask them about it. Sometimes it's useful if you happen to know that the author isn't very familiar with something when you're wondering why they didn't use it, but try to keep in mind what the actual benefits of your way are, whether they're especially pressing, and that the other person might have written it differently because they were thinking about other concerns that you forgot.

I’ve always found the svn alias ‘svn praise’ pretty entertaining for this reason.

git has "git annotate"

While lots of legacy code emerges organically the way you describe, there are in fact many people in the industry who I'd call "legacy coders." People who saw Dijkstra's "Goto considered harmful" and scoffed, "all these 'for' loops are much less readable than my 'goto loop1' solution." People who use global variables because parameter-based implementations are "needlessly complex."

Basically, not everyone works for Google.

You say that, but Golang has gotos, while being a very minimal language. Not everyone at Google is an amazing developer that's fully up to date with best practices and patterns.

Not that that needs to be said, no matter the company (if it's of any decent size.)

It’s often helpful to know who wrote a line of code, because then I can put myself into their shoes and try to figure out what was going on their mind when they wrote it.

Assuming those lines were getting out of hand, I think it would be a valid question as to why they were not tidied up during the review of the line 4 addition by Alice.

It’s Friday afternoon, you are exhausted after a busy week, the business is pushing for a fix before you leave and you have committed to be home by 6pm so your spouse can go out.

I agree that “who wrote this” is dangerous, and git blame is a terribad name. I will say though, if you can avoid value judgements, then knowing who wrote a block of code is super valuable in a legacy code base. I’ve found that every dev I’ve ever worked with has very real strengths and weaknesses. And knowing who wrote a piece of code can drastically reduce the time it takes me to find hard bugs. It often goes something like, so and so tends to forget certain kinds of edge cases, but they never seem to screw up this kind of logic... so I bet the problem is related to... ah found the problem. But never blame someone for creating bugs, unless it’s really egregious, and then, only if you can help them with better habits going forwards.

I really like this approach of using git blame, it's original thinking and highlights how much human components there are in developing.

Yes, "blame" is not a good word.

Use "git annotate" instead.

`git log -p` is vastly superior to `git blame` for determining why a file is the way it is.

That gives you all the history (or all the history of a file).

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.

*genius

These days my rule of thumb is to not try to rewrite or generalize until I or my team has tried to do more or less the same thing three times. Before that, you just don't have a good feel for what is generalizable/edge case or what is invariant/variable in the problem space.

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.

Generalizing even when you are only using your solution once can sometimes be useful.

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.

As a technique against this, at the point that you're writing the code to begin with, have you ever tried documenting the reasons you're doing something even if it's blatantly obvious at the time?

   // 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.

like, totally obvious. except six years later when the regex stops matching, and you are already using the API all over the code anyway and you get to this part with the scrape and you don't get it. Are we trying to elude the API requests number limit? or what is the reason for this bizarre scrape.

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.

> code that I wrote myself is hard to read

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

The best feeling for me is when I come across old code and then re-write it to make it [simpler | faster | clearer | better] .. It is tangible proof to me that I have improved in my craft.

I usually do this same thing. But not before mentally cursing out the programmer that wrote this poorly documented spaghetti code... After which I realize it was me.

Even well factored code looks like spaghetti at a casual read in a lot of frameworks/cases, and makes sense once you've swapped all that info back in.

>but with better comments

Communication, especially with your future self, is an important skill.

Code twice: once to understand, once to solve.

As in "42", the first bit is more difficult.

And each time this happens, you get better about writing readable comments up front describing edge cases and difficulties so that future self can avoid steps 1 - 6 with a head start on refactor ideas / feasibility.

> git reset --hard HEAD

story of my life

> git stash # i might need this one day And i never need it.

I've started saving my stashes to branches instead.. adding a _ on the front of the branch name to remind me to delete the branch at some point

Out of curiosity, do you ever actually delete the branches? I would absolutely just end up with a number of _-prefixed branches on all my projects.

I don't allow myself to have more than 1 active stash at any given point on a project. You quickly learn to delete with no regret some code you wrote !

Better than the other way round.

> Re-realize the edge-cases and difficulties

I think comments can help avoid such scenarios.

This isn't quite the same situation but it reminds me a little bit of xkcd.com/1421

Reply on news.ycombinator.com