13 ms·

All the time. The old joke is about us looking at code we wrote six months ago, and being horrified at what we see. And I've had more than my share of that. B

• Rainymood 6y ago
  Me writing docstrings: God this is so much work for nothing... my code should speak for itself. Me 6 months later: Thank god I wrote docstrings, what is this garbled mess.
  • jjice 6y ago
    100%. It's amazing how many GitHub repos have little to no comments, not even file or function overview comments. The amount of time save by potential contributors reading and having to interpret the code is way longer than it would take for the author to write the comments in the first place. To each their own, but comments are generally a positive addition to code.
    • CmdrKrool 6y ago
      Yes, the greatest value add of comments for me is the potential time-saving, in the ideal case (re)acquainting you with a large work of code by guiding your attention from the top-down - firstly to orient you in the broad structural aspects, then to fly you smoothly down towards the minutae of reading individual lines of code. This does sometimes entail a few 'what'-style comments, so I'm disappointed to regularly read of programmers that have apparently taken up arms against them.
      • t-writescode 6y ago
        Are they ‘what?’ or ‘wat?’ comments? Maybe that’s the difference?
        • whynaut 6y ago
          what, opposed to ‘why’ or ‘how’
          • t-writescode 6y ago
            No, I understand that part; but, I think of a "what" comment as "incrementing value of X" a "wat" comment, like the meme, is more of a "this is a really weird blob of code that might be obvious when you break the whole thing apart; but, what it's doing is _this_ this is the implementation of it because we have a complicated data structure that's connecting all these pieces"
    • woah 6y ago
      I find it's not useful to have comments in code that you are actively working on since they quickly get out of date. They are best added when one finishes work on a block of code.
      • jannotti 6y ago
        I get the feeling, but I rarely think "I'm completely done now, time to comment!" Better to admit that and document a bit earlier than when it's "finished".
        • lanstin 6y ago
          More accurate comments that way, isn't it. Nothing sadder than the optimistic comment from before implementation, which took the regular twisty path towards correctness in the corner cases. More of a risk for the higher level methods than the little "DRY" functions that do something relatively functional.
        • miketuritzin 6y ago
          I frequently think just before committing/pushing, "Time to add some comments!" That doesn't mean the code is fully finished, but it does provide a clear point in time to add them (when needed).
      • hermitdev 6y ago
        At a previous job, when I transitioned off a few projects that I had solely worked on for 7 years, I warned the dev taking over from me: I don't usually comment my code, but when I do, you'd better pay attention. I think in one of them, only a single source file (C++) had comments, and there were more comments than code. I was explaining an intricate locking pattern around a data cache. Like you suggested, I added the comments after I'd done the work because it was a work in progress. I added the comments because it was a very fragile piece of code and sensitive to changes (e.g. really easy to cause a deadlock or race condition if changed).
      • 6510 6y ago
        While working on it my comment explains what the block should be doing. Extra points for lists of harebrained ideas that will likely never happen.
    • BurningFrog 6y ago
      I think there are levels: Level 1: Garbage code with no or bad comment. Level 2: Garbage code with good comments. Level 3: Good code with comments Level 4: Code good enough that it doesn't need comments, with rare exceptions. Each level is better than the previous. You can't level up directly from 1 to 4. Still, 4 is the best level. I know it sounds weird if you haven't seen it.
      • zadler 6y ago
        I still think a file should have at least some small comment at the top to help orient the reader and set expectations.
      • Sevaris 6y ago
        I don't think level 4 exists. There is no code for problems of sufficient complexity that are self-explanatory. There are too many hidden assumptions and foreknowledge and tradeoffs and decisions baked into a block of code that, unless it's trivial, there's no way code itself can reflect it adequately.
        • jbotz 6y ago
          It does exist, but only for snippets, sections of code, or at best whole individual functions, especially in languages that are concise and expressive (which are most languages that are not Java ;-). But even really good code still needs comments about how things fit together, what to find where, etc., because those things are generally not expressible in programming languages, although a good module system can help a lot with that.
        • BurningFrog 6y ago
          I have three things to say about that: 1. I did allow for "rare exceptions". Some things do need to be explained outside of the code. Maybe we're not so different after all :) 2. There are a number of techniques to write such code. Before I learned them, I had NO IDEA. One is to take what would have been comments and use them as variable or function names. This includes (and I had real resistance before I accepted this) breaking out a variable of function only in order to give it an informative name. "Level 4" doesn't just happen. You work at it for a long time and sharpen your skills in that area. 3. To me, much of the art of writing software is to find ways to divide a complex problem into simple pieces. If my code is real complex, I look for simpler way to write it. And I look hard.
  • Beltiras 6y ago
    I always advise juniors to document their code because they never know, next maintenance programmer to touch it might be themselves. I can't remember why I wrote code a week ago, let alone 6 months.
  • mywittyname 6y ago
    Especially when it comes to data structures. It's so helpful to see a comment with an example of the structure of a variable, especially because you won't have the same context when you come back to it in a few months. I know some people don't feel that way, because I've been dinged for it in code reviews as something that should be covered in unit tests. But I think digging through unit tests to glean the structure of an object adds a lot of overhead.
  • cpascal 6y ago
    On a bit of a tangent here, but good commit messages are another thing I really appreciate 6 months later.
    • delusional 6y ago
      I love good commit messages as well, but it can be hard to convince people to write them. I always hear "Why? i don't use them" which is self propelling. You don't have good messages, so you don't read them when you want to know something, so you don't write good commit messages.
      • hermitdev 6y ago
        Another thing I like to put in commit messages is the ticket# (of what ever bug tracker you're using) of the feature/bug task that drove the change.
      • saagarjha 6y ago
        I don't really do comments all that often (generally, only for "Chesterton's fence-esque" things) but I do really rely on good commit messages. They are really helpful when going back in history and trying to get a general idea why something changed.
