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

All the time.<p>The old joke is about us looking at code we wrote six months ago, and being horrified at what we see. And I&#x27;ve had more than my share of that.<p>But what&#x27;s ALSO happened, many times, is I look at old code I wrote... and I&#x27;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.<p>&quot;Wow, I wrote THAT?!&quot; Because I was deep in a coding trance when I wrote it. So deep &quot;in the zone&quot;, that when I come out, it&#x27;s not easy to recapture where I was. Not even the next day, and certainly not months later.<p>Interesting how it works!

Way back, when Paul Graham first wrote &quot;A plan for Spam&quot;, I was so intrigued upon first reading the article, that I jumped straight into coding.<p>I happened to be hosting my own mail server at the time, and I had previously implemented a crude spam filter, but the important part is that all my emails were already stored in a database and (crudely) classified as spam or ham, so I had a corpus available for training the classifier.<p>I spent a couple of hours in &#x27;the zone&#x27;, and wrote a Bayesian email classifier plus all the database management needed in a few hundred lines of C. The program compiled the first time - a first for me - and worked correctly the first time - another first. It did help that I had been heads-down in a complex project written in C for several months at that time, so my knowledge of the language and good design- and implementation practices were at an all time high.<p>That same program managed my spam pretty much unaltered for several years, until I switched to a commercial email host. Every few years, I still dig up that code as an example of good design and implementation.

Programming isn&#x27;t unique in allowing you swing between moods of &quot;this feels great :D&quot; and &quot;I&#x27;m so dumb&quot;. (I think most people feel like either at times, even hours apart).<p>But Fred Brooks makes a good point with:<p>&quot;&quot;&quot;The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....<p>Yet the program construct, unlike the poet&#x27;s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […]<p>The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.&quot;&quot;&quot;

What 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&#x27;s some corner case or weirdness in an API you&#x27;re calling.

Everyone&#x27;s talking about code, but I do this with carpentry. Right now, I&#x27;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-one else will ever notice them.

The only thing I have ever gone back and admired is when I wrote the following snippet of code:<p><pre><code> long time; &#x2F;&#x2F; no see</code></pre>

Yes. Early on in my career, I needed a function that produced a range of dates, given a start and end date. After it was all said and done, it boiled out like so:<p><pre><code> def daterange(start,end): while start&lt;=end: yield start start +=timedelta(days=1) </code></pre> Though simplistic and straightforward, I admire the solution. I am sure there may be “better” ways to achieve the same result, and posting this here may result in cowboys trashing it or pointing out a fallacy - oh well... at the time, I was pretty satisfied with it and am still to this day.

I&#x27;ve had the joy(?) of working for a company for close to 10 years, moving on to other work for about 5 years, and then returning again.<p>During my first tour with the company I built, among other things:<p>- (on a two-person team) an ASP.NET web app that allows payroll admins to extract year-end data from their AP in order to distribute tax forms (W-2s, 1099s, etc.)<p>- (different two-person team) a mail-room management back-end that allowed us to print&#x2F;mail over 1 million forms&#x2F;year for customers of the above<p>- (yet another two-person team) A corporate intranet product<p>Since returning to the company I&#x27;ve been on another small team (3 developers) building an independent payroll platform. As part of that effort, we&#x27;ve had to integrate with all the other things I ever built at the company. It&#x27;s been extremely valuable for our team that I have intimate knowledge of basically all of our integration points across the company. Much of my original comments and code from ~2007-2015 are still in the source tree. Some of that makes me happy, and some of that makes me cringe :)

It&#x27;s been years since I&#x27;ve asked a question on Stack Exchange. There comes a point when any place I get caught up nobody can help me. So there are several questions I&#x27;ve answered myself. Of course, working in the same space six months later, I&#x27;ll have a problem, search for it, and land on the question on Stack Exchange that I&#x27;ve answered months earlier. It&#x27;s happened a few times.

I have a Notion database of code Snippets for this purpose.<p>Described this in a recent blog post: <a href="https:&#x2F;&#x2F;tkainrad.dev&#x2F;posts&#x2F;managing-my-personal-knowledge-base&#x2F;#notion-snippet-database" rel="nofollow">https:&#x2F;&#x2F;tkainrad.dev&#x2F;posts&#x2F;managing-my-personal-knowledge-ba...</a><p>It&#x27;s nice to take a moment after finishing a project, a challenging task, or whenever you feel like it and preserve snippets that you are proud of. Going through these pieces of code later brings back memories of these past projects, teams, tasks,...

