Ask HN: Do you ever go back and admire a piece of code you wrote? - <AUTHOR> I switched careers and got into coding about five years ago and I have always wondered about this and am a little embarrassed about it.
Sometimes after finishing a big implementation, I just go back and read my own code ... and I like it! I feel proud that I translated some kind of abstract problem solving into a concrete solution, and somehow it works!
I feel like I created something that flows according to my ideas and it's a joy to look at. Are there analogous feelings in other creative pursuits you practice?
Of course not everything is like this, only novel problems I encountered have potential to give this feeling, CRUD back-end endpoints are routine by now. Also I don't feel like an exceptional programmer, feel more like an impostor, so please don't read this as bragging. <comment><USER2> 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.

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

Interesting how it works!

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

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

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

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

<comment><USER7> This sounds a lot like TDD, but with comments instead of tests. It's an interesting technique I never heard of.

Do you ever get back to code you wrote and find a lot of misleading comments that you simply forgot to delete/update? Or are you always updating the comments before you try a new approach if the first one didn't work out?

<comment><USER6> The pseudocode comments are way too detailed and too much noise to keep in the code. I'm not going to keep a comment in the code like.

       //increment i

But also if the comment is something like:

      //Call the API to get a list of customers.

I'm going to replace it with

      List<Customer> customers= GetCustomers();

Use the IDE to create a valid stub function and delete the comments. The method names become self documenting. At any point I have code that compiles.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Way back, when Paul Graham first wrote "A plan for Spam", I was so intrigued upon first reading the article, that I jumped straight into coding.

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.

I spent a couple of hours in 'the zone', 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.

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.

<comment><USER9> 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?

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

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

<comment><USER11> Use Rust, then. Rust is like Go, except its binaries are small and fast (except string formatting, which is very runtime, horribly bloated and merely "fast-ish"). Anything C can do, Rust can do better (the string formatting excepted).

<comment><USER9> What is it with people insisting on using something other than C? You don't know what I'm working on, yet you're insisting I operate completely differently?

It's so weird to me.

</comment></comment></comment></comment></comment></comment><comment><USER12> Programming isn't unique in allowing you swing between moods of "this feels great :D" and "I'm so dumb". (I think most people feel like either at times, even hours apart).

But Fred Brooks makes a good point with:

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

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […]

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

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

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

<comment><USER15> I learn to accept when I am tired and need to take a break. Sometimes hours of needling through code can be solved in minutes on a fresh brain. I used to be stubborn and wouldn't stop until I had made some progress and that went on making a tired day into an exercise in frustration. Took a while to have the confidence to shut down and start fresh the next day.

<comment><USER16> This hit me real hard, thank you I need to become better at this.

Just had a few frustrating days at work, lo and behold problem solved elegantly in 1 hour on a Great Prayer Day where I was supposed to be off-work.

The simple solution was just writing out a truth-table and then implementing it using the new C# switch expression to make sure I had all combinations taken into consideration.

</comment></comment></comment></comment></comment><comment><USER17> 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's some corner case or weirdness in an API you're calling.

<comment><USER18> I always write // XXX comments that mean there's something here I'm supposed to remember but I don't have the time to write it down right now. It's always fun going back over those and trying to reverse engineer what the hell I was thinking at the time.

</comment></comment><comment> frosted-flakes 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-one else will ever notice them.

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

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

<comment> frosted-flakes 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.

</comment></comment></comment></comment><comment><USER21> The only thing I have ever gone back and admired is when I wrote the following snippet of code:

      long time; // no see

<comment><USER22> I came across this gem recently:

        catch (Exception up)
        {
            throw up;
        }

Truly genius code

<comment><USER23>
      try
         ToastTheGenius;
      except
       On Glass: Exception do
         raise(Glass);
      end;

</comment></comment></comment><comment><USER24> 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:

      def daterange(start,end):
          while start<=end:
              yield start
              start +=timedelta(days=1)

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.

<comment><USER25> I'm struggling to understand how this is special... isn't it basically just the normal 2-argument range function, but with date instead of int?

        def range(start, end):
         while start < end:
          yield start
          start += 1

Or is it more about the beauty of the algorithm than this specific code?

<comment><USER26> I think it's just the relative simplicity of code that handles date logic compared to other languages:

