Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you ever go back and admire a piece of code you wrote?

news.ycombinator.com

Post reply on HN
Print view View original

191–200 of 267 posts

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#191

Post by 6510 »

woah wrote: post #156
jjice wrote: post #96

Earlier quoted context omitted.

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.

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.

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.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#192

Post by bonniemuffin »

frosted-flakes wrote: post #97

Everyone's talking about code, but I do this with carpentry. Right now, I'm working as a trim carpenter in residential construction, and I pride myself on doing as good a job as I can. As a result, when I come back to a job to install door hardware after everything is painted, I sometimes just wander around the house and admire my work. Especially tricky details that took a bit of thinking to get right, even if no-on…

The guys who installed new tile in my shower put in a custom shower niche that incorporated an interesting tile pattern, and I was glad to notice them taking pictures of it when they were done. It was neat to see their pride in creating an elegant one-of-a-kind feature (in what was otherwise a fairly routine project).

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#193

Post by lanstin »

lsaferite wrote: post #108
mcv wrote: post #90

Earlier quoted context omitted.

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.

I came to write basically this exact thing FWIW. Always write the why, not the what. It's the clear difference between useful comments and excess noise.

There are particularly clever one liners that need a bit of unpacking on the what - Python is bad for this but anytime you are patting yourself on the back for the cleverness, a brief note (at least on the test) is probably warrented. I supposed one can code without cleverness but it's less fun :)

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#194

Post by frosted-flakes »

tonyedgecombe wrote: post #169
dehrmann wrote: post #144

Earlier quoted context omitted.

How does one find a trim carpenter (or any skilled tradesman) who has this level of attention to detail? There's definitely two tiers of work, someone who cares and work good enough for a rental unit, and you have no idea what you're going to get until it's done.

I've noticed good trades people always take pictures of their work. I'm now wondering if it's worth asking to see images of their recent jobs.

Yeah, I take pictures too, but I've never really done anything with them. Mostly for my one satisfaction, but I suppose they could be useful to show customers.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#195

Post by ekimekim »

woah wrote: post #156
jjice wrote: post #96

Earlier quoted context omitted.

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.

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.

I think this is a matter of coding style.

When I'm writing something I'm generally "top down", breaking the problem into sub-tasks. In this mindset I'll often start a sub-task with a comment describing what it needs to do, and then set out to do it. If it turns out I was wrong about what I needed to do then I update the comment, but that's not that common.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#196

Post by kylek »

Sometimes I leave random/joking comments around my code if I've been in a rabbit hole for a long time and end up with a preposterously simple and elegant solution. I erupted with laughter a couple days ago seeing "# i fink yo freaky and i like u a lot" in the middle of some brambles I was untying.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#197

Post by hermitdev »

bryanrasmussen wrote: post #110
SketchySeaBeast wrote: post #77

Earlier quoted context omitted.

When I started my first programming job the CEO told me that programming is 59 minutes of feeling like an idiot and 1 minute of feeling like a genius. It's really stuck with me, and has so far proven true.

What's awful are those bad days when it's actually hours and hours of feeling like an idiot, draining you away, and then when you figure it out you still feel like an idiot because first off it was so simple and second of all solving something in minutes is not going to wash away hours of feeling like an idiot. Luckily as I have gotten older I have gotten fewer and fewer of those days.

I once had an issue where it appeared my servers were leaking less than a byte of memory per request (WTF? less than a byte?).

It took months to find the bug. Turns out it started leaking once the filesystem quota was reached, the log tried to roll and failed. All logging messages were just building up in a queue. It was a definite face-palm moment once found, but yeah, took months to get there.

I had a similar issue w/ a high-res timer that was causing spurious socket timeouts. Only found because...logs were saying operations were taking +200 years to complete. That was about 6 weeks of time during development.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#198

Post by hermitdev »

cordite wrote: post #187

Sometimes my old code is “why did I over engineer this, it’s so hard to trace through” Other times it’s “I think I really nailed the dev UX on this.” These days I’m prioritizing more on conveying intent and proper use by name, location, and signature. And it seems to be supporting me back over the last two years oh my current codebase.

I have this problem with a codebase I work on now. Basically, the program flow is: 1. Download file 2. Load file to local DB 3. Load local DB to cloud 4. Load cloud to different local DB 5. Generate file for other system.

Really annoying, really over-engineered, and of course, undocumented. To boot, it also utilizes dependency injection because... There are no unit tests, no mocking, nothing. No reason to use DI other than to obfuscate. Very frustrating. It's 10Ks worth of C# that I could do in a few hundred in Python (and have it perform better).

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#199

Post by bitwize »

I'm working on a mobile game using an ECS-based engine I wrote myself.

Almost every time I add a significant feature to the game -- a new enemy or object type, a state machine for enemy AI, etc. I brace myself for a drawn-out process -- and am surprised to find that things come together rather well and straightforwardly, with a minimum of bugs and glitchy behavior. And I think to myself, huh. Well, I guess I'm not as dumb as I thought I was, and made some actually good choices early on that greatly eased my development burden now.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#200

Post by bitwize »

redsymbol wrote: post #80

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

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

Post reply on HN