I keep a copy of some very old code, from 15ish years ago, and I&#x27;ve peeked into it a few times in recent years when facing similar problems to what I&#x27;ve solved there, only to be horrified by what a pile of garbage that was. So there&#x27;s also a fun element in that - seeing how far I&#x27;ve come. It&#x27;s a good laugh.<p>I have a bunch of open source projects from more recent years up on Github that I look at once in a while when I&#x27;m looking for a solution for something, and they tend to be less piles of shit. BTW my biggest project open source project has been taken over by a whole team after I&#x27;ve left it, and I can&#x27;t recognize most of the code now, that&#x27;s a really weird bittersweet feeling.

I&#x27;ve always loved seeing recursive functions I wrote in the past. The amount of power and elegance that can come from a good recursive function is my favorite.

My number one favorite time is after I sold a company. Two years later, the company contacted me as the old CTO and asked me about some piece of core technology. They asked me to take them through it and show them what was going on since they wanted to migrate it into something else.<p>My first question was, &quot;Haven&#x27;t the other developers ever touched it.&quot; They said no. This core piece of technology scaled to way more users and was essential to making 100s of thousands of dollars for the company. It didn&#x27;t even break once in two years. It was core to the service and they were just asking how to move it. I was so proud of previous me.

One I like to go back to is the micro-kernel scheduler written in assembly I did for a grad school project: <a href="https:&#x2F;&#x2F;github.com&#x2F;mbcrawfo&#x2F;avr-kernel&#x2F;blob&#x2F;master&#x2F;kernel&#x2F;core&#x2F;kernel_asm.s" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mbcrawfo&#x2F;avr-kernel&#x2F;blob&#x2F;master&#x2F;kernel&#x2F;co...</a><p>It seems so much more interesting than the web stuff I do today.

I wouldn&#x27;t call it admiration. Most of my code archeology is like &quot;this code is a mess, what fool wrote that. git blame... oh, it was me&quot;

I generally admire the architecture and and some nice and elegant tricks on my past code, but not the code itself. I always feel like things could be cleaner, with better names, with a more consistent coding style (I am quite severe to my self on this point).<p>Much older code is generally neither smart neither beautiful though.

Yes! Some code reflects what the requirements demand, including error handling, and no more. The design is elegant in that it abstracts properly, is very readable and extensible. Periodically, when I&#x27;m feeling down about my abilities, I look over this code and smile.<p>Often I look at my older code and recognize the stage of development as a coder that I was in. It&#x27;s usually not cringe-worthy but it makes me pensive about how I would handle it now.<p>Another joy is when I find out that a module I wrote is being used extensively by other developers. Just recently I found out that a small, single-purpose function I wrote for my specific needs and deployed to our shared library, is fundamental to another team. They asked me about modifying it for requirements they have. The code itself wasn&#x27;t beautiful but it filled a need and could be understood well-enough to modify by another. It made me happy all day.<p>And yes, other creative pursuits give me the same joy. Some practice sessions on my drums seem effortless. My ideas seem to flow regardless of the technical difficulty. Likewise, some dinners I make are chef-level tasty and get the desired &quot;yummmm&quot; from my wife and daughter.<p>Keep a memory of the times when your code makes you smile. Those memories pull you through the down times.

I don&#x27;t feel proud of my code if it works but I do feel terrible about it if it doesn&#x27;t work perfectly. As soon as I realize that there is any problem in any of my projects, I need to drop everything and fix it immediately or else I can&#x27;t sleep or think about anything else.<p>I guess not being able to carry on with my life if I know that my code has the slightest issue means that I assume it is perfect and therefore I&#x27;m idolizing it.

