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.
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.
We kind of have. They're called YAML files now.
The other day, a promising young programmer asked me how to deal with the overwhelming load of new frameworks. Which ones should he learn? Which ones should he ignore? What should he do if he picks the wrong one? How will he know?
In my opinion, it really doesn't matter as long as he is learning something new. You only get stuck when you try to stick to the things you are familiar with. You need to keep stretching yourself time after time.
If someone says to me, "Do it in Python", "Do it in Elixir", "Do it in Haskell", "Do it in Go"... it just doesn't matter to me. I've been through that blender before a hundred times. In fact, that's precisely why you would pick a guy like me. I'm not trying to keep up with the current trends. That doesn't matter. But I'm also trying not to hang on with a death grip to what little I know.
On the other hand, if you need some guy who knows every single detail of how Rails works, hire a young guy who has only ever worked with Rails before. You need a mix on a team. Pair him up with an old guy so that he gets some perspective before he burns out his career.
Oh, absolutely, we often do. But, like the ancient kungfu master trope, you can't tell your juniors this directly, it's a realisation they have to reach themselves. Sometimes while being smacked in the face by the consequences of not listening.
(More seriously, being a curmudgeon doesn't help; being a mentor does)
Background: Current company recently got series B, and I'm trying to aggressively scale the engineering team. As such, I've been rapidly phone screening candidates at a much higher volume than usual.
After screening the first set, I began feeling very sad about the current state of software engineering. The average age was probably about 27. All had CS degrees. All were experienced Java developers. And, yet most did not know the difference between a long and an int. Most couldn't describe the differences between linked lists, arrays, and hash tables. Most could not explain how to make a block of code thread safe. Most could not describe how an interface is different from a class. Most could not explain the difference between value passing and reference passing.
I was so aghast. I mentioned in passing to a co-worker that computer science degrees must have become so dumbed down over the last decade. But, then I realized my mistake.
Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.
Another thing I've seen many times is that the listing either wasn't written well, circulated in the right communities, or that details like compensation or the environment scared off people with better options. That can be a very delicate subject to bring up because many places don't want to admit that the problem could be their business rather than the candidate pool.
Let's say you're a good, experienced developer. You get 10 recruiter messages per week. You ignore most of them but 1 in 20 you decide to read. There's a 10% chance that the description looks like a good fit. You contact the recruiter and tell them your salary requirements. There's a 15% chance that it's in your range. You decide to set up a phone screen. But, since you're valuable to your current company, you're extremely busy. There's a 20% chance that you can make the call.
I'm too lazy to calculate that, but that's a huge number of people to contact just to phone screen one good person.
While I agree with this statement, the ageism I think is plaguing the Valley is an interviewing/HR/hiring issue, as it is in that process that their confirmation bias is being reinforced there when they bring the old dogs through the door.
FWIW the best engineers I have ever worked with, in my opinion, always seem to be the ones ten years or so ahead of where I am. They're the ones I am always learning something from.
There are many large companies (mainly, banks and card corps) paying really, really good salaries for people with 30+ years experience with COBOL, JCL, REXX and the like. You know, mainframe stuff.
Obsolescence is in the eye of the adolescent, if I may be so bold.
The salary you quote, converted to UK money, is about right for entry-level roles. I was hired in that company at a graduate level and I had no experience of mainframes whatsoever when I got the job (which I hunted down out of the same morbid fascination you mention).
My older colleagues though, the ones with 30+ years experience, they would be getting much better money than that. It would depend on the position also, but I heard of at least one graybeard who was asked back from retirement, because the company couldn't afford to lose his expertise.
Now, I don't know what they paid him, but I'm pretty sure it's what I call a really, really good salary.
My formula is to spend at least 15 hours a week on non-billable learning projects, writing technical books, etc. A lot of this time is simply reading papers in my areas of interest (deep learning, functional languages like Haskell, application of deep learning to NLP, etc.) and writing enough code to make sure I understand new technologies.
I get hired because I stay current.
I agree that core technologies like linear algebra, machine learning, etc. aren't the current topic. The main thing is to learn new things, and as someone else here said, maybe it does not matter so much what you learn as long as you learn new things.
It's the age equivalent of https://xkcd.com/385/ . When it's a younger person, it's "this person can't code for <x> because they don't have experience." It's harder to quell that cognitive dissonance when you don't have that out and forces you to place the blame on incompetence.
But for my own stuff, there's no way I'd use any of that crap. Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids. This stuff is my proper income stream, and the most important thing is that it works. If that means I have to write a "for" loop and declare variables and risk 19 year old kids snooting down at my code, so be it.
But yeah, the key is to never get so far down in to that comfy hole that you can't hop back into the present day when it's time to talk shop with the cool kids.
Turns out you can get a lot done when you don't have to constantly fight with terrible 3rd party javascript.
"I've found there are either people who believe they know better at everything whose skills have not improved much, and then people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time"
That being said, there is something compelling about an older engineer who constantly re-invents himself with the latest technology.
That's the point I'm trying not to make. Are you building a startup that's effectively a CRUD app? If so, sure, that's pretty much all you need and is why coder schools have become so prevalent - they get you to a practicing point that covers the bases of most small websites and very, very basic startups.
Age and experience brings with it something vital: the ability to build long term pattern recognition of technology business cycles, the "all is old is new again", the ways that novel technologies may fall like their predecessors. This is not something you learn in a CS program or even a few years out of college. It's something you only learn by playing with tens of languages and mastering six or seven over decades, by constantly learning, by being part of those business cycles. This skillset is often discredited and is enormously valuable, but I believe it requires a tireless passion for novelty and modern technique to become a multiplier on skill.
No. After four years you know just about enough to inflict a really nasty case of the second-system effect on some unsuspecting customer.
My biggest to date (but not the only one): having received complaints, I figured in 2 days that the culprit is the change in the manufacturing-workweek-number of the DDR ICs. It took them several months onsite with people travelling from abroad and with expensive equipment to find the real root cause, and guess what they have found?
And I am not even a hardware engineer. How did I do that? Intuition. You need lots of time to develop intuition, much more than 4 years, and once you got it, it saves lots of time and money.
I have also seen other experienced engineers do this sort of tricks, and I pity the workplaces where people aren't familiar with this.
I think there is just a large percentage of people in tech that do it to make an income with the least amount of thinking. Only a small percentage is really interested in the technology.
The "old" people who are curmudgeonly and stuck on older technical stacks are the ones who don't fare well. The ones who are current in skillset never seem to have an issue and generally impress the people they meet, as they bring both experience and current technical knowledge to the table. Anecdotally, I would say 8/10 of the 40+ crowd I have interviewed fall into the "old technical stack" / "i know better" crowd, and I think these are the ones that poison the well for the good guys.
I am beginning to believe that the trick to software engineering as a career vs. management is to stay current above all else. If you let yourself become obsolesced, you will be thrown aside like an old PowerBook. That's the reality of the technology industry and has little to do with age.