[https://stackoverflow.com/questions/4345045/javascript- loop-...](https://stackoverflow.com/questions/4345045/javascript-loop-between- date-ranges)

I hate dealing with date math, but I have to admit that Python makes date math much more elegant. I've written the functional equivalent of the OP function several times, and it's just so nice to be able to loop over dates just like they were any other generic sequence.

Edit: plus you can enhance it pretty to make arbitrary increments with ease:

        def daterange(start, stop, increment='days', step=1):
             start = datetime.fromisoformat(start)
             stop = datetime.fromisoformat(stop)
             inc = {increment: step}
             while start <= stop:
                 yield start
                 start += timedelta(**inc)

        > list(daterange('2020-01-01', '2020-01-14'))
        [datetime.datetime(2020, 1, 1, 0, 0), datetime.datetime(2020, 1, 2, 0, 0), datetime.datetime(2020, 1, 3, 0, 0), [...], datetime.datetime(2020, 1, 14, 0, 0)]
        > list(daterange('2020-01-01', '2020-01-14', 'weeks', 1))
        [datetime.datetime(2020, 1, 1, 0, 0), datetime.datetime(2020, 1, 8, 0, 0)]

<comment><USER27> Python's date handling is meh. Some languages have dates as first class primitives and are a dream to work with.

</comment></comment></comment></comment><comment><USER28> I'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.

During my first tour with the company I built, among other things:

\- (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.)

\- (different two-person team) a mail-room management back-end that allowed us to print/mail over 1 million forms/year for customers of the above

\- (yet another two-person team) A corporate intranet product

Since returning to the company I've been on another small team (3 developers) building an independent payroll platform. As part of that effort, we've had to integrate with all the other things I ever built at the company. It'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 :)

<comment><USER29> They're lucky (or cursed) to have had the same person build so many different systems at the company.

<comment><USER28> Ha! Too true on both counts.

</comment></comment></comment><comment><USER30> It's been years since I'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've answered myself. Of course, working in the same space six months later, I'll have a problem, search for it, and land on the question on Stack Exchange that I've answered months earlier. It's happened a few times.

</comment><comment><USER31> I have a Notion database of code Snippets for this purpose.

Described this in a recent blog post: [https://tkainrad.dev/posts/managing-my- personal-knowledge-ba...](https://tkainrad.dev/posts/managing-my-personal- knowledge-base/#notion-snippet-database)

It'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,...

<comment><USER32> +1 for db of code snippets - things like:

cat ~/src/example-code/py/numpy-masked-array.py

save me tons of time for those hairy things that I had to eat an hour to figure out and then use infrequently

</comment></comment><comment><USER33> I keep a copy of some very old code, from 15ish years ago, and I've peeked into it a few times in recent years when facing similar problems to what I've solved there, only to be horrified by what a pile of garbage that was. So there's also a fun element in that - seeing how far I've come. It's a good laugh.

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'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've left it, and I can't recognize most of the code now, that's a really weird bittersweet feeling.

</comment><comment><USER4> I'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.

<comment><USER34> hear! hear!

<comment><USER35> For me it's the opposite, I'm truly proud of those times where the obvious recursive solution is avoided and I manage to solve it with a "while(..){}". I'd be like "LOOK I DIDN'T TOUCH THE STACK ONCE". I'm raised on microcontrollers though.

</comment></comment></comment><comment><USER36> 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.

My first question was, "Haven't the other developers ever touched it." 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'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.

<comment><USER37> Wow. You should be proud indeed. Turned out you maintained enough corner cases right there.

<comment><USER38> How big was it, and did you write it?

</comment></comment></comment><comment><USER39> One I like to go back to is the micro-kernel scheduler written in assembly I did for a grad school project: [https://github.com/mbcrawfo/avr- kernel/blob/master/kernel/co...](https://github.com/mbcrawfo/avr- kernel/blob/master/kernel/core/kernel_asm.s)

It seems so much more interesting than the web stuff I do today.

</comment><comment><USER40> I wouldn't call it admiration. Most of my code archeology is like "this code is a mess, what fool wrote that. git blame... oh, it was me"

</comment><comment><USER41> 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).

Much older code is generally neither smart neither beautiful though.

<comment><USER42> well, that's the path to coding enlightenment! hahaha, just keep climbing for a few years more

</comment></comment><comment><USER43> 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'm feeling down about my abilities, I look over this code and smile.

Often I look at my older code and recognize the stage of development as a coder that I was in. It's usually not cringe-worthy but it makes me pensive about how I would handle it now.

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't beautiful but it filled a need and could be understood well-enough to modify by another. It made me happy all day.

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 "yummmm" from my wife and daughter.

Keep a memory of the times when your code makes you smile. Those memories pull you through the down times.

<comment><USER44> I read this after making my own post that starts the same. This sums up my thinking too so elegantly. There are so many aspects to code and how it gets written that inform the output that each needs to be viewed in the context of that. Was it time critical? Was it part of a legacy migration? Was it a complex problem?

The quality of the code doesn't have to reflect the quality of the solution and we should celebrate the things we nail.

</comment></comment><comment><USER45> I don't feel proud of my code if it works but I do feel terrible about it if it doesn'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't sleep or think about anything else.

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'm idolizing it.

<comment><USER46> Sounds like a perfect case of perfectionism.

</comment></comment><comment><USER47> When I was ~15 I wrote this: $c=`clear`;for(`tail -c+324 $0|zcat`){if(/^p/){print@l;@l=()}elsif(/^d(.+)/){select$u,$u,$u,$1/10}elsif(/^s(.)/){$s=9;$e=-30;$m=-1;if('o'eq$1){$s=-30;$e=9;$m=1}for($i=$s;$i!=$e;$i+=$m){$j=0;for(@l){print substr($_,$i+$j++>0?($i+$j) __2:0,-1). "\n"}select$u,$u,$u,.1;print$c}}elsif(/^c/){print$c;@l=()}else{push@l,$_}}__END__

Which (with ~1.5KB of binary data appended, total under 2KB) creates this: [https://code.shishnet.org/videos/floating_point.mp4](https://code.shishnet.org/videos/floating_point.mp4)

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

<comment><USER11> That's really neat. I'm guessing this is Lemonade? [https://github.com/shish/lemonade](https://github.com/shish/lemonade)

(Also, leave a blank line before your code and indent each line of it by two spaces to make it formatted like code.)

<comment><USER47> It is indeed :) Looking at the code now, I see so many opportunities for "improvement" like making it run on OSX as well as Linux; but I think that might spoil the magic :P

</comment></comment></comment><comment><USER48> Sometimes-- but most of the time when I look at code I wrote and was proud of but 6months or a year later-- I'm like, what was I thinking- I would of done it differently now. I call it programmers remorse. Since we'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.

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 "Thanks Past Jon- This is Future Jon (to you) and noice forward thinking"

While in isolation due to gobal things... it'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.

</comment><comment><USER49> Just to continue the analogy about carpentry / 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/unmount from quick looking. And it would be even more difficult to figure out with a TV in the way.

10 years later, it's time for me to move out, and I'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).

I look from the floor up behind the back, and what do you know -- I'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.

I was marveling at my foresight for a self-satisfied minute (and thanking my past self).

</comment><comment><USER50> No, I mostly go back and surrender to not understanding why I wrote what I wrote. Yes, I am in awe. But because it's a like a third person wrote it.

Regardless of comments.

<comment><USER42> Haha. I'm always proud of myself when I look at code that I don't understand, and I see some comment clarifying it and making obvious the reason why it couldn't be simpler and why I did something the way I did it. And then I'm like: "hey, you can trust yourself"

When that doesn't happen, I just spend the time to understand it again and add the comments. It eventually gets better.

</comment></comment><comment><USER51> I often return to things with reluctance, assuming massive technical debt, only to be pleasantly surprised (sometimes I am pleasantly offended!). I'll usually attempt a "haut-syntactica" 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.

On an aside, someone here mentioned that python 2 isn't python 3, in that the code itself gets old quick. But I don't think that really comes into it. Unless you're spaghetti-plugging holes in clients, there's a lot of joy to be had in manipulating any language or system to a desired end, especially when it's hard won, and I would think too when you return and see yourself in the result.

</comment><comment><USER52> 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'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 "discovery" is what I use to guide me. If it's not there, I know there'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's not "I wrote that!" with pride but "I was used to bring that about!".

</comment><comment><USER53> > Are there analogous feelings in other creative pursuits you practice?

Not exactly a "creative pursuit" but often with legal work it takes _years_ 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.

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.

</comment><comment><USER54> There's one particular piece of code I'm especially proud of, coming from a side project. It's a non-trivial amount of code, and it's not the cleanest code, and it has bugs and missing functionality. However, as a library it hits the sweet spot of:

1\. Zero dependencies

2\. Lightweight abstraction

3\. API enforces correctness in usage

4\. API covers the problem space well enough that the API hasn't changed since a couple months after initial release (it's been 3-4 years)

5\. Library does something all of the individual pieces of software using it couldn't have done individually - not easily anyway.

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.

I wasn't the only person working on that specific problem. In fact IIRC my solution was the third "to market". 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.

It's not my most elegant code, but it solved a specific in-demand problem and did a clean job of it.

</comment><comment><USER55> 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.

</comment><comment><USER56> I wouldn't say admire. When I stumble upon code from many years ago I (somewhat painfully) realize I've lost a lot of the ingenuity I used in my early days. I read the code and find myself thinking "how the hell did I come up with that solution". I didn't care about finding the optimal algo/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 "new" frameworks.

</comment><comment><USER57> 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!

</comment><comment><USER58> Not entirely mine but beautiful nonetheless:

        @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

<comment><USER59> You should really use deque for the stack

<comment><USER60> Why?

<comment><USER61> 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...](https://docs.python.org/3.8/library/collections.html#collections.deque)

</comment></comment></comment></comment><comment><USER62> > 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.

</comment><comment><USER63> 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...](https://github.com/silasdb/mark-number- circles/blob/master/mark-number-circles.scm)

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

<comment><USER64> I made the script-fu to generate a color hex triplet before it was part of the color dialog box. It was the first time I write scheme as well. I still love scheme even though I never got to use it

</comment></comment><comment><USER65> 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'll have a glass of whisky and pull up the .h and .c files and smile.

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.

</comment><comment><USER44> 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.

</comment><comment><USER66> I find that some ideas gestate on the backburner "I wish I had time to implement feature X".

Then upon going into the code I realize the basic framework already exists to implement the feature.

One of the more pleasant experiences in our code base.

The negative experiences of "Did I write this?!?" tend to be driven by performance bottlenecks and profiling.

</comment><comment><USER67> 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](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](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.

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

<comment><USER69> Would you mind sharing it? I am really curious.

<comment><USER68> I can't share the code.

It is just a really dumb search for a random solution. (I don't want to get the same solution or solutions each time.) The domains (which are always pretty small) for the variables are randomly shuffled first, so the search can just iterate through the domains.

The problems mostly have a large number of solutions out of the total space, so finding a solution is fast.

The real beauty is then being able to write short declarative code, which is very easy to write, read and _modify_ (I'm not always sure in advance exactly what the constraints should be). None of which would be the case for the code which would construct a solution, even though it might run a little faster.

</comment></comment></comment><comment><USER70> 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/stops/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.

</comment><comment><USER71> Yes, absolutely.

More fulfilling for me however is not the code itself, but significant results. I have captured/framed a few graphs in my career that look like a "sudden jump" or a "sudden drop", which were caused by deploying a more elegant solution to a problem or pain point.

</comment><comment><USER72> 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't something I experience much anymore.

</comment><comment><USER73> 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'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.

</comment><comment><USER74> 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:

        <Expr> ::= <Reference> | <NumericLiteral> | <Expr> '+' <Expr> | ...
        <Reference> ::= <identifier> | <ArrayRef>
        <ArrayRef> ::= <identifier> '[' <Expr> ']'
        <Varname> ::= ... (The parser is parametric in the parser for <Varname>)

... without upsetting the F# typechecker.

</comment><comment><USER75> Yes, but only with a fairly small share of the code I've written in the past. Most of the code I've written is nowhere near as good as it could be; some of it is embarrassing.

By the way, for me this happens with all forms of creative/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'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.

</comment><comment><USER76> 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.

</comment><comment><USER77> One of my very first was Inna domain parking app, that it tried to "fertilize" 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.

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.

<comment><USER78> I do hope you stopped doing this. Parked domains have frustrated me so often!

</comment></comment><comment><USER79> 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.

</comment><comment><USER80> 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.

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 _that one row_ doesn'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.

Select techniques from different tanks are often handy.

</comment><comment><USER81> I have on one or two occasions come up with a pretty neat algorithm for some task that seemed really clever. Later I'd learn that I wasn'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, "Hey! I'm as smart as that programmer!" or at least, "Hey! I have been as smart as that programmer was when they came up with that algorithm! I'm not a complete idiot!"

</comment><comment><USER82> I'm opposite. Never ever I felt proud of my code, I always am critical of it and thinking in the back of my head "I know how to refactor it even better". It'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.

</comment><comment><USER83> I don'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'm a good writer, even when I think I'm just another hack.

<comment><USER15> If it captures you back then yes, your writing is so good that it doesn't get in the way, you don't even notice it. I am not a natural writer and have to always make an effort to make something sound the way I want to. Quite often I cringe at my old scribblings and that sometimes without a reason..

<comment><USER83> Oh I have plenty of those moments too!

</comment></comment></comment><comment><USER84> I'm 50 now, but when I see the code I was writing in my teens and twenties, I'm convinced I am nowhere near as clever anymore. Time to get back to my roots.

</comment><comment><USER85> 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.

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 "math-focused-lens" and then I start to find some small admiration.

</comment><comment> c-smile 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.

I believe there is a moment of maturity in any developer'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.

</comment><comment><USER86> There have been a few times that I've really admired code that I wrote ... it happened way more often building embedded systems where I was short on processor cycles and memory.

But I'll also comment on the opposite (which I attribute to continually trying to improve my craft). Often when I look at code I wrote >6 months ago, I find something that I'd do differently today. Sometimes it's downright distasteful!

</comment><comment><USER87> That's just how some people are. For what it's worth, I can'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!

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.

<comment><USER88> It depends on what you code. For me there must be three things for me to be proud of some codebase:

      1. I could use my creativity (it was not entirely defined problem which just needed to be translated to code).
      2. I have enough time to make it good, not rushed.
      3. Problem was a little over my current competence level, so I could learn something new.

If you only make CRUD forms day in/day out it's hard to be proud of what you do. Creating map display engine which is more performant than anything you have seen to date IS a thing to be proud of (I'm still proud of that one thing, but it's other firm's internal tool, so I can't show you). Unfortunately, for most developers being able to work on such things is very rare. I had maybe 5 such things over my 20 year career.

</comment></comment><comment><USER89> 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.

</comment><comment><USER90> Rarely !

But what regularly happens is that I stumble on my own comments and/or helper methods, which saves me a ton of time.

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've got so much of them that they compose quite powerfully ! And old comments are like gold nuggets when the time comes to debug.

</comment><comment><USER91> Yes. I wrote some Rust code about 3 years ago. I'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're constantly fighting the borrow checker, etc) it would be too discouraging.

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

</comment><comment><USER93> 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've done the same thing. Perhaps, it's because we're viewing an older thought process, and have sufficiently dissociated ourselves with it, so we're able to neutrally critique it.

</comment><comment><USER94> I revisit my generalized monoidal FizzBuzz implementation on occasion. It's hard not to given it's elegance and beauty. :) [https://gist.github.com/lgastako/d4fa392cbe85cbfae7dfa5e18c1...](https://gist.github.com/lgastako/d4fa392cbe85cbfae7dfa5e18c14a2a4)

</comment><comment><USER95> I remember writing this library [https://github.com/tuladhar/adns- ruby](https://github.com/tuladhar/adns-ruby) few years back. I sometimes go through the code to be in that moment again and be "man I wrote this". I cannot express that feeling, but it feels great.

</comment><comment><USER96> Yes. But if you can figure out what it does you're going to be really sad.

{ eval "package " . __PACKAGE__ . '::' . (0+$class) . "; use base qw(" . join(' ', map { ref($_) || $_ } @_) . ");" }

This might help:

my $package = bless $class, __PACKAGE__ . '::' . (0+$class);

Or this:

return Devel::Pointer::unsmash_hv(substr(ref $self, 2+length(__PACKAGE__))); }

</comment><comment><USER97> 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:

[https://github.com/semitrivial/ions](https://github.com/semitrivial/ions)

</comment><comment><USER98> 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.

</comment><comment><USER99> All the time.

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.

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.

</comment><comment><USER100> 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.

<comment><USER101> 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).

<comment><USER102> > It's 10Ks worth of C# that I could do in a few hundred in Python (and have > it perform better).

You could also re-write the same code in C#, and have it perform even better than the hypothetical Python version, while being around the same length.

</comment></comment></comment><comment><USER103> Maybe in the first 6 months or so after writing it.

After that, I occasionally go back through old code asking "what have you done for ME lately?" and an eye towards dragging it behind the toolshed and going "Ole Yeller" on it.

My code has to continually prove its worth to me, or else it's gone. Code is a liability.

</comment><comment><USER104> No. I really don't have that courage.

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

</comment><comment><USER106> I do sometimes go back and stare at this wonder I crafted once:

      s=>s[0]+/.*( .|z)|...s.s?|T..|M[i-t]+|[AFINOUW][^o]v?|.*/.exec(s)[0].slice(-1).toUpperCase()

It does something pretty useful, that has surely been written many times over. But unlikely ever as succinctly as this. :)

<comment><USER107> Alright, I'll bite - what does it do?

<comment><USER108> [https://codegolf.stackexchange.com/a/122957](https://codegolf.stackexchange.com/a/122957), perhaps?

</comment></comment></comment><comment><USER59> 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.

Otherwise code can always be made better.

</comment><comment><USER109> I wrote a GPS coordinate mapping tool for a fun project once. I wrote it on a train, and I didn'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.

</comment><comment><USER110> I've only been coding for a few years now.

Often I'm sort of irked by my old code.

But it is telling that from time to time I find some old simple code that was easier to read / change than I expected if only because I coded it so simply and in an iterative sort of way.

There's something to be said for being simple...

<comment><USER111> Going back and being annoyed with your old code means you've improved.

<comment><USER110> Well then I've improved A GREAT DEAL ARGH!

</comment></comment></comment><comment><USER112> 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.

Admiring an older piece of code that I've written more than last year? Rarely, unless it's just a small puzzle or self contained code.

</comment><comment><USER113> 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 "What was i thinking?"

</comment><comment><USER114> I 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.

</comment><comment><USER115> 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't uncommon among artists

Now at times when I have the space and time to code things the way I wanted, I step back and do the same :)

</comment><comment><USER116> I'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 "zone" to pull off, so it seems like magic to present-day me.

</comment><comment><USER117> If you don't occasionally go back to appreciate what you've built, you're probably not taking enough pride in your work.

If you don't occasionally go back and become horribly embarrassed at what you've done you're probably calcifying.

</comment><comment><USER118> It will pass :) And you're looking at the code right after you wrote it.

