74ls00 · HackerTrans

2 years agodiscuss

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.

74ls00

4 years agodiscuss

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.

74ls00

4 years agodiscuss

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.

74ls00

4 years agodiscuss

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.

74ls00

4 years agodiscuss

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

74ls00

4 years agodiscuss

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

74ls00

4 years agodiscuss

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.

74ls00

4 years agodiscuss

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.

74ls00

4 years agodiscuss

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

74ls00

4 years agodiscuss

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

74ls00

5 years agodiscuss

I find this debate interesting, but I can see this argument being used by both sides. Is your point that you don’t foresee external issues by buying like the supplier going under/the product becoming unmaintained or that you don’t foresee internal issues by building like some critical security oversight?

74ls00

5 years agodiscuss

Neither. All you get is in effect a certificate that says you “own” it. Nothing more, nothing less.

comments