rtomayko

Interesting to see this as I’ve never heard returning to adolescent interests being common but that’s exactly the path I followed after leaving tech. I tried getting into sound engineering because I loved recording with rented 4 track recorders and early software DAWs in my late teen years. It didn’t stick and I ended up going back further to when I found an old Honda Trail 70 in a barn when I was a kid and rode around absolutely everywhere in my local area just to explore.

I recently found the adventure riding community and built up a Husky 701 for multi-day (hopefully multi-week in the future) on/off road trips. It’s not unlike a small open source project but more physically active. I’m early 40s now and plan to explore on a bike into my 60s.

I also recently bought a ranch in Colorado. This isn’t from my childhood but turned out to hit all the right notes for me. Ranchin’ is almost impossible to make a profit at but I’ve met a bunch of people now who can’t stop doing it and I understand why. It’s a never ending stream of natural projects, big and small, that engage every part of you mentally and physically. Again here, not unlike a (larger) software project.

I went into tech because I thought I liked hacking, turns out I just like work, especially on systems you can iterate on every day and see improvement.

As for tech, I haven’t written a line of code in years and rarely use the internet except for practical things like maps and basic information. I still browse HN occasionally. Not sure why as there’s not a lot of content relevant to my current interests. It still has a little of whatever I loved about tech in the 2000-2015 era, which seems entirely gone from the wider internet now.

I made the jump to a System76 Adder WS laptop and pop!os for development after buying the lemon first gen MBP with the terrible keyboard. It was my seventh and possibly last MBP (including powerbooks before it).

I was considering one of the new 13” MBPs but that seems unlikely if injecting network latency into syscalls is the direction things are going.

If you’re not building Mac/iOS apps, find a Linux laptop you can tolerate for development and an iPad Pro for everything else.

I’ve seen this referred to as “satisfying your inner Linnaeus“ and have spent way too much time in that weird place myself.

I’ve been thinking about bike vs scooter a lot lately too. Austin is overrun with scooters and I used them for a little while before finding the electric Uber Jump bikes. They seem superior to scooters in every way in Austin, which makes the 20:1 ratio of scooters to bikes a bit baffling.

But I can see your point in SF where I use to walk 5 blocks from my apartment to the muni train and then another five blocks from the train to the office. Scooters would have been ideal there.

The e-bikes have one massive advantage in Austin - you can take them on the Butler Trail that runs the width of the Austin along the river. You can get almost anywhere of interest very quickly on one of the jump bikes.

There’s also no useful bus or train transport in Austin (I thought SF was bad) so you’re not using the small transport to move small distances between larger transport as often.

I've always loved this idea.

Fun fact: a blame-based suggested reviewers UI was included in the original Pull Request design mockups. We shipped with a much weaker list of everyone with write access list and eventually dropped the list altogether due to it not being very useful. I've always wished we would have revisited the blame based approach instead. A seemingly small feature that could dramatically improve communication and reduce noise.

I'm as keen to see memory safe systems languages become commonplace as anyone but some 90% of our stack is C - Linux, MySQL, Git, MRI, nginx, haproxy, memcached, redis, and many other internal components that we'll be talking about on the engineering blog soon. We like C. We're going to need a few more years of research, real production experience, and language/library maturity before betting critical infrastructure on something else by default.

"Unfortunately, your request for a 5% raise was rejected. We're sorry to see you go. Can you help hire a replacement? Just write up a quick job posting w/ your basic work experience and daily routine. Thanks."

We thought the Downloads feature was doing more harm than good in its previous form. Quality-wise it just wasn't up to snuff (failed frequently, flash, lack of design). Bad experiences on the site need to be fixed or killed. No one was willing to dedicate time to fixing it because they felt their time was better spent on other things so that left killing it.

The timing of the Releases feature only entered into the decision a little bit. It's hard to tell when something is going to ship at GitHub because there's no deadlines. Projects are done when they're done. The downside to this approach is that you can't rely on ship dates when making decisions like when to kill a feature something might replace.

We don't talk about unshipped features as a rule. It's hard to do so in a way that doesn't imply promises or timeframes.

Ouch. Sorry about that. Opening an issue now.