If you look at your own code months or years later (some applications do need maintenance), you'll hate it or be ashamed of it. But you should know better than improving it by then.

</comment><comment><USER119> Once or twice. I still remember a Perl routine I wrote probably 10 years ago. It'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.

</comment><comment><USER120> 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?

</comment><comment><USER121> 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.

</comment><comment><USER122> There is one instance which I wrote almost a year back. It's does nothing special, hasn't increased the company's revenue but it does one thing and does it best.

Right now the whole file is changed but that code is still intact.

</comment><comment><USER123> Less so with the code per se and more with some elegant or minimalist abstraction it implements.

So the best bits are probably the multipage comments that precede a handful of lines of code and explain what's going on :)

</comment><comment><USER124> I'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.

</comment><comment><USER125> 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's a breeze to maintain.

</comment><comment><USER126> 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.

</comment><comment><USER127> 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.

</comment><comment><USER128> 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.

</comment><comment><USER129> 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.

</comment><comment><USER130> You should always take pride in your own work regardless of what profession you're in. There's nothing wrong with that at all.

</comment><comment><USER46> Only if I go back to a language that I haven't used for a few years where I don't remember how the solutions are implemented.

</comment><comment><USER131> 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.

</comment><comment><USER132> I'm a fan of my recursion scheme examples :p

