When I like to reminisce, I go back and look at my recursive code.
So much of my code is boring, flat, procedural code, because that's what the job calls for.
Ask HN: Do you ever go back and admire a piece of code you wrote?
81–90 of 267 posts
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#82I publish as much of my stuff as I can as MIT License, just so if I need to re-solve a problem I've seen before in three years and I'm at a different job, I can say, "Didn't I solve this three years ago?" and go back and repurpose the old code.
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#83The only thing I have ever gone back and admired is when I wrote the following snippet of code: long time; // no see
Hehe, well if we're going here there are various go-to shell commands / filenames / hostnames I inevitably end up using at some point just for the wry smile: $ PONG=1.1.1.1; ping $PONG $ more cowbell $ cat dog | tee hee And my favourite choice of empty file: $ touch me Also I was fairly please years ago when I briefly re-aliased cd to something that could do "the right thing" (TM): $ cd ... $ cd ..../src/ etc..
I wrote a generic bash function to spin up a mongodb instance called `mongo`. I couldn't resist adding
`echo "Mongo only pawn in game of life"`
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#84All 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. 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…
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.
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#85Rereading old code (and sometimes admiring it) is a way to gauge, whether you learned something in the past month. If you did not, change your course.
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#86The only thing I have ever gone back and admired is when I wrote the following snippet of code: long time; // no see
I once came across a function that declared this:
int ofTheJedi;
return ofTheJedi;
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#87Earlier quoted context omitted.
You should really use deque for the stack
Why?
Probably just an efficiency argument, since deque is designed to be efficient when used as a stack/queue. https://docs.python.org/3.8/library/collections.html#collect...
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#88> Are there analogous feelings in other creative pursuits you practice?
The "wow this was clever" feeling I'm sure exists in all kinds of creative pursuits, but for artistic creativity I doubt the "somehow it works!" feeling is the same. If it connects with an audience you probably wonder if it was just marketing and luck, and if it doesn't, you wonder if it's just your own personal taste.
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#89No - I'm hard on myself and so look back and always say "this is sh!t"
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#90What I like better is when you are bumbling through code you wrote a while ago trying to figure something out and there it is, a golden comment from past you, telling future you why you wrote shit this way. Usually it's some corner case or weirdness in an API you're calling.
It's unfortunate that the younger generation of coders took "comments are code smell" idealogy to heart and are actively against writing comments.
Too many comments explain what is going on. That should be obvious from well-written code. But comments why it's done that way can be extremely valuable.
And sometimes there is indeed something wrong with the code. In those cases, a comment saying so can save a lot of time analyzing what's wrong with the code.