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.
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.