6 ms·
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
by halostatue 6y ago
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.
- DoubleGlazing 6y agoThat's the case for me. I'm Okay with the Java language, but everything else about it's ecosystem is different from the .net world.
- throw1234651234 6y agoThis. 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.
- soperj 6y agoGradle & Maven are just build tools. They can be used for other stuff, but that's what they're mostly used for in my experience.
- deleted 6y ago[deleted]
- faceplanted 6y agoI 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.
- mike00632 6y agoGradle, CMake, Python virtual environments...
- soperj 6y agoWhen 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.
- AtlasBarfed 6y agoLots 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.
- soperj 6y agoyeah, 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.
- AtlasBarfed 6y agoIMO the tools that have been created to fill the gaps seem to be poor imitations of dotNet, rails, and java frameworks. The testing framework I saw in a React app were almost straight from java, but somehow (despite JS being more flexible and script) MUCH uglier.
- ufmace 6y agoYup. 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.
- 3np 6y ago“Actually, you know what, I think this is not a great match”
- twodave 6y agoI 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.
- jayd16 6y agoNo 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.
- cosmodisk 6y agoI 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.
- BlargMcLarg 6y agoEven 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.
- msla 6y ago> JAVA 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."
- 908B64B197 6y agoIf someone can't learn a new ecosystem, I have bad news for them in this industry. Also, rejecting someone because they can't rote memorize ecosystem specific incantations is... a pretty big red flag.
- bluGill 6y agoThe 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.
- jfengel 6y agoThe 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.
- chrisdalke 6y agoI 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.
- pjmlp 6y agoIn many agencies, like where I work, everyone is .NET/Java polyglot, one hops between platforms, depending on the project. On top of that comes SQL backends, Web and occasional C++ for some native libraries to plug on. At previous jobs the employer followed similar development approach. I never got the Developer X mantra.