For the most part my standards get higher as time goes on though. So only small things!

<comment><USER15> Ive been toying with Racket and found myself admirig scheeme and recursion in general. It is so simple and yet so elegant.

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

</comment><comment><USER134> Yes. Sometimes I can't believe how smart I was back then and wondered what happened to me.

</comment><comment><USER135>
      amountFulfilled = isFulfilledOnSite * quantity

yes, isFulfilledOnSite is a boolean

</comment><comment><USER136> No - I'm hard on myself and so look back and always say "this is sh!t"

</comment><comment><USER137> 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.

</comment><comment><USER138> Kinda, except the opposite.

</comment><comment><USER139> Every bloody monday I admire the naivety of the code I wrote friday.

</comment><comment><USER140> Yes. But not as often as I cringe at something I wrote.

C'est la vie.

Live. Learn. Adapt. Move on.

</comment><comment><USER141> Yes, I also get surprised on how I implemented the solution.

</comment><comment><USER142> I'm usually like "Who wrote this shit?"

</comment><comment><USER143> I wrote an very concise recursive solution to one of our interview problems. Not really 'good' code because its hard to read and reason about, but I enjoy looking at it every 6-12 months.

</comment><comment><USER144> No, usually I never

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

</comment><comment><USER146> rarely. mostly i look back in horror.

