>Just keep learning and building stuff, and you'll always be very employable.
This is true, but there are a few caveats.
The one that I've been running up against most recently is that a lot of this new-fangled stuff does not really have a strong value proposition, and I personally do not want to waste time on it.
This has become especially true since "cloud" hit critical mass. Junk seems to get generated 20 times faster than it used to and see much wider adoption. GitHub profiles are now status symbols and everyone feels a need to have a bundle of their own showpieces to display.
A lot of the fads are totally perplexing, from the perspective of an engineer who is more interested in building a robust system than padding his resume. JavaScript on the backend (or, even more horrifying, the desktop)? Single-page app frameworks like Angular for everything, including very simple pages? Why?
Yet, it's hard to find a web-oriented position that isn't asking for a background with some SPA and some Node.js. Maybe it's a fad, but it's still going to impact your job prospects.
The takeaway: stay on top of fads and new tech, even if you resent it and think it's really dumb.
I had the same experience with Rails; I hated so much about it and put off getting serious experience with it for 4 years or so. Turns out I still hate it after years of usage, but it was much easier to find work, both as an employee and a consultant, when I had significant experience in the fad.
Didn't matter that I was learning all kinds of new tech that I thought was interesting. As much as one may hate it, it's usually best to bite the bullet and ride the market's waves.
The most frustrating one today is Kubernetes and Docker. Ansible was so beautiful. I hate Docker with a seething passion (not necessarily other container systems), and I see Kubernetes as a very rough toolkit for people who have Google-scale problems that no one should be trying to make for themselves.
Other caveats:
* sometimes techs DO go extinct. Though COBOL is not quite extinct yet, I've known COBOL coders who have gone years unemployed (that doesn't happen to anyone who knows a language/stack still in wide circulation). A small niche has pros and cons, and one of the cons is that the supply:demand ratio is fickle, and may not always be in your favor.
* It is very rare that your technical qualifications will be so unique that they will take precedence over your personal and political qualifications. This is something most developers try to dance around, but the fact is that tech is ultimately run by people, and they want to be comfortable more than they care about that loop's runtime. If you're looking for something that will confer huge career benefits, the odds are that improving your people skills will be more valuable than improving your technical skills. This is almost universally true. It's especially true if you think it's not.
I'm like you; I looked at Chef and thought "WTF??". I looked at Puppet and thought "WTF???". I looked at Ansible and thought "ahh, yes! they get it!"
Most of the application stacks I see that are popular I think of as being invented by people who didn't bother to look around at what had already been tried and rejected by the previous generation.
Caveat I don't build apps that need to scale to millions of users.
Yeah ui frameworks. has anyone else noticed that yahuda Katz seems to have been completely unfamiliar with any other ui framework for the past 20 years? For example the superfluous stuff removed from 2.0? Sure the browser has unique requirements, but sheesh.
I tend to agree that a lot of the new-fangled stuff (aka. hipster shit stacks) are generational/cyclic re-hashes of previous techniques, but unlike previous generation don't even attempt to adhere to standards or otherwise appeal to ideas such as separation of interface/implementation and interchangeability in general. Supposedly, that's pre-generation POSIX or Java-ish greybeard stuff and we're living in a post-standards era after all.
But I think you should re-consider Node.js. JavaScript is based on an ECMA-specified (ISO-adopted even) language with at least three major implementations, plus smaller (yet still highly regarded) ones. The Node.js API is (loosely) based on CommonJS which is as good as it gets in terms of a community API standard for JavaScript.
Genuine question. I'm not a fan of it either, after working with it for two years, but I can't quite explain why. Maybe it's the "magic" aspect of it, since so much is convention, DSL, and hidden away.
Yes, "the magic" is usually the way it's summarized. Everything is expected to be done exactly their way. Your code is interpreted and modified by Rails to fit its pre-conceptions and assumptions about your program. Neither the framework itself nor the support structure around it are forgiving if you deviate, no matter how justified the rationale.
One of the most prominent examples I remember is developing a form and explicitly setting the form's method in the Rails code, of course precisely according to the documentation because we know how picky it is. However, because of some minor detail in the content of the form (which I unfortunately don't remember specifically), I found that the Rails JavaScript was overriding me and dynamically changing the form's method when the form was submitted. I had to hack in the middle there to subvert that event.
It took forever to track that down, something that should've been so basic and simple. This is exactly the kind of anti-feature that developers resent: it's supposedly there to make things "easy" by assuming you meant something, when you've taken pains to say that you did not in fact mean that because you assume it's going to assume you meant that. When you complain, the Rails community blames you for not believing in magic hard enough.
That's emblematic of the entire Rails experience; it's just one example among many. We all know that any moderately-complex program is going to have unique requirements and want to do things that are a little out of the ordinary; if it didn't, you'd just be using something pre-built like Wordpress.
When you get to that point, you're going to be tearing your hair out and fighting Rails the whole way, as it insists that no, you didn't mean that when you explicitly defined it in the place the docs say to explicitly define it; you clearly meant the thing that Rails says you meant.
It'd be one thing if this type of behavior was acknowledged and respected as a bug, but it's not. The response you get is usually along the lines of "Well, why were you trying to disobey Daddy Rails? You are a very naughty coder. DHH could surely beat you in a street race, and you probably haven't even read REWORK." The Rails community is a cargo cult.
Rails is not to be introspected or customized. It is only to be appreciated and praised. After all, you are not as successful as 37Signals, are you?
And don't you like magic? Are you not entertained? Magic won't work if you change all the stuff. Don't ruin the magic! The great visionary DHH has come down with the visions of what web applications should be. Do not defy him.
They try to cover all of this up by saying that they believe in "convention over configuration". This means that if you question Rails, for any reason, you will be punished for your insolence. They truly despise heretics.
That's not how frameworks are supposed to work! I sometimes don't even like calling Rails a framework because it's so rigid. Frameworks are supposed to give users the tools and flexibility they need and then get out of the way.
If I feel like I'm writing Ruby (or whatever the base language is) and the framework is just helping me get that code onto the web (or provide whatever the framework's function is), then I'm happy. If I feel like I have to write in a special framework-specific dialect, then it's not a framework; it's a platform, and I'm writing a plugin for it.
I think this revulsion from big-magic black box "frameworks" like Rails and CakePHP led to the rise of "microframeworks", or "semi-reasonable ways to put code behind a web site", as normal people call them. ;)
This is true, but there are a few caveats.
The one that I've been running up against most recently is that a lot of this new-fangled stuff does not really have a strong value proposition, and I personally do not want to waste time on it.
This has become especially true since "cloud" hit critical mass. Junk seems to get generated 20 times faster than it used to and see much wider adoption. GitHub profiles are now status symbols and everyone feels a need to have a bundle of their own showpieces to display.
A lot of the fads are totally perplexing, from the perspective of an engineer who is more interested in building a robust system than padding his resume. JavaScript on the backend (or, even more horrifying, the desktop)? Single-page app frameworks like Angular for everything, including very simple pages? Why?
Yet, it's hard to find a web-oriented position that isn't asking for a background with some SPA and some Node.js. Maybe it's a fad, but it's still going to impact your job prospects.
The takeaway: stay on top of fads and new tech, even if you resent it and think it's really dumb.
I had the same experience with Rails; I hated so much about it and put off getting serious experience with it for 4 years or so. Turns out I still hate it after years of usage, but it was much easier to find work, both as an employee and a consultant, when I had significant experience in the fad.
Didn't matter that I was learning all kinds of new tech that I thought was interesting. As much as one may hate it, it's usually best to bite the bullet and ride the market's waves.
The most frustrating one today is Kubernetes and Docker. Ansible was so beautiful. I hate Docker with a seething passion (not necessarily other container systems), and I see Kubernetes as a very rough toolkit for people who have Google-scale problems that no one should be trying to make for themselves.
Other caveats:
* sometimes techs DO go extinct. Though COBOL is not quite extinct yet, I've known COBOL coders who have gone years unemployed (that doesn't happen to anyone who knows a language/stack still in wide circulation). A small niche has pros and cons, and one of the cons is that the supply:demand ratio is fickle, and may not always be in your favor.
* It is very rare that your technical qualifications will be so unique that they will take precedence over your personal and political qualifications. This is something most developers try to dance around, but the fact is that tech is ultimately run by people, and they want to be comfortable more than they care about that loop's runtime. If you're looking for something that will confer huge career benefits, the odds are that improving your people skills will be more valuable than improving your technical skills. This is almost universally true. It's especially true if you think it's not.