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 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 used a chemex + quality grinder for a long time and haven’t found anything better so not much to add there.
I’ve started experimenting with roasting at home, though, and am surprised at how easy it is. Time since roast seems to be one of the most important variables for taste and beans are by far the largest expense. You can buy a 3lb bag of unroasted green coffee on Amazon for $20:
It takes about 13 minutes to roast a hopper’s worth of beans. I use a normal castiron skillet over medium heat. Just keep the beans moving the whole time.
I've just started dabbling on a small project and would be interested to understand how features overlap and differences in license/distribution model.
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.
I'm looking into why those are showing up in the issues list. Likely a bug. The user has been marked as spammy for over a month, though, which means notifications (email or web) are not delivered.
Your commits will count for the day they were committed once they're merged to master. i.e., It's the date on the commit that matters, not the date it's eventually pushed to master. A little weird since it means past days can fill in later but we wanted to make sure they were counted.
These buttons are only displayed for users who have installed those tools. We're not using it as advertisement, we're making it convenient for people who have already installed the tool.
We actually don't care about rate limits with this type of raw request. The limits are in place because people (usually porn sites) hot link js/css/image assets which can lead quickly to an insane number of requests.
If file extensions could be used to determine whether a resource could be used like this, we'd only apply the rate limits to those. Browsers don't care about extensions or event content types though. They'll happily use whatever's at the other end of a URL for <link rel=stylesheet>, <script>, and <img> tags.
As for whitelisting, it's a path we just don't want to go down for raw requests. We do a lot of that for the API and it isn't cheap to maintain.
I couldn't agree more. There are also many practical issues that I rarely see touched on in these yay SOA articles, like:
Scaling down for development. If you need to start N separate services and work in three projects to get work done, things get tedious fast. Also diffs start to cross projects if you split things too granularly.
Monitoring and management in production. Every process is a liability and requires work to monitor and manage. A single set of homogenous processes is much easier to deal with than many sets of different types of processes.
There's a line where you can be too monolithic. There's also many cases where breaking out services is necessary for isolation and distribution - actual architectural properties that are useful. But I don't get this tendency to break things down for the sake of breaking them down. It seems to come from a very high level architectural view of the problem domain with little concern for practical issues in developing, deploying, monitoring, and managing systems over time.
No. There's simple conventions for adding feature flags (user.some_feature_enabled?). Features are enabled and disabled by changing the code and deploying. This works because deploying new code is fast.
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.