today fullstack developers have to pivot between 2-3 languages on the same day
All the SOA back then was JAVA, they had just different types of HTTP servers to run JAVA
I constantly write software in Typescript, Java and Kotlin. Some days it's all of them other days it's only a subset. I don't see an issue with that at all. If you don't have a standard set of languages I would agree with you but a stack of one frontend and one backend language should not be a problem for anyone that calls themselves full stack.
The SOA point was not about languages any longer. It was about having multiple services that make up an overall feature and app landscape. Also you seem to have missed the part where I said that I was not in fact HTTP calls is manyif not most cases ;)
I fail to see how one has anything to do with the other.
Knowing and applying both Java and Typescript is not an issue at all. What is a pain is CSS and why I tell everyone I'm a BE dev. But I happily build vertical slices of functionality where I have full control over FE and BE code and can adjust as I see fit instead of having to create or follow a rigid interface definition and where the BE isn't user testable when it gets written. What is a pain is the libraries on the FE but that's not an issue with knowing multiple programming languages but with the web dev FE ecosystem in general. A non full stack FE developer would have the same pain.
While we did learn a programming language at university to code our exercises in, we didn't learn that language specifically as "this is the language we teach and this is what you will use in your job until you retire". On the contrary we were told and taught about programming concepts, data structures and algorithms and it was expected that you can program in any language. The (mandatory) operating systems course for example would just assume that you learned enough C by yourself to do the programming exercises. We had to write a working memory compactification algorithm for Minix. In the scripting language course (non mandatory) you had to choose any scripting language you wanted and implement a project in it. In the mandatory hardware course we were expected to pick up enough VHDL to implement whatever we learned in the course.
You can't program in any language, don't fool yourself. Take, for example, SQL that is used in all companies. Can you write SQL functions with the same ease as Java? You may ask why do you need functions in SQL? Because it is faster to run the algorithm in SQL, rather than in Java from an ORM.
I'm not saying I can instantly program at expert level in any language I've never heard of. But yes, I can read most programming languages even without ever having seen them. Take LUA. I had never used LUA and when I started out I was reading code examples and writing LUA code without first "learning" it at all. I just went and did it. Did I probably do some "stupid things" that an expert would do differently and/or fast? Of course. But I got stuff done and learned as I went along. Same when we introduced Kotlin for example. I was instantly productive but someone using Kotlin for a longer time (such as today's me) would "cringe" at how I was writing Kotlin as if it was Java.
Notable exceptions would be languages that have such a weird syntax as Brainfuck ;)
SQL is a great example. I have not been using SQL directly for quite a long time now. But about 20 years ago my bread and butter was SQL and I was writing stored procedures every single working day and I was not writing any Java at that point in time but was using two other languages other than SQL on a daily basis as well (Perl and Bash).
But an unexpected change will come and you will need to go back studying on your free time. This is always happening in our industry, you were just lucky for not living it because you sticked with Java.
In professional capacity over the years I have used Perl, PHP, Bash, SQL (various dialects), Java, Groovy, Kotlin, Scala, Javascript and Typescript. I did not move from Java and OOP knowledge to other programming languages. I started with with languages that don't (have to) use OOP. I still work with Typescript (and until recently Javascript) while also working with Java and Kotlin. And in Java and Kotlin there is very little traditional OOP going on.
I guess the point there is to always keep learning and evolving. I learned Kotlin at work, while doing it. I learned Typescript at work, while doing it. I learned about various libraries at work, while using them. Until a few years ago, I had never used React and I have never used React except at work.
Talk about it. Prolifically. Say that you have no problem working on "that thing" but that it's going to take more time, because you're unfamiliar with that language / library / service or whatever it is that would slow you down.
Then adjust your estimates. If you are working on something completely new that you know nothing about, put in "Spike" tickets to prototype things. Put larger estimates for the tasks themselves after for the "unknown unknowns". When you discover an unknown unknown that can be extracted as a new ticket from what you are currently working on, create a ticket for it to make that fact visible and adjust your current ticket to say it got extracted so nobody still expects your ticket to do it.
Tickets are not evil, tickets are protection for developers - create them and comment on them, explaining what is going on and what needs to be done. Most companies aren't really "evil" in that way. They just don't know better. If you do happen to be in one of the 'actually evil' ones, go find another company to work for. E.g. if developer are not allowed by process or actually prevented by the ticketing software from just creating tickets and moving things around as necessary: run. Don't walk. Run from that company.
Tickets are useless. Real tickets are unit tests that need to pass for the software to be ready for production.
Tickets cannot protect you, only Odin's switch statement on stack trace can protect developers from bad changes.
I will give you an example, you worked for a company and on a ticket, you wrote “this code works this specific way and should never be changed”. After 6 months, the company fires you and another senior developer takes your place. The new developer never read previous tickets because no one read old completed tickets, so no one will read the message you left, and they will change the code accidentally.
However, in Odin with unit tests and locking stack traces with switch statements, the code is really protected from these kinds of accidents.
The “while doing it” does not work if you don't have experience with similar language. If you don't believe me, try learning Rust while writing a server for your work.
But I think I'm barking up the wrong tree here anyway, because you seem to be completely set in your thinking that nobody should need to know more than exactly one programming language and that should probably be Odin and that anyone thinking or saying anything else is just wrong. Well good luck to you getting paid and having fun. I definitely know that someone with your attitude towards learning and expanding ones horizon would not last long at my place.
only Odin's switch statement on stack trace can protect developers from bad changes.
on a ticket, you wrote “this code works this specific way and should never be changed”
What I was saying about tickets being protection is that they're protection against "the company" and process and being rushed all the time "because agile". Embrace them. Use them to your advantage. Someone gives you one ticket to do X and do it quickly but you don't know the library or service involved? Convert it into an Epic and extract 10 tickets including some prototyping in spikes.
Odin with unit tests
Making simple tickets to epic shows that the company does not have a software architecturer. It means that you create a monster application with full of technical debts left by junior. If CDD used in your company, nobody would ever be able to replace a ticket with an epic, because the architecturer would show you from where to start and what steps to take.