9 ms·
> 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
by enobrev 7y ago
> 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.
- sbmthakur 7y ago> Re-realize the edge-cases and difficulties I think comments can help avoid such scenarios.
- snicky 7y agoSemi-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...
- grogenaut 7y agoI'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.
- eitland 7y agoWhich is why I am trying to get better at what I used to to: writing down and sharing problems I saw.
- gambiting 7y agoI'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.
- appleflaxen 7y ago.
- sbov 7y agoI 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.
- pfranz 7y agoIt 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.
- rags2riches 7y agoWisdom of the Ancients https://xkcd.com/979/ https://xkcd.com/979/
- grogenaut 7y agoI 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.
- chinhodado 7y agoIt'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.
- HeyLaughingBoy 7y agoTHANK YOU!!! I really thought this only happened to me :-)
- james_s_tayler 7y agoHave experienced this too. Haha.
- harel 7y agoHeh, that happened to me too... I loved it.
- Buge 7y agoDoes "Sbd" stand for something, or is that your username?
- taatparya 7y agoSomebody
- PunksATawnyFill 7y agoUh, 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."
- deleted 7y ago[deleted]
- hollerith 7y agoThe 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.
- hyperpallium 7y agoSO is my notebook.
- collinmanderson 7y agoThis. Why create my own silo of documentation when I can just put the answer where I'm likely going to find it (Stack Overflow).
- jjeaff 7y agoI 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.
- grogenaut 7y agoEven 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.
- Sharlin 7y agoThis 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 https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence
- mpolsz 7y agoThat 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.
- Sharlin 7y agoYes, naturally "those who come after" often includes the future you.
- gilbetron 7y agoMuch 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 ;)
- dd36 7y agoSame 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.
- mr_toad 7y agoAs 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).
- 7y ago
- mgolawala 7y agoThe 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.
- Tade0 7y agoHere'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.
- carapace 7y ago*genius
- harrisreynolds 7y agoThis is really funny. So good. I ask all the time, "Who wrote this shit??" knowing it was probably me.
- yxhuvud 7y agoThat is the only time I dare ask it. When else do I dare? Someone might take it the wrong way otherwise.
- heelix 7y agoHonestly, 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.
- koala_man 7y agoI'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.
- kbp 7y agoThe "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.
- SkyMarshal 7y ago>but with better comments Communication, especially with your future self, is an important skill.
- polyterative 7y ago> git reset --hard HEAD story of my life
- tehlike 7y ago> git stash # i might need this one day And i never need it.
- fouc 7y agoI'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
- larkeith 7y agoOut 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.
- C4stor 7y agoI 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 !
- anoncake 7y agoBetter than the other way round.
- glaurung_ 7y agoThis isn't quite the same situation but it reminds me a little bit of xkcd.com/1421
- munchbunny 7y agoThese 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.
- eru 7y agoGeneralizing 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.
- bitL 7y ago> 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
- logicallee 7y agoAs 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.
- hyperpallium 7y agoCode twice: once to understand, once to solve. As in "42", the first bit is more difficult.
- decisiveness 7y agoAnd 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.