</comment><comment><USER147> we call this code review

<comment><USER58> A code review consists of reading a piece of code written _recently_ by _someone else_ , which is not what is asked by OP.</comment></comment>


Stick to What You Know, a Tale of an Investment Gone Wrong - <AUTHOR> http://jacquesmattheij.com/stick-to-what-you-know-a-tale-of-an-investment-gone-wrong

<comment><USER2> Maybe, like jacquesm, it's my lack of experience in retail, but doesn't "money gone missing" show up on the books quite easily, especially after a quarter? You sold X, so you should have Y, except there's only Z (Z < Y). Or, if they didn't register the sales, then it should have shown up as theft?

<comment><AUTHOR> Especially when you're selling something like gasoline. When I worked in the gas business, they measured the tanks every single day and knew the amount of gas there to the millimeter.

Sounds like multiple people were complicit in this.</comment></comment>


Ask HN: Has anybody here ever used a completely split keyboard? - <AUTHOR>

Here is a sample of what I mean:
http://www.kinesis-ergo.com/freestyle.htm
So a keyboard that is completely split in to two portions, one for the left hand and one for the right hand.
If you did, what was your experience like? Is it worth it? <comment><USER2> I use the Contour from the same folks:

<http://www.kinesis-ergo.com/contoured.htm>

The two halfs are built into a single plastic block but there's still about 6 inches of separation between the two islands of keys. I love it, though there are other benefits, like two key clusters of 6 special keys (Enter, Backspace, Ctrl etc.) under each thumb area, amongst several other things. Double the price though.

From the images on the freestyle it would appear you still have to deal with both halves being linked by a cable, so it's probably not that great a difference from a normal ergo keyboard or the Maxim model they sell (unless you put it into the vertical mode). I'm sure I've seen setups with one half on each arm of a chair.

<comment><AUTHOR> > I'm sure I've seen setups with one half on each arm of a chair.

That was what I was going for. Thanks for the info!

<comment><USER2> Here's what I'd seen before. Looks like it was discontinued as a product even when I first saw it years ago.