When I was ~15 I wrote this: $c=`clear`;for(`tail -c+324 $0|zcat`){if(&#x2F;^p&#x2F;){print@l;@l=()}elsif(&#x2F;^d(.+)&#x2F;){select$u,$u,$u,$1&#x2F;10}elsif(&#x2F;^s(.)&#x2F;){$s=9;$e=-30;$m=-1;if(&#x27;o&#x27;eq$1){$s=-30;$e=9;$m=1}for($i=$s;$i!=$e;$i+=$m){$j=0;for(@l){print substr($_,$i+$j++&gt;0?($i+$j)<i></i>2:0,-1).&quot;\n&quot;}select$u,$u,$u,.1;print$c}}elsif(&#x2F;^c&#x2F;){print$c;@l=()}else{push@l,$_}}__END__<p>Which (with ~1.5KB of binary data appended, total under 2KB) creates this: <a href="https:&#x2F;&#x2F;code.shishnet.org&#x2F;videos&#x2F;floating_point.mp4" rel="nofollow">https:&#x2F;&#x2F;code.shishnet.org&#x2F;videos&#x2F;floating_point.mp4</a><p>I feel like my youthful stupidity unlocked a lot of potential - I managed to make a lot of impressive fragile hacks which only needed to work once, and worked once. These days if I tried to create an animation like the one above, I’d probably get a couple of thousand lines into writing a well-tested reusable framework, and get bored before seeing any results...

Sometimes-- but most of the time when I look at code I wrote and was proud of but 6months or a year later-- I&#x27;m like, what was I thinking- I would of done it differently now. I call it programmers remorse. Since we&#x27;re always learning and patterns change over time based on technology I think that most programmers live in a constant state of embarassment over things they previously had done.<p>However-- sometimes (with increasing rate into my 15 year carreer) I need to modify something and had not touche the code in a long time-- only to find to my supprise I already had that feature or ability coded into it... I then have to say &quot;Thanks Past Jon- This is Future Jon (to you) and noice forward thinking&quot;<p>While in isolation due to gobal things... it&#x27;s a good time to make sure Past you and Future you get along-- Present you (third state) is both past and future but leave some notes for Future [yourname] and make sure if you find notes from Past [yourname] you remember to appreciate their work.

Just to continue the analogy about carpentry &#x2F; home construction. About a decade ago when I moved into my apartment it came with a wall mount for the TV that had a tricky mechanism that would not be clear to a casual user how to mount&#x2F;unmount from quick looking. And it would be even more difficult to figure out with a TV in the way.<p>10 years later, it&#x27;s time for me to move out, and I&#x27;d left the TV as the last thing because I had forgotten how to work the mechanism to get the TV off the wall (and it would require all sorts of annoying face-against-the-wall maneuvering to see how to unscrew, etc).<p>I look from the floor up behind the back, and what do you know -- I&#x27;d left myself a taped note, extra bolts, and instructions on exactly where to turn the hidden lock screws (in the state where the TV already mounted) to release the unit from the wall.<p>I was marveling at my foresight for a self-satisfied minute (and thanking my past self).

No, I mostly go back and surrender to not understanding why I wrote what I wrote. Yes, I am in awe. But because it&#x27;s a like a third person wrote it.<p>Regardless of comments.

I often return to things with reluctance, assuming massive technical debt, only to be pleasantly surprised (sometimes I am pleasantly offended!). I&#x27;ll usually attempt a &quot;haut-syntactica&quot; refactor, only to fall back into the flow and elegance of the original work ... tho I definitely have a tendency towards over-engineering in the first instance.<p>On an aside, someone here mentioned that python 2 isn&#x27;t python 3, in that the code itself gets old quick. But I don&#x27;t think that really comes into it. Unless you&#x27;re spaghetti-plugging holes in clients, there&#x27;s a lot of joy to be had in manipulating any language or system to a desired end, especially when it&#x27;s hard won, and I would think too when you return and see yourself in the result.

Best feeling I ever got was when I was starting out using list comprehensions and ternaries in Python. I sometimes got the (slightly creepy) feeling I wasn&#x27;t so much writing this thing myself but using a feather duster carefully to clean away the cobwebs sort of like an archaeologist. That feeling of &quot;discovery&quot; is what I use to guide me. If it&#x27;s not there, I know there&#x27;s a better implementation. Got me thinking about Socrates and how discovery could really just be recollection. So my take is a little bit opposite what you are calling for. It&#x27;s not &quot;I wrote that!&quot; with pride but &quot;I was used to bring that about!&quot;.

&gt; Are there analogous feelings in other creative pursuits you practice?<p>Not exactly a “creative pursuit” but often with legal work it takes <i>years</i> for any sort of feedback on a document’s effectiveness. Sometimes you’re alerted to a potential issue and your first thought is “yikes, there’s no way I drafted for that”. Much like coding it’s always a good feeling when you go back and see that you had contemplated the weird scenario and drafted accordingly.<p>I’ll admit it feels a bit more “magical” when it happens in my code though. I think perhaps because the stakes are lower so I can appreciate the work instead of feeling like I’ve dodged a bullet.

There&#x27;s one particular piece of code I&#x27;m especially proud of, coming from a side project. It&#x27;s a non-trivial amount of code, and it&#x27;s not the cleanest code, and it has bugs and missing functionality. However, as a library it hits the sweet spot of:<p>1. Zero dependencies<p>2. Lightweight abstraction<p>3. API enforces correctness in usage<p>4. API covers the problem space well enough that the API hasn&#x27;t changed since a couple months after initial release (it&#x27;s been 3-4 years)<p>5. Library does something all of the individual pieces of software using it couldn&#x27;t have done individually - not easily anyway.<p>When I first started working on the code, I guessed (correctly, in retrospect) that for technical reasons changing the API after version 1.0 would be a struggle, so I reached out to 3 of the more prolific developers in the space who needed what I was working on and collaborated with them early to rapidly iterate on the API. I declared 1.0 a couple weeks later once it felt like we were all pretty happy with the product.<p>I wasn&#x27;t the only person working on that specific problem. In fact IIRC my solution was the third &quot;to market&quot;. However, by really pushing to get through multiple iteration cycles in collaboration with my intended users, the bunch of us managed to converge onto a simple and durable design which ended up becoming the de facto standard.<p>It&#x27;s not my most elegant code, but it solved a specific in-demand problem and did a clean job of it.

I&#x27;m working on a mobile game using an ECS-based engine I wrote myself.<p>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&#x27;m not as dumb as I thought I was, and made some actually good choices early on that greatly eased my development burden now.

I wouldn&#x27;t say admire. When I stumble upon code from many years ago I (somewhat painfully) realize I&#x27;ve lost a lot of the ingenuity I used in my early days. I read the code and find myself thinking &quot;how the hell did I come up with that solution&quot;. I didn&#x27;t care about finding the optimal algo&#x2F;ds, I would just use whatever I knew at that moment without a second thought. Now I have to care a lot more about writing code that looks smart and learning &quot;new&quot; frameworks.

My first ‘real’ program. Written in VB6 in 2005. It connected to a state message switch using dmpp2020 protocol. It function was to run drivers license numbers and return a photo for Police Officers. It had two components- a back end that connected to the state and a web based front end. They were connected through a sql server. The front end wrote a request to a table and the back end monitored that table. The response from the state was then returned into another table. It was used by a couple of agencies including our 911 center. This was necessary as binary objects were a new thing at the time and neither our CAD or RMS system could do anything except plain text. So the subject of this - do you ever go back and admire your code - in this case I go back and wonder how it ever managed to function lol. Seriously. In reality though my admiration was in how rock solid it was. It’s last use :( was in 2017 so it was in service for 12 years and during that time it crashed literally never. I can’t say the same for the our other interfaces to the same message switch. So thanks HN for the opportunity to remember that!

Not entirely mine but beautiful nonetheless:<p><pre><code> @dataclass class Node: id: str children: List[Node] = field(default_factory=list) # beautiful Python: traverse a tree depth-first, pre-order (stack based) def __iter__(self): stack = [self] while stack: node = stack.pop() yield node stack = node.children + stack</code></pre>

&gt; Are there analogous feelings in other creative pursuits you practice?<p>The &quot;wow this was clever&quot; feeling I&#x27;m sure exists in all kinds of creative pursuits, but for artistic creativity I doubt the &quot;somehow it works!&quot; feeling is the same. If it connects with an audience you probably wonder if it was just marketing and luck, and if it doesn&#x27;t, you wonder if it&#x27;s just your own personal taste.

I have some stories about old code but this is a nice one: in my old job I&#x27;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.<p>I soon got tired of drawing circles and numbers and decided to write a quick Gimp plugin that does just that:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;silasdb&#x2F;mark-number-circles&#x2F;blob&#x2F;master&#x2F;mark-number-circles.scm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;silasdb&#x2F;mark-number-circles&#x2F;blob&#x2F;master&#x2F;m...</a><p>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&#x27;ve ever written and from time to time I get an email from a random person from the world thanking for this small script :-)<p>EDIT: fix English

I have an old A* pathfinder I wrote in C about 13 years ago that I revisit with surprising frequency. Every now and then I&#x27;ll have a glass of whisky and pull up the .h and .c files and smile.<p>The code is good, but something about the simplicity of the language and the bareness of the algorithm that makes that header and source file pair so meaningful for me.

Yes! I do! But they’re never the parts I think they’ll be. Sometimes it’s the simplest of things like a nice CRUD api that’s bounded and neat. Sometimes it’s a horribly complex system with well known trade offs and intricate guarantees. I love looking back and thinking “yea I got that right” or seeing an abstraction that’s stood the test of time (my six year old report query definition and data table responses in a reporting system is one concrete example I’m proud of, but I’d rename some fields for sure). I have a few of these that I’m so proud of if I really stop and consider it. On the flip side, the majority of projects teach me something that I wouldn’t do the next time, hence the common “old code sucks” trope. I think it’s important to recognise when something worked as much as when something didn’t. It’s these successes that give me the confidence to try things a little outside the box if I think it’s for the best.

I find that some ideas gestate on the backburner &quot;I wish I had time to implement feature X&quot;.<p>Then upon going into the code I realize the basic framework already exists to implement the feature.<p>One of the more pleasant experiences in our code base.<p>The negative experiences of &quot;Did I write this?!?&quot; tend to be driven by performance bottlenecks and profiling.

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 (<a href="https:&#x2F;&#x2F;unix.stackexchange.com&#x2F;q&#x2F;36307&#x2F;3645" rel="nofollow">https:&#x2F;&#x2F;unix.stackexchange.com&#x2F;q&#x2F;36307&#x2F;3645</a>), and someone actually went and implemented it in C! Fast forward a few years, and I&#x27;ve reimplemented most of it in Rust with 98% code coverage (<a href="https:&#x2F;&#x2F;gitlab.com&#x2F;victor-engmark&#x2F;cronlist" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;victor-engmark&#x2F;cronlist</a>). It&#x27;s very likely neither optimal nor idiomatic, but every time I implement something using TDD it&#x27;s a hundred times more readable than without, even when using an unfamiliar language.

I immediately think of my very simple 17-line constraint satisfaction problem solver which has saved me so much work.

My one particular stand out accomplishment was back in the Lumatic (RIP) days. We were a small app that provided pedestrian navigation in cities that included public transit. When we expanded beyond a single city we quickly learned we had to deal with timezones. The straightforward thing was to convert the times in each GTFS feed (the file containing scheduled transit times&#x2F;stops&#x2F;etc) to UTC. So I started digging into to the horrors of the tzdata format and spent a solid 8 hours looking into options there, hit a wall, tabled the project for a few days after which time an idea popped into my head: change the timezone for the process serving the city to match the timezone of the city. Sure enough, changing the TZ environment variable worked like a charm and unix did the rest.

Yes, absolutely.<p>More fulfilling for me however is not the code itself, but significant results. I have captured&#x2F;framed a few graphs in my career that look like a &quot;sudden jump&quot; or a &quot;sudden drop&quot;, which were caused by deploying a more elegant solution to a problem or pain point.

Perl code mostly. I rarely use Perl anymore and my current code is much more straightforward and maintainable that the Perl stuff I wrote but wow was some of it elegant and clever. I enjoyed writing lots of it which isn&#x27;t something I experience much anymore.

Not on purpose but sometimes I need to get back at an old project and it always takes a few minutes to get my mind around it&#x27;s architecture again. Sometimes, as I re-understand why I did things a certain way, I get aha-moment and am sort-of proud I guess.

Writing parsers with parser combinator libraries (personally, I use FParsec on F# and pyparsing on Python) feels like this all the time. I am especially happy about one doubly-recursive, parametric parser I had to write to handle an expression grammar of this kind:<p><pre><code> &lt;Expr&gt; ::= &lt;Reference&gt; | &lt;NumericLiteral&gt; | &lt;Expr&gt; &#x27;+&#x27; &lt;Expr&gt; | ... &lt;Reference&gt; ::= &lt;identifier&gt; | &lt;ArrayRef&gt; &lt;ArrayRef&gt; ::= &lt;identifier&gt; &#x27;[&#x27; &lt;Expr&gt; &#x27;]&#x27; &lt;Varname&gt; ::= ... (The parser is parametric in the parser for &lt;Varname&gt;) </code></pre> ... without upsetting the F# typechecker.

Yes, but only with a fairly small share of the code I&#x27;ve written in the past. Most of the code I&#x27;ve written is nowhere near as good as it could be; some of it is embarrassing.<p>By the way, for me this happens with all forms of creative&#x2F;original endeavors, not just with coding: Sometimes I read and admire passages I wrote in clear, lucid English in the past. Sometimes I look at and admire mathematical equations I wrote in the past (even if I&#x27;m no longer as well-acquainted with them as when they were fresh in my mind). Sometimes I look at and admire diagrams I sketched in the past, e.g., for a research project.

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.<p>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&#x27;s so rare for me to feel that... That&#x27;s probably why I prefer working among less experienced developers. That way I can see myself as comparatively better and feel good about myself.

One of my very first was Inna domain parking app, that it tried to &quot;fertilize&quot; any domain that was pointed to the server. It would obtain feeds piped via Yahoo feeds for keywords from the domain, and sell the domains later at higher price for the slightly better SEO value.<p>I still love the domain parser I had there. I actively tried to avoid regex by the time, and I had a huge validator that brings tears to my eyes. I admire it because this can be written with a single regex, but I am sure I spent an hour or two working on this, carefully planning about public suffixes, IDN conversion, host headers, etc.

Definitely. I wrote a React application that had a large amount of flexibility requirements for a client. They would need to re-purpose this application to deploy on multiple client sites with a variety of contextual content. I built a sort of navigator wrapper that would allow arbitrary content, but meet a pretty extensive list of contextual requirements as well. It was a fun elegant solution and they were expecting new child pages to take days to add, I showed them how a decent developer could add them in minutes.

I have some big programs that serve more as touchstones for me. I am familiar with the layout and I can see the various functions that work very well.<p>I tend to do a lot of ETL-like stuff, essentially tanks that roll in one direction relentlessly. If there is an uncaught exception, it gets Pokemon-caught because it is okay if <i>that one row</i> doesn&#x27;t happen, I can examine the problem later. The tank must roll forward. Each problem encountered in the wild results in another chunk of armor.<p>Select techniques from different tanks are often handy.

I have on one or two occasions come up with a pretty neat algorithm for some task that seemed really clever. Later I&#x27;d learn that I wasn&#x27;t the first to invent it and that so-and-so had discovered that algorithm years ago. It could make me sad, but usually it makes me think, &quot;Hey! I&#x27;m as smart as that programmer!&quot; or at least, &quot;Hey! I have been as smart as that programmer was when they came up with that algorithm! I&#x27;m not a complete idiot!&quot;

I&#x27;m opposite. Never ever I felt proud of my code, I always am critical of it and thinking in the back of my head &quot;I know how to refactor it even better&quot;. It&#x27;s a never-ending story for me. And whenever happen to do maintenance of a old project of mine from years ago I cringe of the way I implemented some stuff and plenty of times I have to restrain myself to not refactor it since the client wants only a simple change while the refactoring would eat away my free time.

I don&#x27;t code, but I do write. I regularly re-read my own writing to spot any problems, but sometimes just for pleasure. For example, about 18 months ago I wrote a 5 part series on how to build a direct conversion receiver for the ham radio bands from scratch. I learned tons along the way and it was really rewarding to write. Re-reading it recaptures some of that joy and reminds me that I&#x27;m a good writer, even when I think I&#x27;m just another hack.

I&#x27;m 50 now, but when I see the code I was writing in my teens and twenties, I&#x27;m convinced I am nowhere near as clever anymore. Time to get back to my roots.

Not really. If you remove the algorithm part (which can be drawn very nicely and admired on paper) you have code. And code age, and it ages fast. Python 2 is not Python 3. C++11 is not C++20. I see the changes that need to be done instead of the beauty of the work.<p>There has been some exceptions, mainly in my Haskell-code, a monad still seems to be a monad and I start to see it with a more &quot;math-focused-lens&quot; and then I start to find some small admiration.

Most of the time. But that applies to code that I wrote in last 15 years, especially in Sciter, its core was written around 2005.<p>I believe there is a moment of maturity in any developer&#x27;s career. And it is related to critical mass of experience - when for pretty much any new task you know upfront how it should be done , at least architecturally. And in different variants: ideal, realistic or just to show something.

There have been a few times that I&#x27;ve really admired code that I wrote ... it happened way more often building embedded systems where I was short on processor cycles and memory.<p>But I&#x27;ll also comment on the opposite (which I attribute to continually trying to improve my craft). Often when I look at code I wrote &gt;6 months ago, I find something that I&#x27;d do differently today. Sometimes it&#x27;s downright distasteful!

That&#x27;s just how some people are. For what it&#x27;s worth, I can&#x27;t look at anything I make and be happy with it; I only see the flaws, omissions, and infelicities. If you can be proud of what you make, then great!<p>Nobody cares either way, though; code ultimately has its own notion of quality, and human aesthetics are totally unrelated to code quality. We all must learn to think like computers and appreciate code like computers do.

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

Rarely !<p>But what regularly happens is that I stumble on my own comments and&#x2F;or helper methods, which saves me a ton of time.<p>Turns out that having a clean code structure with clear places to have those 5-liners that you need all the time is really useful, and by now I&#x27;ve got so much of them that they compose quite powerfully ! And old comments are like gold nuggets when the time comes to debug.

Yes. I wrote some Rust code about 3 years ago. I&#x27;ve set it aside until the IDE situation improves, and now I look at it to remind me that I wrote that (not too shabby) code because I want to pick up Rust again at some point and if I went by the tone of the articles on HN (Rust is hard, you&#x27;re constantly fighting the borrow checker, etc) it would be too discouraging.

I&#x27;ve never written a single line of code that I liked. I enjoy programming, but I&#x27;m a terrible programmer even after... Jesus, thirteen years. Sometimes I&#x27;m not totally unhappy with my solutions, but most people here could do a hell of a lot better. Fortunately, that doesn&#x27;t keep me from getting paid and delivering acceptable work.

I resonate with the feeling of joy of having translated thoughts into a concrete result :) More often though I find all sorts of loopholes and alternative ways I could&#x27;ve done the same thing. Perhaps, it&#x27;s because we&#x27;re viewing an older thought process, and have sufficiently dissociated ourselves with it, so we&#x27;re able to neutrally critique it.

I revisit my generalized monoidal FizzBuzz implementation on occasion. It&#x27;s hard not to given it&#x27;s elegance and beauty. :) <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;lgastako&#x2F;d4fa392cbe85cbfae7dfa5e18c14a2a4" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;lgastako&#x2F;d4fa392cbe85cbfae7dfa5e18c1...</a>

I remember writing this library <a href="https:&#x2F;&#x2F;github.com&#x2F;tuladhar&#x2F;adns-ruby" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tuladhar&#x2F;adns-ruby</a> few years back. I sometimes go through the code to be in that moment again and be &quot;man I wrote this&quot;. I cannot express that feeling, but it feels great.

Yes. But if you can figure out what it does you’re going to be really sad.<p>{ eval &quot;package &quot; . __PACKAGE__ . &#x27;::&#x27; . (0+$class) . &quot;; use base qw(&quot; . join(&#x27; &#x27;, map { ref($_) || $_ } @_) . &quot;);&quot; }<p>This might help:<p>my $package = bless $class, __PACKAGE__ . &#x27;::&#x27; . (0+$class);<p>Or this:<p>return Devel::Pointer::unsmash_hv(substr(ref $self, 2+length(__PACKAGE__))); }

I admire this library of ordinal notations I wrote, which can be considered as a systematic meditation on the nature of strong AI and more specifically on computer programs that write computer programs:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;semitrivial&#x2F;ions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;semitrivial&#x2F;ions</a>

Sometimes I leave random&#x2F;joking comments around my code if I&#x27;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 &quot;# i fink yo freaky and i like u a lot&quot; in the middle of some brambles I was untying.

All the time.<p>I have learned very useful tricks over time, like the ability to automate code creation to incredible levels with my own dialects of lisp that makes me hundreds of times more productive.<p>But when I was young I used scalable vector graphics to document everything I did, and some ideas I had are quite impressive to me today.

Sometimes my old code is “why did I over engineer this, it’s so hard to trace through”<p>Other times it’s “I think I really nailed the dev UX on this.”<p>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.

Maybe in the first 6 months or so after writing it.<p>After that, I occasionally go back through old code asking &quot;what have you done for ME lately?&quot; and an eye towards dragging it behind the toolshed and going &quot;Ole Yeller&quot; on it.<p>My code has to continually prove its worth to me, or else it&#x27;s gone. Code is a liability.

No. I really don&#x27;t have that courage.

I do reminisce,but do the opposite of admire, perhaps because my day job has never been primarily to write code.

I do sometimes go back and stare at this wonder I crafted once:<p><pre><code> s=&gt;s[0]+&#x2F;.*( .|z)|...s.s?|T..|M[i-t]+|[AFINOUW][^o]v?|.*&#x2F;.exec(s)[0].slice(-1).toUpperCase() </code></pre> It does something pretty useful, that has surely been written many times over. But unlikely ever as succinctly as this. :)

I admire my old code when I go back to that code and by reading the code, see some idiosyncratic behaviour. Then a pay slightly more attention and see my own comment in the code saying that the author knows about it and that was the assumption made in the first place.<p>Otherwise code can always be made better.

I wrote a GPS coordinate mapping tool for a fun project once. I wrote it on a train, and I didn&#x27;t have the device that was going to use it. I sent them the link and they said it worked perfectly. I doubt the code was very good, but we just used the first version for the project.

I&#x27;ve only been coding for a few years now.<p>Often I&#x27;m sort of irked by my old code.<p>But it is telling that from time to time I find some old simple code that was easier to read &#x2F; change than I expected if only because I coded it so simply and in an iterative sort of way.<p>There&#x27;s something to be said for being simple...

I had this feeling from time to time, usually right after finishing a project. While every relevant contextual details are still fresh in my mind.<p>Admiring an older piece of code that I&#x27;ve written more than last year? Rarely, unless it&#x27;s just a small puzzle or self contained code.

It is the best way to stay motivated as a programmer. The power to model a real world scenario into code and seeing it work has been my motivation to keep coding. Make sure you also look at that stupid code once in a while and ponder &quot;What was i thinking?&quot;

I publish as much of my stuff as I can as MIT License, just so if I need to re-solve a problem I&#x27;ve seen before in three years and I&#x27;m at a different job, I can say, &quot;Didn&#x27;t I solve this three years ago?&quot; and go back and repurpose the old code.

I used to do a fair amount of artsy stuff, and always stepped back to admire my work at multiple points in the process, as I suspect isn&#x27;t uncommon among artists<p>Now at times when I have the space and time to code things the way I wanted, I step back and do the same :)

I&#x27;ve got a big text file of 6502 machine code I wrote a few years back that I pull out and marvel at from time to time. One of those things that you have to be fully in the &quot;zone&quot; to pull off, so it seems like magic to present-day me.

If you don&#x27;t occasionally go back to appreciate what you&#x27;ve built, you&#x27;re probably not taking enough pride in your work.<p>If you don&#x27;t occasionally go back and become horribly embarrassed at what you&#x27;ve done you&#x27;re probably calcifying.

It will pass :) And you&#x27;re looking at the code right after you wrote it.<p>If you look at your own code months or years later (some applications do need maintenance), you&#x27;ll hate it or be ashamed of it. But you should know better than improving it by then.

Once or twice. I still remember a Perl routine I wrote probably 10 years ago. It&#x27;s maybe 10-12 lines long, but what I remember is that I wrote the entire routine in one continuous train of thought, ran it and it worked on the first try.

What are you problem solving approach when implementing a particular feature,functionality and it is the first time you are doing or you have been stuck for days and not able to figure it our, how do you guys go about it?

I can get this feeling with non-novel code when I slot something into a larger framework (following the paradigm). I find that easier to walk away from than writing novel code, as it takes longer to feel satisfied with the latter.

There is one instance which I wrote almost a year back. It&#x27;s does nothing special, hasn&#x27;t increased the company&#x27;s revenue but it does one thing and does it best.<p>Right now the whole file is changed but that code is still intact.

Less so with the code per se and more with some elegant or minimalist abstraction it implements.<p>So the best bits are probably the multipage comments that precede a handful of lines of code and explain what&#x27;s going on :)

I&#x27;m still proud of my LTE RRC layer protocol implementation for mobile phone testing: design, implementation, its ability to work with diverse physical layer emulators... Wrote it probably 10 years ago.

Funny thing, I update one of my first iOS apps from time to time and I still see the quality and more important consistency of the code I wrote. It&#x27;s a breeze to maintain.

Yes, i still like how we were able to run 72 voicemail lines on one machine under a ms-Dos environment with 5Mb coax network. Written under Pascal, still got the code.

I did it few times, most of them were cases when I took extra time to enable extending the code instead of writing ad-hock code that fit only the problem at hand.

Yes, I do this sometimes. I feel proud of most of the things that I wrote but not about stuff that was written by multiple people and where I just added some things.

When I like to reminisce, I go back and look at my recursive code.<p>So much of my code is boring, flat, procedural code, because that&#x27;s what the job calls for.

You should always take pride in your own work regardless of what profession you&#x27;re in. There&#x27;s nothing wrong with that at all.

Only if I go back to a language that I haven&#x27;t used for a few years where I don&#x27;t remember how the solutions are implemented.

All the time. I put pride in my code. I worked in various teams and codebases and came to appreciate the quality of my code.

I&#x27;m a fan of my recursion scheme examples :p<p>For the most part my standards get higher as time goes on though. So only small things!

I not only go back and read old code, I still <i>use</i> some code I wrote thirty years ago on a day-to-day basis.

Yes. Sometimes I can&#x27;t believe how smart I was back then and wondered what happened to me.

<p><pre><code> amountFulfilled = isFulfilledOnSite * quantity </code></pre> yes, isFulfilledOnSite is a boolean

No - I&#x27;m hard on myself and so look back and always say &quot;this is sh!t&quot;

actually I do this from time to time. because I tend to forget about the beauty of it. this is one of the nicest thing about being a developer, to be able to step back and enjoy the work. I take this as a motivation for clean code.

Kinda, except the opposite.

Every bloody monday I admire the naivety of the code I wrote friday.

Yes. But not as often as I cringe at something I wrote.<p>C&#x27;est la vie.<p>Live. Learn. Adapt. Move on.

Yes, I also get surprised on how I implemented the solution.

I&#x27;m usually like &quot;Who wrote this shit?&quot;

I wrote an very concise recursive solution to one of our interview problems. Not really &#x27;good&#x27; code because its hard to read and reason about, but I enjoy looking at it every 6-12 months.

No, usually I never

yes I check back my previous leetcode submissions before interview and sometimes amazed how the hell did i come up with that.

rarely. mostly i look back in horror.

we call this code review