4 ms·

> Any Java developer who doesn't know... I take it you work for Google or contribute to projects under management of Google. Perhaps Google is more selective

> Any Java developer who doesn't know... I take it you work for Google or contribute to projects under management of Google. Perhaps Google is more selective in their hiring. My claims about Java developer generalizations comes from a decade in the travel industry with 4 of its largest corporate brands, each (at one time) employing thousands of developers. This is the reality of big corporate software development. Take a look at any major corporate brand presence with a website and notice how many megs are downloaded for small amounts of content and tiny interactions. Consider that content quantity served on webpages has not dramatically increased since the 90s and the interactive experience has gotten better since the 90s, but not by orders of magnitude. Yet, despite high speed connections it takes longer to load most corporate websites now than it did back then. It seems, from the bloat, exchanging developer competence for tooling and ecosystem advancement has a had a negative correlation on performance and code quality. I completely understand this is an over simplification, but most problems solved by ecosystem advancement aren't problems related to any business requirement or user concern. Most of those problems are things only developers care about. The changes to the platform that actually do relate to business concerns are generally addressed as enhancements to the technology standards that comprise the platform. If you do work at Google you have access to economists and can get their opinion on this matter.

cromwellian 8y ago
I do work for Google, but I've also worked at Oracle, IBM, several startups, and in enterprise consulting. Yes, Enterprise software is full of very low quality development, but this is language independent. I have seen plenty of web developers in enterprise whose sole skill was cut-and-pasting jquery snippets from web searches and tutorials and using jquery plugins. I've also seen some pretty terrible Ruby-on-Rails stuff in the enterprise. Actually, Obamacare's launch was stymied by poor Ruby code, and I hear Square at one point had problems with their Ruby, hired a bunch of Xooglers, who redid everything in Java. (and released some kick ass Java open source libs, like Retrofit, Dagger, etc) The common variable isn't Java, or Javascript, or tooling, it's Enterprise IT hiring inexperienced or unqualified engineers, often consultants, some of whom don't have degrees in engineering/CS, or are from body shops. Once enterprise switches most of the legacy systems from Java or Ruby to Node, you're going to find exactly the same people writing horrible code. You can already start to see it in the Node ecosystem, and in Kubernetes (go ecosystem), with people piling high on dependencies and frameworks, layer upon layer, of new-fangled tools and magic that will solve your enterprise problems, but what it ends up doing is creating a brittle system of crushing complexity and bloat and silos of IT department people who have narrow specific skills as opposed to general purpose engineering skills. The big tech companies in the valley don't look for candidates who have acronyms on their resumes "Java/Javascript/SQL/noSQL/RDBMS/J2EE/XML/SOAP/...." or professional training certifications, they look for people with general purpose engineering skills who can learn any language needed, and who generally adhere to good practices and habits. Back in the 90s, I taught retraining courses to enterprise and government workers. Many of them had never done coding before outside some basic Office or Lotus Notes scripting, and some of them were former COBOL users. A lot of them were reading books like "Perl, CGI in 21 days" or "Java in 21 days". And that's the problem, because the proper way to retrain your employees isn't to send them for a crash course. It's to hire some very good engineers and engineering managers, and let them learn as apprentices having their code reviewed by them. I don't want to bash all enterprise developers, there are some excellent companies out there doing good work. But my general impression from years of cleaning up messes I encountered in consulting, is that corporate IT departments don't care about things like code health or tech debt. This isn't a Java specific problem, it was there with COBOL, and it's there with Ruby, and it'll be there with Node. It's just whatever is Enterprise's favorite fad du jour will eventually be given a bad rep. If enterprise was using Haskell, even Haskell code would come out with a bad rep. :)
- shooptake 8y ago
  To be fair, plenty of Googlers/Xooglers/other Faang alumni produce hot garbage as well. Sure, on average you might have better code, but that doesn’t mean its good.

cromwellian 8y ago

I do work for Google, but I've also worked at Oracle, IBM, several startups, and in enterprise consulting. Yes, Enterprise software is full of very low quality development, but this is language independent. I have seen plenty of web developers in enterprise whose sole skill was cut-and-pasting jquery snippets from web searches and tutorials and using jquery plugins. I've also seen some pretty terrible Ruby-on-Rails stuff in the enterprise. Actually, Obamacare's launch was stymied by poor Ruby code, and I hear Square at one point had problems with their Ruby, hired a bunch of Xooglers, who redid everything in Java. (and released some kick ass Java open source libs, like Retrofit, Dagger, etc) The common variable isn't Java, or Javascript, or tooling, it's Enterprise IT hiring inexperienced or unqualified engineers, often consultants, some of whom don't have degrees in engineering/CS, or are from body shops. Once enterprise switches most of the legacy systems from Java or Ruby to Node, you're going to find exactly the same people writing horrible code. You can already start to see it in the Node ecosystem, and in Kubernetes (go ecosystem), with people piling high on dependencies and frameworks, layer upon layer, of new-fangled tools and magic that will solve your enterprise problems, but what it ends up doing is creating a brittle system of crushing complexity and bloat and silos of IT department people who have narrow specific skills as opposed to general purpose engineering skills. The big tech companies in the valley don't look for candidates who have acronyms on their resumes "Java/Javascript/SQL/noSQL/RDBMS/J2EE/XML/SOAP/...." or professional training certifications, they look for people with general purpose engineering skills who can learn any language needed, and who generally adhere to good practices and habits. Back in the 90s, I taught retraining courses to enterprise and government workers. Many of them had never done coding before outside some basic Office or Lotus Notes scripting, and some of them were former COBOL users. A lot of them were reading books like "Perl, CGI in 21 days" or "Java in 21 days". And that's the problem, because the proper way to retrain your employees isn't to send them for a crash course. It's to hire some very good engineers and engineering managers, and let them learn as apprentices having their code reviewed by them. I don't want to bash all enterprise developers, there are some excellent companies out there doing good work. But my general impression from years of cleaning up messes I encountered in consulting, is that corporate IT departments don't care about things like code health or tech debt. This isn't a Java specific problem, it was there with COBOL, and it's there with Ruby, and it'll be there with Node. It's just whatever is Enterprise's favorite fad du jour will eventually be given a bad rep. If enterprise was using Haskell, even Haskell code would come out with a bad rep. :)

shooptake 8y ago
To be fair, plenty of Googlers/Xooglers/other Faang alumni produce hot garbage as well. Sure, on average you might have better code, but that doesn’t mean its good.