I’m sorry but this comment just highlights how mind bogglingly bad we in tech are at documentation and knowledge transfer. The very idea that a single project can only survive as long as the same individuals are working on it is insane. For hundreds of years architectural projects have outlasted the original architect. Or just look at civil engineering: transportation networks, utility infrastructure, etc. The idea that every project must bring on a high schooler to maximise the longevity of a project before we have to start over is ludicrous. Our tech stack needs to prioritise stability, we need to learn how to document from our friends in other disciplines, our funding models need to expect smaller returns over much longer timescales, and we need a culture of celebrating those who do the tireless job of maintenance.

NASA, probably more than any private organization has reams of documentation. Every bolt is documented. Maybe, just maybe, electronic systems are more complicated than bridges and buildings that literally just sit there.

I do agree that we need to do a better job of celebrating the people that do maintenance which is what the vast majority of our field is based on.

I agree. Sometimes I'm prototyping something or feeling my way down one possible implementation -- it's a lot more efficient to go deep in one area of the codebase and come back to fix up everywhere else later once I'm sure this is the right trajectory. In my day job, I use Flow.js which gives me this and I'm a little hesitant to give that up, given there's no many static type checkers that work this way.

Lots of mine (like git and vim) have already been mentioned, so here's some different ones

The Elm compiler, for giving me a welcoming on-ramp into functional programming. It's not the best nor my favourite, but its by far the most beginner friendly and is worth all developers learning for how it changes the way you think.

ed, whichever implementation you chose. And that's precisely what I'm thankful for. It showed me (via Michael W Lucas's book) that a software program can be fully specified, that you can have the entire spec in your head, and that you can just pick up any compliant implementation. So very refreshing.

What are you talking about? Of course they do! Try performing any of the operations listed in this article, or making a reply to this comment, by only twiddling the state of the transistors in your CPU.

Several years ago, to learn about machine learning, I wrote an algorithm that learnt what the best links in a Wikipedia article are to click in order to find the shortest route between two random articles. The answer was pretty much what you’d expect: top of the article, see also section at the bottom, first paragraph of each section, and then the rest of the article

It's only tangentially related, but I just wanted to say that being able to programmatically hack around with the minecraft world via python on the raspberry pi is what first made programming fun for me. I distinctly remember building a binary clock; actually writing code to achieve something I wanted rather than some arbitrary class exercise

I've recently taken up basketry for much the same reasons, but it has the added bonus that you don't really need any special equipment and the cost of materials is pretty low. Just so satisfying holding a thing in your hand that software just doesn't have.

I believe that my current work has a positive social impact. I work for ResearchSpace (https://www.researchspace.com/) where we make software for bio-med research labs. Its no change-the-world kind of endeavour, but is is simple, honest work. We're almost always looking to grow the team, for anyone interested.

Used to be the same in the UK (was my first language), but now they've revamped computing education up and down the country I'd be very surprised if it's still used anywhere

Yes, going back and understanding why something broke/has changed is incredibly valuable. Often it's not because of one singular decision but a collection of decisions over time that resulted in some behavioural regression. Being able to easily hop through all the commits of the recent past is incredibly valuable for me to understand how we can prevent such errors in the future, not just patch over the current one and move on. Fixing things without considering how we got here I tend to find leads to messy code; extra checks and assertions that aren't necessary if one takes the time to update the underlying assumption or modules that end up too tightly coupled because an extra bit of logic is added to fix that one bug.

Obviously it's possible to go too far; not every commit needs an attached essay. Many of my commits are just "fixed typo" or "added unit test for X", but then sometimes I'll write a short paragraphs or two explaining my rationale, referencing the commits that came before