456 karma · joined June 18, 2019
Anyway, maybe all obvious observations but thank you nonetheless
Then there was that one time I was self-studying computer architecture (Computer Systems: A Programmer's Perspective) and was able to turn what I learned around and hack our binary code at a customer site because I wasn't in an environment where I could compile our code... and then years later, when I wanted to analyze the ROM of a 90s electronic device with a much simpler instruction set than x86, I wasn't afraid to crack open the thing in Ghidra
Let's see, what else have I read that's paid dividends over the years:
- Modern Operating Systems (Tannenbaum)
- Learning Python (Lutz)
- JavaScript - The Definitive Guide (Flanagan)
- Programming PHP (Tatroe)
- Learning Web Design (Robbins)
- Algorithms (Sedgewick)
- A book I read whose name escapes me now, about technologies like RS-282/RS-484 and serial communications in general
- (I could probably put down Cuckoo's Egg too as an "inspiration" for me ultimately getting interested in computers and networking, and I bet that's not too uncommon a story)
It's probably a sign of my age (mid 30s for reference), but when I'm curious about something and want to learn it really deeply - I look for a good book on the topic. (although I'm willing to admit that maybe this process hinders me in some ways, because it means I sometimes spend more time studying than I actually do working with a thing - I have spent a LOT more time reading about circuits than building them - but I like studying so I'm happy either way)
The dial-up sound just evokes that early Internet feel so perfectly...
(minor use case I had recently was I was trying to find old Japanese blogs for Tamagotchis, which I gather there were a ton of in the 90s but almost none survive today - imagine if I could get those instead of the 1,000,000 sites just trying to sell them to me)
I've always been a computer guy... I'm bad with my hands. Could never do origami. Part of the reason I dropped out of Boy Scouts was I didn't want to learn how to make knots. I was terrible in art class, I can't draw and I honestly have trouble just visualizing things (I was not great in geometry either). It's difficult for me to be creative like that. So that's my background, lol.
I could play music (and that's a hobby I still want to pursue), but lately I've been wondering if there was a craft that was better for people like me. Like, I got these cute handmade plushies as a gift recently, and I want to do something like that.
(honestly it seems like crocheting and knitting might not be bad options, but just wondering what else is out there!)
e; one thing I've considered is making something with electronics (I know enough about circuits to be dangerous), but the thing you run into quickly is you don't really want to just give somebody a circuit board, lol. At some point, it seems like all the interesting projects move towards 3D printing which I find intimidating.
Never had to do that since, but it sure saved my ass back then...
Carbon was officially removed with 10.15 Catalina in 2019 - what's the statute of limitations on reusing a name like this?
Auxiliary problems are something that always screwed me in college, when we were doing Baby Rudin, if a proof required a lemma or something first I usually couldn't figure out the lemma. Or in general, if I didn't quickly find the 'insight' needed to prove something, I often got frustrated and gave up.
This material seems like it would be good to actually teach in school, just like a general 'how to think and approach mathematical problems'. Feels kinda weird that I had to seek out the material as an adult...
One other thing I got out of the Polya books, was I realized how little I remember about geometry. So many of their examples are geometrical and that made them harder for me to grok. That's something I wish I could revisit.
(don't have any examples on-hand atm, this is just my general perception after years of occasionally looking things up there)
The early experience with the command line in turn made me much better at using it when I started working - new people at my company often struggle with the basics and take much longer to get comfortable with it than I did (the vim learning curve is steep indeed...). Now I prefer doing all my day-to-day computer stuff in the command line.
A more tenuous connection, but it's possible Cuckoo's Egg seeded in me the drive to spend unreasonable amounts of time tracking down root causes of issues and figuring out how things work. But that didn't really manifest until I started working.
Systems, software, and testing all worked in close concert so that software developers could find problems or gaps in requirements, as could testers. And of course there was a strong feedback loop between software & test. Meetings were weekly and people reached out to each other as needed outside of that. A daily standup was usually a sign that something was wrong.
In recent years we've moved to cargo-cult capital-A Agile, so we've basically traded our flexible process for a LOT more meeting overhead and pretty much a negative gain in efficiency. We spend significant portions of meetings talking about process which was never a problem in the past.
All because we didn't fit some predefined one-size-fits-all framework... sad!
(and of course the REALLY dumb thing, is that we're still often tied to a delivery schedule of 1 or 2 builds a year, with customer selloff testing - so the external process we fit into is still 'waterfall-y')
e; I guess one thing I neglected to mention here is schedule. We usually never had issues with schedule, our timelines were generous enough that even if we underestimated the complexity of something we could still make the delivery date. (admittedly there would sometimes be crunch periods in the last few weeks before delivery)
(alright, it has happened though that they needed to wheel out the old-timer who was around when the hardware was originally delivered, come integration time - since the way you hook up to the thing isn't always clearly described. But the software was fine!)
Years ago I bought the 3-volume set "Mathematical Thought from Ancient to Modern Times", but never had the time to get past the first few chapters. I'd be interested in any recommendations for math history tomes like that.
I gave up eventually because I got stuck on a certain station, and whenever I tried to leave I was immediately killed by a swarm of stronger ships. But it was still a cool experience.
Actually that book is also what helped demystify async programming for me.
IIRC Jason Scott's BBS documentary mentions this a bit. There's a couple that shows up a number of times that met on a BBS.
My current machine is also not on the latest so I wonder if an attempt to brew update would nag me now...
As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all.
I've also seen instances where tests are written too early, using a data structure that gets changed in development, and then causes churn in the unit tests since now they have to be fixed too.
I've generally come to think that unit tests should be used to baseline something after it ships, but aren't that useful before that point (and could even be a waste of time if they take a long time to write). I don't think I'll ever be able to convince anybody at my company about this though lol