In my experience it's exactly the opposite. People who do nothing but write glue code between major services think they're hot stuff.
One of my personal career goals is to stay as far away from simple glue code as I can. Unfortunately it makes up most of our field right now. But it seems like an especially precarious place to be.
Most lawyers are doing simple glue stuff and think they're hot shit. You think I couldn't refer that case to another law firm, or a machine?
Most businessmen are doing simple glue stuff and think they're hot shit. You think I couldn't randomly guess at the market, but not outperform it, nor a machine?
I think you'd get the 90% case due simply to the preponderance of people who have a cold instead of some other, more rare condition with similar symptoms. Problem is you'd cause harm to everyone who doesn't have a simple cold because you have no idea what you're doing.
Comparing the knowledge needed to be a good doctor to what is required to throw up some bloated SPA? C'mon, get over yourself.
With programming, if you are designing the control system for an aircraft and it fails, people will be able to find out exactly what failed and why, and who to blame.
It's hard to compare doctors and programmers, because there are many levels of medical professionals, just like there are many levels of programming.
Lawyers have paralegals that dig through the case studies and case law for them along with law databases like LexisNexis.
The ability of an experienced professional to quickly decide these things comes after many years of hard-won skill building...
They either have a checklist, or they wing it. You give obscenely too much credit.
Medical mistakes are incredibly common. There are thousands of people who DIE from prescription accidents each year.
I look forward to the day where I can send data from one place to another and not have to bother with file formats, text encodings, port numbers, network protocols, and so on. IP (and especially TCP/IP) is so prevalent today that we use "IP connection" and "network connection" interchangeably. Someday I hope we have that consistency at some other layers of the stack. I shouldn't have to say "send me that file -- what app did you use to make it?"
Now, UTF-8 is a given and there is a mess of potential issues. No longer are byte-by-byte comparisons reliable, especially in some languages like Vietnamese.
Your example of IP connection and network connection is true, but overall connections are more complicated. Some clients can't use HTTP2, some clients are behind firewalls, some clients need CORS support, etc.
And plus there is this accelerating wave of advancements everyone is trying to keep up with, but that come with real investment. Upgrading OSes, programming languages, frameworks, libraries. Figuring out how to keep data secure.
I really don't see things getting less complicated as time goes on. At least not until we have some real form of AI, but even there I have my doubts because there will always be tradeoffs.
It'll take a bit of evolution to get there depending on how new the problem is, but it also took a bit of evolution to get where we are today, and nothing is ever perfect.
What are you doing where that can't covered by that use case? Actually, I can think of tons. What are you doing that can't be covered by that use case, but is still boring?
A lot of people aren't in a position to do this. I think actual plumbers also have to deal with similar constraints.
It's nice to not be constrained, but it's also more impressive to do a good job under severe constraints, IMO.
When seeing something one doesn't understand, the default reaction of an intelligent person should be to ask oneself what one should learn to comprehend it. It shouldn't be dismissing it as "clever".
There is a reason why so many projects end up being a giant mess.
Most people aren't smart enough to make it through a bootcamp and those who do still need years of experience to be fully productive.
I welcome more boot camp grads. The amount of work for both groups is growing. I don't see salaries for devs falling. They may flatten out for some business problems/areas, but new and/or underserved will always appear.
It's very much a "correctly predicted nine out of the last five recessions" kind of situation.
Incredibly thorough code reviews helps reduce this, but at that point it slows down the skilled members of the team too much for it to be worth it.
The issue of precarious is also a bit "the grass is greener" sort of view. In 5 or 10 years when the industry again looks different, bootcamp level web dev work may be as precarious as you project. But right now, what's more precarious, specializing for one company in a corner of the industry where there are only a small handful of companies, or working for a company that you the employee, could easily replace?
E.g. "software engineer", and "programmer" should be labels for different roles/capabilities, as should be "computer scientist". Using the terminology incorrectly should be frowned upon, similarly to how this goes in other disciplines.
These have a lot of core skills in common, both hard and soft, but it's such a mishmash of things that trying to impose precision via labels doesn't seem helpful to me.
It's also why there's so much difficulty in bringing wages down by just training more programmers: it's much harder than it looks. Teaching people to program is far more unreliable than other disciplines; the degree of self-starter on-demand continuous improvement required is very high. Other professions (e.g. actuary) may have a big hill to climb, but the requirements are written down and there is a clearly marked path up the hill. In software you may wake up to find that someone has moved the entire hill during the night and you have to make your own path, again.
But what is a "computer scientist", really? Is it just some theorist who sits in an ivory tower and tells us all what to do? In my opinion, a "computer scientist" can actually be either a programmer or an engineer (or maybe have both in their blood? who knows). It's someone who is less concerned about building things for today, and more concerned about how computers are going to work tomorrow. It's a wholly separate role from us "construction workers" who have our boots on the ground and are actually building things...the scientists are concerned with how we're going to build things tomorrow. I don't know if Rob Pike, Robert Griesemer, Ken Thompson, or Russ Cox still work on actual systems code anymore or whether they just figure out how to improve the Go language, but assuming that they only work on Go full-time, that to me is the role of a "computer scientist", though for example Ken Thompson is also a "programmer" because he likes to build things.
Also, separating "building" from "maintaining" (when "maintaining" means more than running / scaling / securing, and also includes adding features) is a a recipe for disasters! The builders/creators start creating unmaintainable messes because it's not their job to maintain them.
I don't think these kinds of distinctions help in software... we need different ways to look at the problem...
Also this lack of separation is kinda what makes software dev a cool field to work in... I love the hacker mentality and if it ever fully dries out I'm gonna quit working in this field and move to a fresher/younger one.
Integration platforms are getting good. The API integrations that make up a lot of my work might be better done with them in not too long. It's already reached the point where some clients speak with me only after an integration platform hasn't met their use case.
For example maybe if you went to bootcamp, you (crimsonalucard) would be hot stuff when you came out (even if you've been programming for 20 years), due to exposure to all the external services you'll be able to glue together.
The fact that your glue code will have runtime O(1) (a single call) instead of O(n^n), but only for up to 4, as the poor kids do something like have four different if statements for 1 to 4, and each one is a nested for loop, and over 4 it silently does nothing, is less relevant than the exposure to the API's at all.
In other words, maybe terrible programmers can be hot stuff writing the latest glue code - even if it's brittle and barely works.
With all the services huge companies are exposing, this wouldn't surprise me.
Under that definition, anyone on the face of the earth can be "hot stuff." You don't even need to go to bootcamp. Just read some online tutorials, make a website. Done. You're just calling the average person "hot stuff."
In my opinion, you're only hot when you know how to do something that is rare, very hard to learn and in demand.
In fact that's all a modern website is. The old way involved servers rendering pages. Now The frontend interfaces with an API. Efficiency at the cost of complexity.
You want to know what's impressive? Writing a compiler. Writing an OS. Nothing is simpler than interfacing with an API.
If writing glue code is your job and you're getting paid a lot of money to do this stuff then count your lucky stars because truly anyone can do that job.
In fact, I think it helped me get my current job.
If I'm working on a blind, handicapped user's interface and someone figures out how to connect OK Google's speech recognition in a few lines of code, and it's legit and allowed by their terms, it's still impressive. Who cares if you don't know the first thing about speech recognition?
What's going on right now is a bubble. People perceive these skills to be "hot stuff" when in fact it is just "average" or even "below average"
When the bubble bursts all programmer wages will go down after everyone realizes that programming is a skill akin to driving or algebra. Anyone can do this trivial work.
Try "random walmart shopper" (a box store that everyone visits.) or just random person.
As for your claim that a random person can learn to write glue code, well, we're going to disagree.
>Try "random walmart shopper" (a box store that everyone visits.) or just random person.
Random Walmart shoppers are people too and they can be intelligent as well. I use the word homeless not to imply lack of intelligence or to insult, but to imply that even a person with no ability/capability/desire of getting a job can with minimal training gain those skills.
>As for your claim that a random person can learn to write glue code, well, we're going to disagree.
Can any person learn algebra? Can any person learn arithmetic? Can any person learn to read an english book? All of these things, seem trivial to learn, but they are not trivial at all. It is only because of the context in which we learn these things do we find it easy later in life, but fail to remember that at the time of learning, these concepts are just as hard as programming.
Programming is not easy to learn just like how reading english is not easy to learn at all. But make no mistake, just like how basically anyone can learn to read english, anyone can learn how to program. Some people have talent for learning languages others don't, but with time, everyone can learn it. That's how cheap this skill is.
The very existence of bootcamps hinges on this concept that anyone can learn. People walk out of a bootcamps thinking they have talent or were taught incredible skills. The reality is, everything they learned is available online for free. They paid money to learn because they lack the self control to do it themselves.
I think the people who can go through a coding boot camp successfully have great arithmetic skills, great reading skills, and can easily solve 2x-7=11 for x in their head in a moment 100% of the time. (Basic algebra 1.) And can read any generic software manual easily, if the manual doesn't assume too much prior knowledge and is written at a basic level.
I don't think the average walmart shopper can do it.
Do you disagree? What do you think the baseline skills are for people who go through a coding bootcamp successfully? Maybe you have more experience with those people than I do. I think of them as intelligent, educated people with above-average SAT scores but without specialized programming training, who decide to go through a boot camp. They're curious, motivated, smart. But they're not programmers.
Anybody can do what you just described with practice and training. The typical high school education along with programming is achievable by the typical person.
>I don't think the average walmart shopper can do it.
Stop insulting walmart shoppers.
>Do you disagree? What do you think the baseline skills are for people who go through a coding bootcamp successfully? Maybe you have more experience with those people than I do. I think of them as intelligent, educated people with above-average SAT scores but without specialized programming training, who decide to go through a boot camp. They're curious, motivated, smart. But they're not programmers.
I don't even think you need to go through a bootcamp to get the baseline skills needed for your typical "glue code" job.
Anybody can learn programming. People who go through a bootcamp typically have enough skills to do the job but they likely may not have enough skills to pass a coding interview. Coding interviews are, unfortunately, harder and unrelated to the job.
Anyway we clearly view people's baselines differently. Maybe you're the one who's right.
>I don't think given pen and paper but no google, the average person can solve 2x-7=11 for x.
I'm pretty sure everyone on can do this.
>Anyway we clearly view people's baselines differently. Maybe you're the one who's right.
I think you're way off. Check your baseline. There is not one person in my high school who couldn't solve that expression in their head.
Folks in the middle of the curve are blissfully unaware how much there is to know and how many difficult problems must be solved to put together those backend services they are gluing.