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

201–210 of 267 posts

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

#201

Post by bitwize »

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…

"I am a builder," the end user replied. "Many of the houses of this town were made under my chop."

http://www.catb.org/esr/writings/unix-koans/end-user.html

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

#202

Post by l0b0 »

I once had the idea for a tool which would print the next few crontab runs, to make sure they were staggered correctly. Asked on Stack Overflow how to do it (https://unix.stackexchange.com/q/36307/3645), and someone actually went and implemented it in C! Fast forward a few years, and I've reimplemented most of it in Rust with 98% code coverage (https://gitlab.com/victor-engmark/cronlist). It's very likely neither optimal nor idiomatic, but every time I implement something using TDD it's a hundred times more readable than without, even when using an unfamiliar language.

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

#203

Post by benwills »

lanstin wrote: post #190
benwills wrote: post #183

Earlier quoted context omitted.

This sounds awesome. C is my preferred language and I use it whenever I can and when it makes sense. I'd love to see this code. Is there a public repo for it?

Try go :) it's got the speed and "here's how the machine works" of C plus a) batteries included for all the modern things, and b) excellent multi-core scheduler. On the grandparent, I never much wrote a ton of C and then compiled, did more "skeleton of the app/lower level bits/stich them together" incremental stuff. So lots of compiling and testing along the way. Not quite Lispy but Lispy for C.

I have, and I do use it for projects (and plan on using it for more). But I also need C for things that require certain performance I'm unable to get out of Go.

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

#204

Post by juliend2 »

Maybe a fun side project I did in Python a while back: a small source-to-source transpiler. I find it beautiful for the simple fact that it feels idiomatic and good python code, based on some inspiration I got from other (senior) codebases back then.

I think (for me at least) it has a lot to do with what I see what good™ programmers are doing. If it matches that, then I allow myself to consider it good. But it's so rare for me to feel that... That's probably why I prefer working among less experienced developers. That way I can see myself as comparatively better and feel good about myself.

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

#206

Post by silasdb »

I have some stories about old code but this is a nice one: in my old job I've needed to write technical documentation about a GUI we had developed. This consisted in making numbered labels in pictures using Gimp, embedding the pictures in a LibreOffice document (at the time, OpenOffice) and writing what each item was about.

I soon got tired of drawing circles and numbers and decided to write a quick Gimp plugin that does just that:

https://github.com/silasdb/mark-number-circles/blob/master/m...

I new nothing about Scheme at the time (the script is written in an imperative style) but I still think it is one of the smallest and most useful pieces of code I've ever written and from time to time I get an email from a random person from the world thanking for this small script :-)

EDIT: fix English

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

#207

Post by scarface74 »

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’ll do comments first and then code. It’s a lot faster for me to keep a flow and pseudocode and then write the code in between. If the comments are two pedestrian afterwards (increment i), I will erase the comments.

I started this technique early in my career back in the late 90s after reading “Code Complete”.

It also helps me to pick back up faster if I get interrupted.

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

#208

Post by lhuser123 »

bonniemuffin wrote: post #192
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).

I sometimes wonder why it’s so difficult to find people like that.

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

#209

Post by BurningFrog »

jjice wrote: post #96
Rainymood wrote: post #84

Earlier quoted context omitted.

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.

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

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

#210

Post by dmckeon »

scarface74 wrote: post #207
woah wrote: post #156

Earlier quoted context omitted.

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’ll do comments first and then code. It’s a lot faster for me to keep a flow and pseudocode and then write the code in between. If the comments are two pedestrian afterwards (increment i), I will erase the comments. I started this technique early in my career back in the late 90s after reading “Code Complete”. It also helps me to pick back up faster if I get interrupted.

I’ve heard that styled as “do project the document, don’t document the project” but I don’t know a source to attribute this to.

The idea is to write a rough draft that covers what the project is, what it does, the API structure, and how to use the project, then write the code, “projecting the document”, and finally sort out the documentation - comments in the source, everything else in a manual page, article, or research paper.

Post reply on HN