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"
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.
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.
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.
In the South Bay, I largely don't have cultural fit problems, and I can pretty easily score pretty good jobs at second and third-tier companies (getting jobs at top-tier companies is a real challenge, still, but considering the compensation and prestige at the end of that particular tunnel, I can see why.)
In San Francisco, though, I quite often have 'cultural fit' issues, and often can't even get into startups that pay really poorly.
I often see it get written into contracts with very little thought as to what it means. You get some great looks from managment when you break the figure down into minutes though, especially when you don't have 24/7 staffing. A poorly timed cosmic ray could ruin your SLA.
* It would where I'm at now, because someone thought it would be a good idea to handle a critical business process by emails csv's.
60x60x24x365 x (1 - (99.999/100)) = 315.36
Wikipedia confirms: https://en.wikipedia.org/wiki/High_availability#Percentage_c...
So yes, 2hrs of downtime would most definitely violate the SLA. The 8 hours you refer to is the figure for 3 nines.
Two decades on their C/C++ win32/x apps are running and no one has java installed in their desktop to run mine. They have every reason to be smug.
When I look at all the apps installed in my computer, very few are .net apps.
I think we've been completely skipping this step for the last few years.
Lately I've been taking a look at a lot of older tools and being pleasantly surprised by how capable they are compared to modern ones. I started coding professionally in a world of virtual machines and xml files, now where moving back to native compilations and json. Eventually we'll rediscover ini files and how there even simpler than json and we can avoid the curly bracket tax. I've used every build tool under the sun but recently discovered that make was simpler and better than anything else I've used. We've gone full circle on ORM's and now writing sql is in vogue again.
I wish I'd learned more from those guys much earlier.