[http://blog.jonudell.net/2009/03/14/the-floating-arms- keyboa...](http://blog.jonudell.net/2009/03/14/the-floating-arms-keyboard/)

<comment><AUTHOR> Funny quote from that article: "Some people are so devoted to their keyboard that they search for backups and worry about finding another copy of a discontinued version."

That could be about me, I spent a week tracking down a working SGI keyboard because I managed to mess up my 10+ years old one. I dread the day when I won't be able to buy mother boards without a keyboard connector.

It's weird how you can get attached to certaain hardware, screens I'm not so partial to but that keyboard is something else. Haven't found a replacement yet.

</comment></comment></comment></comment><comment><USER3> I use this keyboard: [http://goldtouch.com/p-64-goldtouch-adjustable-keyboard- blac...](http://goldtouch.com/p-64-goldtouch-adjustable-keyboard-black.aspx) (it's completely split, but the two halves are _firmly_ connected).

The #1 reason is that it has a minimal laptop style single column of keys to the left of BS \ ENTER etc., my biggest problem is moving my right arm from the keyboard to the mouse (all mouse alternatives I've tried are worse than a plain optical mouse).

If you tent it it's _rock_ solid, but I didn't find any advantage to that feature. I do really like the variable splitting ability; I've previously used a solid base keyboard with a fixed split (and some tenting) but being able to adjust all this so it's _just_ right is noticeably better.</comment>


A Physics Anomaly: Fountains of Chain - <AUTHOR> http://nytimes.com/video/science/100000002747620/fountains-of-chain.html

<comment><USER2> Read the paper here: [http://arxiv.org/abs/1401.5810](http://arxiv.org/abs/1401.5810)

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER3> I saw Steve Mould demonstrate this a few weeks ago as part of the Full Frontal Nerdity Tour [1]. It was superbly entertaining.

[1] [http://festivalofthespokennerd.com/](http://festivalofthespokennerd.com/)</comment>


The former CEO of Mozilla is launching a web browser that blocks all ads - <AUTHOR> http://www.businessinsider.com/former-mozilla-ceo-brendan-eich-launches-ad-blocking-web-browser-brave-2016-1?r=UK&IR=T <comment><USER2> Sounds like he wants ad agencies to pay him to allow adverts onto users device.</comment>


Wayland Is Almost There - <AUTHOR> https://bearbin.net/blog/wayland <comment><USER2> I try it each time a new version of ubuntu comes out and it works for a while but eventually I get freezes or crashes with my ten year old nvidia card. I switch back to X11 and its fine.</comment>


Show HN: An open source music grid you can play around and create short music - <AUTHOR> https://music-grid.surge.sh <comment><AUTHOR> Few days back, I was trying out an AntiStress app in play store which had many small widgets to play around. It had a similar music box which I loved. I wanted to make it configurable and longer, so I made one. The code might be messy since it's my first svelte project, PRs are always welcome :)

</comment><comment><USER2> Love it!</comment>


Will the company that kills Google be founded by Google employees? - <AUTHOR> http://www.pbs.org/cringely/pulpit/2007/pulpit_20070524_002134.html <comment><USER2> The conclusions of this article may not necessarily be wrong (everything gets killed eventully), but it pretty spectactularly misses the point of 20% time. The interesting part of 20% time is that it is not about what management thinks, but about how much momentum you can get on your idea yourself and with others you can attract and motivate. I don't work there, but from my understanding the idea is that mgmt can't reject an idea per se -- if you want to work on it that is your call.

</comment><comment><USER3> No, Google will be killed by people who it rejected to take.

</comment><comment><USER4> This article is pure speculation.

</comment><comment><USER5> Many famous empires were destroyed from inside.

<comment><USER6> Like what?

<comment><USER7> Like a couple of shots inside a thermal exhaust port.

</comment></comment></comment><comment><USER8> Bob seems to be right (as usual). The moral of his story: don't try to buy up 50,000 painters and keep them under one roof, that's just disastrous.</comment>


The Marriage of Figaro… and Rails 4.1 👰 - <AUTHOR> http://collectiveidea.com/blog/archives/2013/12/18/the-marriage-of-figaro-and-rails/

<comment><USER2> > Because knowledge of the secret_key_base allows an attacker to read and > manipulate an application's cookies, checking the value in was never a good > idea.

So FYI, "read and manipulate an applications cookies" is strictly the same as "run arbitrary ruby code in your Rails application process". I would upgrade "never a good idea" to "completely and catastrophically exposes your application to remote code execution" in this paragraph.

<comment><AUTHOR> Thanks! Updated.

</comment></comment><comment><USER3> Figaro was pretty cool last I checked. Though we've been using foreman [1] for setting the env variables in the .env file, since foreman also helps manage additional processes in development like mailcatcher, mongo, redis, elasticsearch, and any other dependent processes that your don't leave running all the time in your machine. And it has a command to export your env to Heroku or upstart. I don't remember how much of this Figaro does, just thought I'd throw foreman out there as another solution to keep in mind.

[1] [https://github.com/ddollar/foreman](https://github.com/ddollar/foreman)

</comment><comment><USER4> Is Figaro even usable without Heroku? From what I understand the commands it offers are tailor-made for Heroku, and the main problem mentioned (secrets.yml not being Heroku-friendly) seems like specifically a Heroku problem. IMO I'd use Figaro for Heroku, and YML files for a VPS.

<comment><AUTHOR> Figaro is certainly usable without Heroku. It added some Heroku conveniences later in life, but is built to simply populate ENV while keeping source control clean.

<comment><USER4> Good to know. I suppose for all cases where I'm deploying to non-Heroku servers I'd probably still use secrets.yml just because it's built into 4.1.

<comment><AUTHOR> Makes sense, now that it's the new convention. Thanks for the comment!

</comment></comment></comment></comment><comment><USER5> I've used Figaro for a few projects and I've found myself very happy with it. It does one thing well without adding unnecessary complexity or overhead to my app. I feel that figaro-like capability in Rails is a win for the community and for figaro/laserlemon as well.

<comment><AUTHOR> Thank you! And I completely agree that secrets.yml is a win.

</comment></comment><comment><USER6> haven't read the link yet, but i love that a wedding emoji was used in the title!

<comment><AUTHOR> I'm really surprised I don't see more Emoji in HN post titles!

</comment></comment><comment><USER7> is the secrets.yml file not checked in to source control ?

<comment><AUTHOR> No, it's not. The idea is that your should be able to (hypothetically) open source your app at any time without compromising any sensitive information.</comment></comment>


Show HN: "Donald Trump V/s Hillary Clinton" Better On-Site UX? - <AUTHOR> https://www.designernews.co/stories/68000-ask-dn-donald-trump-vs-hillary-clinton--which-has-got-better-onsite-user-experience <comment><AUTHOR> [Originally posted on Designer News]

Re-sharing it here for non-designernews audience. Hope this helps.</comment>


React Context API is not built for high-frequency updates - <AUTHOR> https://academind.com/learn/react/redux-vs-context-api/ <comment><AUTHOR> Curious what work-arounds people have found?

Currently looking into passing around an event emitter on context to get around this</comment>


Tuna are spawning in marine protected areas - <AUTHOR> https://news.mit.edu/2019/tuna-spawn-marine-protected-sanctuaries-0724 <comment><USER2> To show my kids a bit about programming we made a simple rabbits-and-foxes simulation. Little dots moving around a rectangle drawn on the screen. The red ones were rabbits, would move mostly randomly, and would periodically make a baby rabbit. The blue ones were foxes and would chase nearby rabbits. When they caught one they'd eat it and make a baby fox.

Fun to watch but we found no matter how we set the initial counts of rabbits and foxes, inevitably there'd be a population spike of rabbits, which would cause a lot of foxes to be born, which would eat enough rabbits (sometimes ALL of them) that the rest of the foxes would starve and go extinct.

We tweaked all kinds of parameters about how they move and how they reproduce and nothing kept the system from oscillating into a broken state.

Eventually we added a "rabbit preserve" \- an area rabbits could pass freely through but foxes couldn't enter. Just like that - the system was stable(ish). There would still be population peaks and valleys but as long as the preserve was reasonably large the rabbit population might crater but wouldn't crash.

Its a nice little project, easy to code and fun to watch

<comment><USER3> Add earthworms. ;- )

<comment><USER4> Is this a joke or reference, perhaps?

</comment></comment></comment><comment><USER5> So by not fishing at all in the protected 11% portion of their fishing area, they're projected to get more fish due to the spillover effect. Well, no surprises there.

We rarely ever do these economic projections.

They can apply to so many more areas, like the forests in Indonesia where they're discovering new antibiotic compounds in shrubs, or the spider habitats whose venom is used in producing heart medication, they're probably a lot more expensive than some lumber and cornfields.

I feel like if we communicated environmental protection more materialistically instead of emotionally, people would have an easier time convincing their politicians to actually enact it.

If we're gonna calculate 25-30 year mortgages for homes than we should probably do environmental risk projections too in dollar figures for those kinds of time frames.

<comment><USER6> One argument against this position is that economic environmentalism cuts both ways. Sure

Sure, marine preserves produce an economically beneficial surplus of salmon. Also, the oil reserves in the Arctic national wildlife refuge are worth more than 500 billion dollars.

In the case of Arctic drilling, I think the moral argument against destroying wilderness is the only viable option.

<comment><USER7> There is a strong economic argument for keeping oil in the ground now, though. Namely, that the planet will cease to support a functioning global economy under runaway warming.

<comment><USER8> That oil could theoretically be burned and the carbon sequestered. Hence no climate impact.

The hazard to fragile ecosystems from an industrial accident is still huge.

Edit: the point is that some environmental protection actions have to be driven by moral/ethical forces. We can't leave everything to the economy.

Having said this there might be ways to use market forces to implement the ethically required environmental protections.

<comment><USER5> Well, if they can afford to pay market-rate insurance on the liability of their sequestration method then yeah sure.

<comment><USER9> Interesting thought. I know nuclear plants are required by law to set aside a part of revenue for eventual long term storage of the waste. You could have that for coal plants.

Of course we already have quotas and trade which is designed for something similar.

And the offsets have their problems...

</comment></comment></comment></comment></comment></comment><comment><USER10> > The researchers observed multiple species of tuna larvae throughout this > protected expanse

Somehow I've gone over 40 years without realizing that fish have a larval stage.

<comment><USER11> I'm in the same boat, I assume like me you were thinking of larvae and maggots as being synonymous, but it looks like with fish the larval stage is more tadpole like: [https://en.wikipedia.org/wiki/Ichthyoplankton](https://en.wikipedia.org/wiki/Ichthyoplankton)

<comment><USER10> I knew of tadpoles, and I knew fish eggs, but somehow I guess I just imagined fish hatching as tiny fish.

</comment></comment></comment><comment><USER12> This is the original article. It's open access!

I'm surprised MIT's press release doesn't link to it.

[https://doi.org/10.1038/s41598-019-47161-0](https://doi.org/10.1038/s41598-019-47161-0)</comment>


How SEO Killed Online Reviews - <AUTHOR> http://inbound.org/seo/2012/06/how-seo-killed-online-reviews/#respond

<comment><USER2> Link is to some other aggregation site, with no comments as yet.

Actual article is at [http://www.koozai.com/blog/search-marketing/how-seo- killed-o...](http://www.koozai.com/blog/search-marketing/how-seo-killed- online-reviews/)

</comment><comment><USER3> Flagged as this violates HN guidelines: "Please submit the original source."</comment>


The trajectory of a software engineer… and where it all goes wrong. - <AUTHOR> http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/

<comment><USER2> Trying to make ... geographic/domain scope a thing here is a huge problem. At some point, you either spend your precious seconds on your brand ( which makes your scope larger ) or you spend it on solving problems. Serious problems are proprietary, secret or ( even worse ) security-clearance secret.

It smacks of "social media thinking". I do not think the mores and practices of social media apply to much beyond social media. Social media looks like narcissism to me.

I am pretty much a full-fledged multiplier but I rather doubt that makes me the top 2%. It just means that I stayed focused on technology ( over a span of 30 years ) while my contemporaries didn't. They chose the "up and out" path. At least one is trying to get back in.

I can turn "lower performers" into higher performers by talking to them. I've done it. That's just me being a human who likes people and needs their stuff to work too. And I've certainly had other engineers help _me_ out in that way. You get stuck; talking helps your brain to find solutions.

Why do we need this method anyway? Peoples is what they is. Why do we stack people into boxes like this?

</comment><comment><USER3> >Why are so many programming jobs (and libraries) in brain-dead languages (such as Java) rather than functional-programming languages (e.g. Scala, Ocaml, Clojure, Haskell)? Because while the Java+IDE environment makes it extremely difficult for an individual engineer to have a 1.5+ impact –there are two cases in recorded history of programmers breaking 2.0 in Java; one is Martin Odersky, who wrote Scala, and the other is Rich Hickey, who wrote Clojure– the state of the tooling makes it possible for the 0.7′s and 0.9′s to get a 0.1- to 0.3-point bump, so long as they stay within their IDEs and don't have to work with a computer (gasp!) at the (God, no!) command line.

I don't see how anyone with practical experience developing commercial software could write something like this. The tool set simply isn't that important. Plus, the idea Java programmers are afraid of the command line is... well, interesting at best.

<comment><USER4> >I don't see how anyone with practical experience developing commercial software could write something like this.

Exactly. Using IntelliJ "holds me back", but if I bust out vim, somehow my _code_ will miraculously get better. Sigh.

What I type, or not type, holds me back. Not the editor. That's just a means to an end.

</comment></comment><comment><USER5> The scale seems ok... and the team mate classification. but otherwise the author is full of it.</comment>


Why Angular 2 Switched to TypeScript - <AUTHOR> https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8#.xkfxa7yag <comment><USER2> I've been programming for a long time and TypeScript has been a slam dunk for me. It makes programming large web apps actually considerably more manageable.

Unfortunately I spend a lot of time defending the merits of static typing to my co-workers. At the same time they're going on about how unit tests are important, while static typing eliminates entire classes of errors and they don't get it for some reason. Unit tests while important don't prevent type errors, and if you tried using them for that you'd have orders of magnitude more tests to write.

I feel like I'm taking crazy pills having to defend static typing while every dynamic language I've used for any project of any considerable size has been a complete nightmare to manage. At this point I feel like a lot of new coders coming out of school just haven't written anything large enough yet and maybe that's why they don't see the point.

<comment><USER3> Don't worry, it's all coming to an end. All the trending languages either are statically typed ( go, swift, rust), or provide some kind of type hinting (elixir) to make up for it.

Unit testing is great, but it doesn't provide autocompletion, or help you analyze your codebase before a refactoring.

</comment></comment><comment><USER4> I wanted to use TypeScript with a new React project, but the biggest problem I had (which eventually lead me away from using it) was that typings were so hard to get ahold of. Built something in JS? Sorry, you have to provide what is essentially a source map in order to get it to work with TypeScript. That should be a non-starter for anyone who is doing more than a hello world app. Figure out a way for me to use TS without having to create a bunch of extra type garbage in my app and I'll upgrade my code base immediately.

<comment><USER5> I was under the impression that typescript is a superset of javascript. Is that not the case?

<comment><USER6> The title of one of the article sections is literally "TypeScript is a Superset of JavaScript" ...people do still read before commenting, right?

<comment><USER5> Just wondering why you can't use React directly if that is the case

<comment><USER4> In order for TypeScript to understand the types it is interfacing with (especially in the case of libraries) there has to be a type definition created for each library. Dismissing my complaint because "TypeScript is a superset of JavaScript" shows a lack of understanding regarding how the system works.

</comment></comment></comment></comment></comment><comment><USER7> Question for TypeScript and specifically Angular 2: does Angular 2 being written in TypeScript mean that webapps based on Angular 2 that are also written in TypeScript, are basically 100% type-safe (e.g. all app-to-Angular library calls, or within-app view-to-model/etc. calls, are all type checked)?

I ask because after looking (admittedly very briefly) at writing an Ember app in TypeScript, it looked like because Ember assumes all of it's webapps will be JavaScript, there ends up being a lot of dynamic-/string-based idioms, e.g. model.set("property").

(There is a good SO post about turning this into a typed model.property.set(...) in TypeScript, but that solves just this one instance, and not the entire Ember experience.)

So, this left me with the feeling that for a TypeScript webapp to have a truly great/first-class/typed interaction with it's framework (Angular, Ember, whatever), that the framework itself would have to: a) be written in TypeScript, and b) have the founding assumption that most (all?) apps written for it would also be TypeScript.

So, per this post, Angular 2 is a), it's written in TypeScript. What about b)?

<comment><USER8> Nothing in Javascript can ever be completely type safe right now. For example, you compile your TS code and it compiles without error, but you pull a JSON object from the server and pass it into a function which is expecting the argument to implement a certain interface. The problem is the interface is dropped in compilation and there's no type checking at run-time, so there's no way for Typescript to know that the program will be type safe at run-time.

<comment><USER9> Not sure about TS, but a good type system would not mean you know the structure of dynamic JSON. It would just guarantee that before accessing some field, you would define in some way your code path what to do in case there is that field and in case there isn't. So, at the end, even if you missed the structure, you would have a clearly-defined error reporting logic (or whatever is necessary) at your runtime.

</comment></comment></comment><comment><AUTHOR> If you're looking for Typescript type definitions for a project you're using check this list - [https://github.com/DefinitelyTyped/DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)

<comment><USER10> Good list, but are they going alphabetically and only made it to 'k'? ;-)

Edit: Thanks, I had a feeling there was a bug... it was just strange to see files from the top-level folder appear afterward, made it less obvious.

<comment><USER11> You can install typings (npm install -g typings) and then search for type definitions. For hapijs, it would be `typings search hapi`. Then you can install using `typings install dt~hapi --global --save`.

</comment></comment></comment><comment><USER12>
        There are a lot of options available to frontend devs
        today: ES5, ES6 (Babel), TypeScript, Dart, PureScript,
        Elm, etc.. So why TypeScript?'

...

        Elm and PureScript are elegant languages with powerful
        type systems that can prove a lot more about your program
        than TypeScript can...

ouch. Thats got to be a tiny bit awkward for the Dart team to read (so, I guess Dart isnt in the list of elegant languages then?)

<comment><USER13> Dart isn't even in the same progamming paradigm as Elm and Purescript, so I don't think it was meant as a slight towards the Dart team.

And really, Dart is more like Java, it's nowhere near the elegance of the ML/Haskell pedigree of Elm and Purescript

<comment><USER14> I think it should already be a pain point that internal Google teams decide to use languages designed by the competition instead of their own.

</comment></comment></comment><comment><USER15> It continues to be amazing to me that a new generation of developers is discovering that, yes, static checking adds a lot of value (for non-trivial- sized projects). Of course, if you were tasked with delivering web apps -- until recently -- you didn't really have any choice.

The older I get, the more the whole "everything moves in cycles" thing appears to be true -- almost regardless of what particular subject matter is under consideration.

<comment><USER16> Where is the evidence that static typing results in a net benefit? There's some evidence that points in the opposite direction:

[http://games.greggman.com/game/dynamic-typing-static- typing/](http://games.greggman.com/game/dynamic-typing-static-typing/)

When a language imposes static types, it also imposes a development cost, possibly negating all the value it brings.

Typescript is a little in the middle in that static typing is optional, but then you also don't reap the supposed benefits wherever you don't use it. Any "tool-based" refactoring is now _less_ reliable than a simple text search.

As for catching type errors, those are usually caught very early. If they aren't, that points to a lack of test coverage.

As for the "documenting" aspect: The article claims that by static typing, the documentation need not be consulted, which is rather irresponsible. If you use a function, you had better read the documentation. I know that's a bit much to ask from actual developers, but it's true.

<comment><USER17> > it also imposes a development cost,

Very very small cost.

<comment><USER18> > _Very very small cost._

I've gone back and forth a few times in my career (currently preferring dynamic languages) and would say that the cost is considerable, even with type inference. The trouble is, we don't notice the costs of approaches we're habituated to or prefer, so it feels like they're much smaller than they are. And we don't account for the costs we don't notice, so our cost/benefit analyses (on both sides of the question) are skewed. We all unconsciously put a finger on the scale.

This doesn't stop everyone from making grand, confident claims about static vs. dynamic typing. Such studies as there are don't support these claims, but the studies are weak in so many ways that it's easy to dismiss the ones you don't like and stick to your previous opinion, so that's what we all do.

For these reasons, the debate is pure tribalism and cargo cult. We should stop pretending that our views have any objective support and just talk about them in terms of taste. That's unsatisfying to the technical mind, though, so none of us will!

<comment><USER19> What is the cost? I mean, you are already working through the types in your head when writing code in a dynamically typed language. It's not like you get to just forget what type things are when you program.

<comment><USER18> Here's one of many examples: when you're defining types you have to think of names for them. That's a high-energy mental operation.

<comment><USER19> Interesting. Can you give me some more examples?

<comment><USER18> Another is that you get a slower interactive development cycle because you have more things to do before your code can run.

For example, some portion of your program may be half-baked because you haven't worked out its types yet, or maybe you've changed a type but haven't yet updated the rest of the program. If you want to play with your program interactively to find something out about the work in progress, now you can't, because your program isn't currently 'correct', i.e. it isn't self-consistent.

This adds drag to the development process. First, you have more work to do. Second, it breaks flow: you must switch your attention to something extraneous, breaking your concentration on what you were doing. Third, it gets you in the habit of satisfying the machine rather than thinking about the problem you're trying to solve.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> So far I'm really into typescript (for dev). However i one big problem which is C.I. It's annoying to have to configure an environment just to run a TS compile job.

<comment><USER15> I don't understand what you mean by "have to configure an environment just to run a TS compile job". Didn't you already have some sort of automated CI testing running on all your JS code?

<comment><USER20> Really I just didn't want to have to install node in the build step because it was already complex.

<comment><USER10> Whether it's TS or some other form of minification or listing, I find node on a build server is unavoidable these days. I just wish it used fewer resources during npm installs...</comment></comment></comment></comment>