• lvturner 6y ago
  I have lived to see both ends of the spectrum from "who wrote this, it's awful" and "wow, who wrote this it's beautiful" I wish I could see over time that the latter takes precedence, but I'm just happy these days that the majority most falls somewhere in in the midpoint between both extremes.
• mmsimanga 6y ago
  I once wrote a stored procedure that did something that has now been built into most databases. I didn't write the original code, I just modified the code to use the information schema. It took me two days to understand the original code and two days to make my changes. For a few years after I wrote that code I got emails from random people asking me questions about it and I sadly could not help them.
• cm2187 6y ago
  I am never impressed by my own style, but I do forget very quickly all the corner cases that the code had to deal with, so I am always impressed that “that guy” thought about those details that are completely outside of my radar!
• wrenky 6y ago
  I have several pieces of code from 5+ years ago that I have zero idea how they work or how I came up with that approach. Its proof that past me was much smarter than present me.
• bitwize 6y ago
  > But what's ALSO happened, many times, is I look at old code I wrote... and I'm IMPRESSED. Just blown away by the beautiful elegance and power of the abstractions I came up with, the sheer intelligence of the approach, the insight and lucidity oozing from the code. > "Wow, I wrote THAT?!" Because I was deep in a coding trance when I wrote it. So deep "in the zone", that when I come out, it's not easy to recapture where I was. Not even the next day, and certainly not months later. I attribute code I wrote in this way to "the other me". A huge problem I encountered when hitting the working world was this: common features at corporate shops, such as open-plan offices and Scrum, seem almost calculated to stifle "the other me" from coming out. It's as if the company doesn't want a programmer to rely on their other self to write the damn code, and by reducing everybody to the exact same kind of gibbering idiot and training that gibbering idiot to write code, programmers become easier to hire (because any gibbering idiot will do), and more replaceable (because you are not relying on a programmer's particularly potent other self to deeply understand, fix, and solve problems). And yes, "gibbering idiot" is about how I assess the intelligence of my normal "talking" self that has to engage with other people, especially in comparison to the "other me".
  • ivthreadp110 6y ago
    I responded without reading anyone else's comments-- I'm so happy that my Past [name], Future [name], dialogue is something other people do! You're "other me" is the same as my "Past Jon" haha-- Remember to thank your "other me" and you should make sure to drop little notes addressed to your future self-- beacuse it is REALLY rewarding to find a note you left addressing your future self like "Hey, Future Self-- If you're looking for the actual module that does the communication-- it's: [location]" And if a year later you are doing EXACTLY that-- trying to track down that thing-- and you start with something you know -- and find that note- It's hard to not exclaim- "Thanks Past Self, you just saved me some searching- hats off to you sir"
    • bitwize 6y ago
      “But even the hacker who works alone,” said Master Foo, “collaborates with others, and must constantly communicate clearly to them, lest his work become confused and lost.” “Of what others do you speak?” the Prodigy demanded. Master Foo said: “All your future selves.” http://www.catb.org/esr/writings/unix-koans/prodigy.html http://www.catb.org/esr/writings/unix-koans/prodigy.html
• MaysonL 6y ago
  Of course, when there's a subtle bug in that wonderful, beautiful code, it's a real bear to understand and catch…
• m463 6y ago
  "Wow, that just like I would have written it!" :)