C# and Java the language are similar enough; the ecosystems are very different. A C# developer would mostly be expecting to develop Windows programs or possibly Windows server / IIS applications. A Java developer could be working on all kinds of different things.
I do most of my development in a what looks like a watered down version of JAVA. Last year I had to dive into C# and asp.bet for a bit. I felt like at home. The language makes sense,there are hardly any surprises and most of its features are excellent. You are right, however, that the ecosystem itself is different and it will take some time to get used to it. However, unless a company hires a contractor on a short term basis,the expectations are that he'd be there for at least a year or two. That's plenty of time to get going and adjust to the ecosystem,which,I think any competent developer would do in a month or two.
There are also arguments when it comes to some very niche types of jobs,e.g. deep optimization all the way to the compiler,some esoteric use cases,etc. Yes,in those cases it's better to hire language native,but for most jobs that won't be the case.
Keyword-happy business HR: "Sorry, we're looking for Java. Case-insensitivity? No, we have to be sensitive to everyone. Being insensitive is not what HR does."
Even one month - two months is a long time for any non-esoteric language except maybe C++ (even that one I doubt) for any developer with experience picking up multiple languages. Most teams are actively working on making their ecosystems easy to pick up for beginners.
That is, unless the company in question has made a complete mess of their pipeline and aren't aware or unwilling to admit it.
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.
Yup. Very similar language, but good luck going from ASP.NET MVC to Spring Boot without missing a beat. Or from WinForms and WPF to Swing and whatever else is new and hot in Java-land. Not to mention NuGet vs Maven, EntityFramework vs Hibernate, etc.
I think this hides/hints at a greater point, though. C# or Java is a technology choice (among many, such as which ORM to use or even whether to use an ORM at all). All technology choices have an impact, and, in my experience working with both of these and other languages, it's just as likely for two shops that chose the same programming language to have made enough other different technology choices to make the transition challenging.
No one said there wouldn't be some ramp up time. Especially if there is another senior Java dev on the team that can "show the ropes", I don't think its that bad.
If we're talking about a lead or solo dev position, it would cause issues though.
This. I can do programming problems in Java, but I definitely can't lead a team doing a Java project. I don't what Gradle/Maven/etc really are. I don't have years of experience with how libraries, the API request pipeline, middleware, etc work. I don't know little tricks / nuanaces, like the fact that Visual Studio has to be restarted for local code to pick up new environment variables, why String and string are the same thing, etc, etc, etc.
I actually find the things _around_ the languages like build tools and ansible and such by far the more confusing parts of dev work just because I never know which of them I should spend time trying to understand and if I just want a runthrough for someone who can already program I never know where to look.
Lots of new languages that arose in reflex to the "stack complexity" of Java ... eventually achieved the same stack complexity with a totally different set of framework/tool names.
Ruby/Rails in particular became this. Javascript rocketed to this complexity level, with the added chaos of seemingly reinventing the entire toolchains every 2 years.
yeah, i never understood that part. People wanting to use javascript on the backend, but not having any of those tools. They exist for a reason, and it's not to make things more complicated.
When I started developing I felt the same way. One day I finally decided that maven was going to be around long enough (and I was going to be a java dev long enough) to spend some time learning. It didn't take long, couple days at most, man has it saved me a lot of grief over the years. CSS was the same, although it took longer than a couple of days, it has been more than worth it.
