Wonderful! I love the "crack" progress bar running through the directory tree. bpytop[0] in cool-retro-term[1] looks quite similar while being genuinely useful.
Guilty! I even wrote my own web-based hacking simulator game because of the influence Uplink had on me. A couple years ago I started working on a new web-based UI[0], the start menu icon at the bottom left surely will feel familiar :)
Another set of hacker games, Hacker Evolution, Hacker Evolution Untold, Hacker Evolution Duality released their source code[0] along with the games on steam for around $10
When I lived in [redacted] a few years ago I realised I lived not far from the Introversion offices and by chance met up with them a few times which was pretty cool. Still got my v1.0 CD of Uplink with the bonus mini-CD in storage :)
If you just randomly press keys (keyboard face roll) it will still type out the code. Sometimes I feel like this is how other people actually write their code.
When I encounter some of my own past work when I thought I was being "clever", sometimes that's how I feel about my own past work. It's a always a reminder to me that I should avoid trying to be too clever.
I used to read and believe this. After all, clarity is important.
Since then I’ve realized that our brains are like lenses; learning to code re-wires your brain to read code, which is different than other types of data, similar to the way that reading a book is a different interface than examining a room; just as we may choose to read certain authors or subjects, or may not think of the same things when examining a room, we may choose to see code in styles or certain languages, or may consider value in clarity of code or in its function.
I value clarity, but upon considering the room again, the first dimension is function, next clarity. This doesn’t subdue clarity to a trivial role, but clarity is a third order to maintainability, which is second order to executability.
Over time, those lenses may not be as agile as before, though we expect them to be. Text is blurred, and we may struggle to hold the glasses at a distance to read a certain part of the code clearly. It no longer makes sense, and that which employs us sees other value.
Yes. We have this notion that code should be understandable to a junior dev with no context and only 90 seconds to understand what the function does. But for a complex system, it would take a lot longer to communicate what's going on in such simple terms, and you would wind up being much more verbose and/or repeating yourself everywhere, which then becomes an impediment to a fluent dev who has been working with the system for months and already has the context.
You need that higher-level clarity in code so that you can still work with abstractions and not have to dive into every function at a code-level, but when working inside a function or a deeply technical area, it's reasonable to expect a developer to spend some time reading the code and coming up with a mental execution model, which is purest when it comes directly from the code in the form that works, and makes sense to the people who actively need to maintain it.
Function is compromised in a code base that must be maintained by multiple people over the course of years when if it is not written with both function and clarity in mind. I have never myself encountered a task where I have had to compromise functionality for clarity, or clarity for functionality.
