The trick isn't memorizing them. The trick is discovering them. I've been emitting various versions of Wingardium Leviosa at Spring Boot for days now, with no effect. Once I've learned the incantation I'll have it and can repeat it in ten seconds, but until I have it I'm producing no actual work.
Arguably, I'm more valuable because I have the capacity to eventually figure this out, rather than having already memorized it. But if this were a crisis rather than a minor bug, it would be much, much better to have somebody who'd already spent that decade learning all of the many, many, many incantations that Spring Boot requires.
(I'd also argue that Spring Boot in particular is much, much, much too dependent on incantations, and the main lessons I've learned could be put on my resume as "Expert in Spring, and you can be too in one lesson: Don't.")
That really applies to all ecosystems. Hiring somebody smart is better. But there really is something to be said for having somebody with X years experience, who can therefore do some things in 10 minutes because they've already done the painful part on somebody else's dime.
I was once backed into a corner to write a web app in some form of Java. So I chose Spring and Angular. After months of frustration, trying to find examples, and put something together, I had gotten just one "show" page and an "edit" form worked out (but not the "update" function side). I put it all aside one day, and wrote what I was working on in Rails. It took me 1 afternoon, including authentication with SAML.
That's when I realized 1) how much Spring and Angular were NOT doing for me (compared to Rails), and 2) how much knowledge lies buried in BOTH stacks. I feel that Rails is by far the better tool for creating CRUD simple web apps, but the ability to be quick with it comes from years and years of living with it, and understanding how 3 or 4 lines of configuration work together to produce the effect of several hundred lines of explicit Java and JS in Spring and Angular.
Disclaimers: YMMV. TACMA. Past performance is not indicative of future results. Et cetera. Et alia. Ad nauseam. E Pluribus Unum. QED.
From my perspective, a great advantage of Java over non-statically-typed languages is that when I make a stupid error, most likely the IDE will notice it and underline it immediately. Thus I don't waste my time hunting for stupid errors.
That is, unless I use Spring. The stupid Spring-related errors only appear at runtime.
Ok, honestly, after a year, using Spring is more convenient than not using it. (Basically, there are two or three types of stupid errors I usually do, and I learned how to decipher the intimidating error messages.) But the first experience is quite a shock. You write something with algorithmic complexity of Hello World, then you run the program, it throws a screenful of error messages, and you want to scream.
It reminds me of my childhood experience with Turbo Pascal, where you had to wait until the compiler told you that you missed a semicolon... and then it pointed at the wrong place -- not the place where the semicolon should have been, but usually the beginning of the next line. After some time, it becomes obvious, but the first time it's definitely not.
Oh, if only you get error messages. My most common mode of failure in Spring is "nothing happened". Which there's no way to debug, or Google. At least error messages show up in Stack Overflow. You missed an annotation, or provided the wrong kind of annotation, and Spring just said, "Well, apparently that code doesn't matter."
Inversion of control means you have no control.
At least Spring has switched mostly to annotations, which are sorta like Java. The IDE can spot some errors.
Until now, I felt bad that I haven't learned Spring earlier. Now I feel happy that I only met Spring after the annotations were added. I can't even imagine the horror...
> It reminds me of my childhood experience with Turbo Pascal, where you had to wait until the compiler told you that you missed a semicolon... and then it pointed at the wrong place -- not the place where the semicolon should have been, but usually the beginning of the next line. After some time, it becomes obvious, but the first time it's definitely not.
C++ template expansion and linker errors come to mind. First time you encounter those it's typically either very short and cryptic or at least 500 errors and the compiler hitting an internal limit of how many of them to display.
I reach for Spring Boot as my tool of choice for most APIs, but I feel your pain. There’s always a particular corner, the dreaded “configuration” folder, filled with a collection of random annotations, single-purpose beans, filter chain setup, etc.
I find that most of my business logic ends up being really compact and powerful, but the tradeoff is that one chunk of the project is really dense.
The problem isn't can I learn, the problem is do you want to wait. You need a few great developers who have a lot of experience to ensure that a mess that is hard to clean up isn't main. If you have a 10 great developers who know how to do whatever right, then 100 other great developers who no nothing about the whatever can learn. However without those 10 experts in the domain to start with nobody knows what the right decisions are in the first place - in 3 years they will realize their mistakes but by then it is too hard to fix them.
To qualify the anecdote below, let me be clear that I’m an outlier: I have shipped‡ software on _lots_ of different stacks and 35+ different languages°.
I know exactly the difference between having to deal with the Java ecosystem for SOAP and the Microsoft ecosystem for SOAP—I had to deal with both at the same time at one job a decade ago. At that job, I worked with a lot of really smart people, but it was a Windows shop. Most of the people I worked with _could NOT_ work with the non-Windows platforms we had to deal with (HP-UX, AIX, Solaris, Linux, VMware, and HP-UX). They would _constantly_ break code that was written to be cross-platform safe because it wasn’t what they were used to. On the other hand, at least I didn’t have to become familiar with how Exchange worked in order to integrate with _that_.
The number of people who can make the level of context switch you’re referring to, or working with multiple contexts like this, is vanishingly small in our industry. It can be done, but I think that you deeply underestimate the surface area of those ecosystems and the _willingness_ of people to put themselves in uncomfortable positions. The OP who talked about knowing C# but being interviewed for a Java position would have been _deeply_ uncomfortable writing Java because the tools they were used to weren’t available.
I would not make the same judgement you’ve made here. That said, if someone _wants_ to learn a new ecosystem, I’m happy to have them explore that (I prefer ability to learn over proven experience when I’m in a hiring position).
‡ Shipped: made it so that others could use, not just myself. This would include a project that I ported from Ruby to IO so that I could learn IO and a project that I ported to Elm in order to learn Elm. It does not necessarily indicate pickup. If we restricted this to stuff that I know that other people used, I might lose a couple more than the two I just mentioned.
° Languages: I include variants of languages that are _sufficiently different_ from their predecessors so as to require translation. This mostly affects the shell scripting variants (Posix sh, ksh, bash, and zsh are all _similar_ but sufficiently different that I count them; I have shipped substantial scripts in each). I don’t count gawk vs awk. Regardless, I vary between 3–4 languages and ecosystems weekly at my current job.
Also, rejecting someone because they can't rote memorize ecosystem specific incantations is... a pretty big red flag.