I see a lot of 40/50 year olds doing Java/Python/C++ development with CICD unit testing skills that are handy programmers without knowing much about JS/ML/k8s. To me that puts them right inbetween your #1 and #2.
As a programmer in that age range I know I don't need to spend time learning the nuances of JS if I'm not using JS. If I start on a JS project (god forbid) I can learn that then. Just like I learned C/C++/Java/Python/PHP/Ruby/Clojure etc when I started on one of those projects.
Machine learning - we know that just means linear regression or Bayesian filters plus marketing, and we prefer programming. We've also seen 20 years of "magic bullet" solutions like ML fizzle and die in the real world and know most ML projects never see a day in production.
K8s is great if running k8s is your job. But it is a specialized skill that is only needed to run very large infrastructures, unless your project architecture (read microservices) has gone very wrong.
20/30 year olds think "keeping your skills" up means learning every new programming fad that blows through because they don't have the experience to differentiate the fads from the advancements. It is like telling master carpenters they need to keep switching brands of tools to "keep their skills up". But all these tools do the same things and are 99% identical. They are busy building stuff with the tools they have.
I love the carpentry example, it's perfect! Sometimes I think tech hiring is kind of like hiring a carpenter, and asking him, "Do you use a circular saw? Because we're a circular saw shop. And I don't mean your 1952 Black and Decker saw, I'm talking a modern day Makita. If you don't have modern Makita circular saw experience, you need to work on updating your skills!"
The older I get, the less interested I am in learning new things for the sake of it. I've already programmed with a whole bunch of different environments in the last 20 years; what's the value of learning something new if it doesn't give me any benefits?
It's not being lazy or a "dinosaur", it's just better time management.
The absolute worst devs I've worked with were very "up to date" people who wanted to re-do all the already-working "outdated" stuff to new "modern" standards. Often, it's just a waste of time.
Very much this. Knowing particular set of keywords that constitutes latest fashion language is a short-term skill. Knowing the paradigms that guide all of them and being able to learn the keywords if necessary in a short time is a long-term skill. Some companies prefer to "hire to the spec" to save short-term learning costs. Smarter companies look into long-term skills which will be useful whatever keywords are in fashion this season.
Which is typically a symptom of having worked at a start-up vs. an established company.
During the dot-com crash, I went from working at a 40 person start-up to a 25,000 employee utility company, and it was a real eye opener. A lot of my "cutting edge" (for the time) skills were dismissed as being flash in the pan, and all the "real work" was done with tried and trued technologies. I ended up finding my way back to a start-up a few years later, and everything was reversed again.
That says "startup". ML is the buzzword that investors love, and k8s/devops allows avoiding big investment into infrastructure which may need to be dropped anyway when it turns out the market doesn't actually want yet another "apply ML to click stream to save on ads costs" startup (I'm stereotyping of course but you get the idea).
I'm 42, and until recently worked for a well known tech company in San Francisco. Most of the time I didn't feel like I was the only person over 30 in the room, but after moving to another city and starting to work on a truly age-diverse did I realize how unbalanced my previous team was.
My current team has a good mix of industry experience and excitement for new technologies, which makes planning both effective and exciting.
Part of the problem is that SF is just so damn expensive... it's going to self-select for people that can afford to live without the additional burden of a family and that tends to be people <30.
Some parts of SV push for diversity and inclusion, but when push comes to shove, firms are quite happy to protect established power structures - shitty managers, retaliatory practices, toxic culture, etc.
No, I am one of the people I just described. I dont know where I fit in with the OP. I'm struggling to keep up with the avalanche of new stuff coming along.
As a veteran dev in my 50's, "k8s" gives me the screaming heebie-jeebies. I've just about got my head around Docker. But it's painful seeing a system that should be a nice little monolith serving a few thousand requests an hour split up into microservices and "managed" using k8s for no good reason.
I realise this might make me unemployable in a modern web dev environment. Maybe I can just ride it out until the industry goes through the rest of the cycle and rediscovers simplicity.
k8s basics is pretty simple actually. If you know Docker, k8s basically is a way to keep a bunch of Docker containers running according to a bunch of YAML configs. There are all kinds of fine details, but the gist of the thing is just that. Of course as every tool it's not always used properly.
It's not the complexity that concerns me. I have dealt with more complex things ;)
It's why people use it in the first place. I get the need for it when you're dealing with huge scale. But it seems to be the new default deployment model, for services that really, and I mean really, don't need to scale that much.
And I've seen people justify breaking a nice monolith into microservices (usually badly) so they can deploy it easier using k8s. Which is totally putting the cart before the horse.
Easier to run a small service in a predictable environment where nobody can step on your toes. Also pretty easy to adjust resource allocations, update pieces independently, easier to isolate screwups (1 part going down sometimes is better then whole thing going down), etc.
I mean, of course you can't approach the task as "we want to deploy on k8s first, no matter what" - of course you have to consider the task at hand and if it works better as monolith - keep the monolith (you can still use k8s - it's just a way to run code, any code can be run within it). But if the task suits the model - e.g. many data processing/transformation/ML workflows do - having a tool like k8s can make deployment easier. One doesn't have to make a religion out of it, but if your problem looks like a bunch of processes working on separate tasks, it may be a useful tool to manage them.
Whether it'd scale better, performance-wise, is a very tricky question, which depends a lot on the task at hand. I think flexibility is a more important aspect. If your task is monolithic and all you need is raw power then maybe k8s isn't the answer.
> Whether it'd scale better, performance-wise, is a very tricky question, which depends a lot on the task at hand. I think flexibility is a more important aspect. If your task is monolithic and all you need is raw power then maybe k8s isn't the answer.
For most (80%+) of the applications I've seen k8s used on, the performance question is not tricky at all. Monolithic performance would definitely be orders of magnitude greater.
I can't help but draw the conclusion that people are using k8s because it looks good on their CV. Whether I'm wise in being skeptical about k8s at my age is a good question.
I can't say much about deployments I haven't seen, but I am using k8s at my current job and where we use it it works quite well and makes deployment easier. I can't tell much details but it's basically processing a bunch of data in real-time in a bunch of ways, organizing them in certain manner and serving certain set of queries from the result. Before anybody asks, no, it's not ads and not clickstreams or anything like that :) And deploying with k8s seems to work decently with that.
Moreover, I can see quite a few places where on my last job (which didn't use k8s) introducing k8s deployment could help in some places. That said, "one size fits all" is never a good strategy. But I think saying "people are using k8s because it looks good on their CV" is wrong. It has its uses, just don't put it where it doesn't belong.
There's a whole lot of current, modern programming that doesn't involve JS, ML, or k8s. Heck, I'm a young programmer and I've done marginal amounts of ML work and avoid k8s beyond a high-level of understanding of what it is.
As an older programmer I have been actively avoiding JS/ML/k8s.
JS is simply garbage we are stuck with where you have to learn all this years footguns to avoid creating bad code. ML is a buzzword of limited scope. k8s is system administration by another name. Web and mobile technologies are useless to learn unless you need them RIGHT NOW as they have a half-life of 18 months.
I want to learn the "force multiplier" sitting beyond what we are using today. GC languages were the last round of force multiplier, and we haven't had much since.
Right now, the only candidate that looks to be a force multiplier is Rust, but I would jump to something else that looked like a force multiplier.
ML is a "force multiplier", but it has limited scope. It might be worth learning depending upon what field I'm sitting in.
Go is just another "managed language" with some oddities (somewhat better support for concurrency useful to servers and some programming in the large improvements).
Dart goes in a similar bucket even with the native compilation.
These languages are all effectively Java with some makeup.
I'm not seeing much force multiplication. I see no new language allowing me to write something more than what I can write now.
It remains to be seen whether Rust will wind up as a force multiplier or not. But it's really the only current candidate even if it's not a great one.
Haha! Given they listed k8 and JS together with ML, clearly that must be something "trendy", i.e. Machine Learning. I love how acronyms can be translated completely differently depending on where you're coming from.
