5 ms·

> The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed wit

by lsc 10y ago

> The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance. This is actually one of my biggest career problems. I mean, it's an advantage, too... I can pretty quickly understand new things, because they are similar to old things, but... on an emotional level part of me rebels from the new cool thing simply because the old thing worked, often more reliably, and this new thing? this new thing has a bunch of little subtle differences and bugs that I have to learn and deal with and fix, just like the old thing had a decade ago, so my natural reaction to the latest fad is usually a negative emotional response, and pointing out that it's essentially the same thing as the old thing. This causes obvious problems, of course, with the people who got promoted for "demonstrating complexity" when they wrote or implemented the new system. I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!) >They aren't interested in the cloud because it's modern day mainframes for instance. This is the opposite of true. Mainframes were all about complete reliability; you can always rely on the hardware, or at least that's what you are paying for. "The cloud" is all about the chaos monkey, about writing your application to deal with any server failing (or returning nonsense) at any time. The disillusionment with "the cloud" comes from having to deal with managers who think that "the cloud" means reliability, when it really means "write your applications so they can deal with hardware that is significantly less reliable than hardware managed by in-house sysadmins"

marcus_holmes 10y ago
re: Chaos Monkey. I love this, and I'm 48. 99.999% uptime meant that once a year your program did something completely disastrous because the server flunked. Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward. As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not.
- informatimago 10y ago
  They should hire us for remote work! :-)
- lsc 10y ago
  Chaos Monkey is actually a reference to a tool that I think netflix released? huh. yeah, I see it on github: https://github.com/Netflix/SimianArmy https://github.com/Netflix/SimianArmy I remember someone giving a talk on it in the mid aughts, and I think it's a wonderful way to describe what happens in real-world networks and systems. >Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward. Hah. Part of it is that I am the guy who is responsible for keeping that multi-year uptime (and on most of my own hardware, this is mostly a matter of vetting updates, security and otherwise, and implementing workarounds) - but I like to point out that building a system that can deal with the chaos monkey is... well, it's way harder than throwing up a reliable SQL server with a reliable backup and someone like me on pager. Especially if you want to beat the "the system fucks up once a year" record that even mediocre server-grade hardware can achieve. That said, if you can write such software, I agree that the end result is better, I mean, like half my skillset is in Linux/BSD and environments where reboots cost big bucks, but I'm not going to cry about turning in my pager. I'm just saying, it's hard and most people screw it up and end up building something less reliable than well-managed hardware with a competent oncall. >As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not. Eh, I think that most of the startups that only hire pretty people also tend to pay such that they can't afford someone who is good who has a few decades of experience, so it might be more of a budgetary/age thing; young people, generally, will work for less. I think it might also be a San Francisco thing. The fitness of the people interviewing me goes up and the wages they offer me go down when I head up that direction.
  - throwanem 10y ago
    The strong impression I get is that it's a seller's market for programming work most places in the United States, but a buyer's market in and around the Bay Area. I've never worked there myself, only visited, but I have known a lot of folks from there with hair-raising tales to tell. Things seem a lot more equitable elsewhere.
flukus 10y ago
RE the cloud/mainframe comparison. I was thinking more of the centralization aspect. The web seems to have gone from this vast network where anyone could set up their own server, everything was decentralized (except DNS which was the source of quite a few debates) and no one had any sort of control over it. Now much of the web seems to have condensed into a handful of data centers and we've given too much control to a few companies. The recent cencorship of twitter (and now youtube) really crystalized this for me. On the other hand I see things like docker (I was late to the game here) and even though everyone seems to be focusing on the cloud aspect I can see it being a brilliant tool for decentralizing again. The tech could easily be leveraged to make things like setting up an email server possible again for small companies or families. > I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!) If you work it out let me know ;) It feels like I've spent a good chunk of my career doing this and I'm only 10 years in. The old reliable tools have all be on the same platform FFS.

by lsc 10y ago

marcus_holmes 10y ago

re: Chaos Monkey. I love this, and I'm 48. 99.999% uptime meant that once a year your program did something completely disastrous because the server flunked. Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward. As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not.

informatimago 10y ago
They should hire us for remote work! :-)
lsc 10y ago
Chaos Monkey is actually a reference to a tool that I think netflix released? huh. yeah, I see it on github: https://github.com/Netflix/SimianArmy https://github.com/Netflix/SimianArmy I remember someone giving a talk on it in the mid aughts, and I think it's a wonderful way to describe what happens in real-world networks and systems. >Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward. Hah. Part of it is that I am the guy who is responsible for keeping that multi-year uptime (and on most of my own hardware, this is mostly a matter of vetting updates, security and otherwise, and implementing workarounds) - but I like to point out that building a system that can deal with the chaos monkey is... well, it's way harder than throwing up a reliable SQL server with a reliable backup and someone like me on pager. Especially if you want to beat the "the system fucks up once a year" record that even mediocre server-grade hardware can achieve. That said, if you can write such software, I agree that the end result is better, I mean, like half my skillset is in Linux/BSD and environments where reboots cost big bucks, but I'm not going to cry about turning in my pager. I'm just saying, it's hard and most people screw it up and end up building something less reliable than well-managed hardware with a competent oncall. >As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not. Eh, I think that most of the startups that only hire pretty people also tend to pay such that they can't afford someone who is good who has a few decades of experience, so it might be more of a budgetary/age thing; young people, generally, will work for less. I think it might also be a San Francisco thing. The fitness of the people interviewing me goes up and the wages they offer me go down when I head up that direction.
- throwanem 10y ago
  The strong impression I get is that it's a seller's market for programming work most places in the United States, but a buyer's market in and around the Bay Area. I've never worked there myself, only visited, but I have known a lot of folks from there with hair-raising tales to tell. Things seem a lot more equitable elsewhere.

flukus 10y ago

RE the cloud/mainframe comparison. I was thinking more of the centralization aspect. The web seems to have gone from this vast network where anyone could set up their own server, everything was decentralized (except DNS which was the source of quite a few debates) and no one had any sort of control over it. Now much of the web seems to have condensed into a handful of data centers and we've given too much control to a few companies. The recent cencorship of twitter (and now youtube) really crystalized this for me. On the other hand I see things like docker (I was late to the game here) and even though everyone seems to be focusing on the cloud aspect I can see it being a brilliant tool for decentralizing again. The tech could easily be leveraged to make things like setting up an email server possible again for small companies or families. > I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!) If you work it out let me know ;) It feels like I've spent a good chunk of my career doing this and I'm only 10 years in. The old reliable tools have all be on the same platform FFS.