8 ms·

It's hard to imagine someone who wouldn't be turned off by the tone of this article. Kicker is the quote at the end: "If you are in a typical enterprise then ma

by tacos 12y ago

It's hard to imagine someone who wouldn't be turned off by the tone of this article. Kicker is the quote at the end: "If you are in a typical enterprise then maybe you are lucky and already doing most of this." I went looking for sarcasm twice and still couldn't find it. Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. Nor are they "mocking" amazon web services for ease of local developer testing. And a request to your boss to write the next services layer in "Kotlin" is likely to be met with the slap it deserves.

VieElm 12y ago
In which case find a new job. I don't understand why people stick with these hell holes for engineers when there are many opportunities to be found elsewhere. You can even find remote work so even if you're stuck in a small town with only one Java employer and you have a family and can't move you can still find that dream remote job with modern tooling and practices. If you apply to these remote jobs but aren't getting hired, that's a solvable problem too. Keep trying to learn more, self-improving and keep applying.
- SomeCallMeTim 12y ago
  > Keep trying to learn more, self-improving and keep applying. I think it's worthwhile to add "improve your job application strategy" to that list. There was just an article on the how bad resumes are at predicting success; the converse is that you can likely improve your resume if you're not getting offers. And write a cover letter. Probably one in 20 (or maybe one in a hundred) resumes come in with a cover letter. And make it relevant. Talk about what the company does and how you'd be a good fit. Paraphrase their requirements list as a list of your strengths, and explain how things you don't know can be overcome. When I do this I have almost always gotten an interview. [1] And when I get an interview I almost always get an offer. [2] The other strategy that works for me is to network. Go to MeetUps relevant to your field and interact with people. I don't care if you're an introvert; I am too. It's hard. But do it. It's worth it. Right now I have a remote job that pays well where I was recommended by a friend who I met because I was networking. [1] The only exception for me was the months following 9/11, when no one was hiring because the whole nation was in shock. [2] I really recommend "Cracking the Coding Interview" by Gayle Laakmann McDowell; if you can answer all of the questions relevant to your field, you should be golden.
  - ZoFreX 12y ago
    Solid advice, but I have a question for you that's always been in my "too embarassed to ask" category: When you say cover letter, do you mean you attach a cover letter to the email as well as the CV, or does the email itself serve as the cover letter?
    - njs12345 12y ago
      The email serves at the cover letter, in my experience
    - SomeCallMeTim 12y ago
      You can go either way. It's more likely that they'll print a cover letter to go along with the resume if you attach it as a separate PDF, though. They might just ignore the email and print the resume, otherwise.
  - BerislavLopac 12y ago
    In all honesty, if a company rejects me for a lack of a cover letter, I'd rather not work there.
    - SomeCallMeTim 12y ago
      The point of adding a cover letter is to stand out. If you don't, you're far more likely to end up ignored in the avalanche of resumes, especially considering how poor of a signal most resumes are. I'd rather have a chance to actually get the job, if it's one I'd find interesting, and writing a cover letter is easy. But you're free to be ignored if it makes you feel better.
      - BerislavLopac 12y ago
        I see your point, but it depends on the circumstances. I actually have a job, and get contacted by recruiters several times a week, so I can be picky.
rgbrgb 12y ago
I have been an enterprise Java dev. Of the things you mention us not doing, we did about half. We mocked external services for unit tests, used git, and did 2 week sprints. My boss had no say on the programming language we wrote services in, I just would have had to convince the rest of my dev team. I doubt that it looks very different at Google or other suitably modern enterprise Java companies. Enterprise doesn't mean shit, it means big.
- emcrazyone 12y ago
  I guess define Enterprise. The OS experience doesn't sound like "Enterprise" to me. Just install the JDK? Most enterprises I worked at, it was more like install WebSphere and it's clients. I did hardly any of these things and I worked at a Fortune-5 company for close to 10 years on a mix of technologies; java being one. Much of the Java there was of the IBM variety. We had WebSphere and their over priced crap. As an insider, many of the DEVs preferred C#. I think much of this had to do with the better development tooling: Visual Studio vs. IBM's version of Eclipse and its infinite list of bolt on and buggy tools. My last 4-5 years there, just about all new apps. were going to C#/.NET platform. I was an insider in an architect role where one of my responsibilities was sitting on a board that oversaw every app. coming into our data center to make sure it followed best practices from language, tools, and general infrastructure stuff like Oracle vs. MS-SQL, SAN or local disk storage. One of our major areas of problems was JMX Message queues and prioritizing them across load balanced clusters of WebSphere servers. It was extremely clunky where as the .NET had better alternatives. Since we were an Enterprise (Fortune-5) by a reasonable definition, GIT and open source version control wasn't use. We use IBM Synergy which is another mess. My last year working there we actually did a trial using subversion which gained a lot of traction. Another problem for Enterprises is single sign on. Especially when you have tons of vendors who want to vet user credentials against our backends. We looked at SAML, WS-Federation, and how much vendor support there was. Like many others at the time, we came up with a kluge based on shared cookies so both our Java apps and .NET apps could work. Largely these standards are too lose to begin with too. Enterprises with deep pockets are hard to work with if your small OEM who can't afford the same financial commitment. In short, most "Enterprises" have a separate group of people who manage the development environment. You don't typically see DEVs setting these things up. We had standard loads for our developers to install and we had the same for our servers. Yea, there were occasions where we would install more JDKs and JREs to test to see if there was a bug or performance difference in the libraries but for the most part, none of the developers had to really mess with the dev environment or the version control stuff.
cmiles74 12y ago
We use JRebel on my team, everyone has a license. We do continuous depolyments and are coming to the end of our current two week sprint. We use Java 8 and are actively leveraging lambdas for code that is more readable. For sure, we are not doing everything mentioned but I think we're pretty progressive and, on the whole, have a healthy attitude towards learning new things. Not every job has to be as suffocating as your example.
throwway222 12y ago
I work in a Enterprise Java shop in the midwest that employs 35k+, of which 5k+ are software engineers. We have 2 weeks sprints, daily scrums, retro and IPMs. We maintain legacy code that has been in production for more than 8 years and write new fully unit and integration-tested code in Groovy/Grails, Ruby/Rails, Java, and Angular. We use the latest tools and machines (both Win and Mac, paired with Intelli J). And our servers are all virutalized. No physical servers under our desk.
jshen 12y ago
"Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. Nor are they "mocking" amazon web services for ease of local developer testing." We do all of these things (minus play framework and i don't know what reactive development is) where I work and we're in the fortune 500.
username223 12y ago
> ... reactive development... Was that sarcastic? A quick search turned up [1], which suggests it was. Or is "Chinese fire drill" an accepted development methodology these days? [1] http://c2.com/cgi/wiki/CeeTwoProject?ReactiveDevelopment http://c2.com/cgi/wiki/CeeTwoProject?ReactiveDevelopment
- vitalus 12y ago
  I think he's talking about reactive programming: http://en.wikipedia.org/wiki/Reactive_programming http://en.wikipedia.org/wiki/Reactive_programming
ripb 12y ago
>Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. This is plain wrong, as many have already pointed out. I would have thought that the audience here would have been smarter than to give upvotes to a very poor, ignorant generalization of those using the second most popular programming language [1] but then I suppose it is reflective of the massive circlejerk against Java that we tend to witness here. [1] http://langpop.com/ http://langpop.com/ >And a request to your boss to write the next services layer in "Kotlin" is likely to be met with the slap it deserves. If your "boss" can't stand a conversation surrounding a backed and reasoned suggestion then I feel very sorry for you for working in those conditions.
pron 12y ago
The following companies are Java shops (i.e. they use it for all/most/huge or very large part of their coding effort): Google, Amazon, IBM, Oracle, Twitter, Netflix, NASA, LinkedIn, Boeing, Raytheon, Twilio, Box and the list goes on and on and on. In fact, you'll be hard pressed to find companies working on large scale projects that don't use Java in any way (Microsoft, GitHub and Stack Exchange are notable examples -- there aren't too many more). Even Facebook, which isn't a Java shop, uses Java quite a lot for their analytics. Pretty much all air-traffic control and defense systems in the Western world are written in Java (those of them written in recent years). In fact, every piece of software you really rely on (probably without even knowing it), there's a very good chance it's written in Java. Hell, there's even embedded avionics software written in Java nowadays[1]. So you'll be surprised what many different kinds of tooling -- both modern, super-modern and less so -- is being used in Java shops. Some use hard realtime GCs, some use really advanced model checking (NASA has built an awesome Java model checker), and yeah, many use Git. And even if many of them don't -- the work they do is so important, that I could really care less whether their SCM is hip or not. [1]: http://www.atego.com/products/atego-perc/ http://www.atego.com/products/atego-perc/
- pkinsky 12y ago
  Twitter and LinkedIn are Scala shops, not Java shops.
  - cgh 12y ago
    I worked on a large Java application at LinkedIn so in my experience, LinkedIn is certainly not Scala-only.
  - pron 12y ago
    Twitter uses Java, too (and Clojure).
  - edwinnathaniel 12y ago
    LinkedIN main web-app is in Java.
  - jbooth 12y ago
cgh 12y ago
I'm in a 70,000+ person company ("enterprise") and we use most of the things in your list. My direct experience does not match your assumptions. And this is a company that is not considered leading-edge in softwawre development, believe me.

by tacos 12y ago

VieElm 12y ago

In which case find a new job. I don't understand why people stick with these hell holes for engineers when there are many opportunities to be found elsewhere. You can even find remote work so even if you're stuck in a small town with only one Java employer and you have a family and can't move you can still find that dream remote job with modern tooling and practices. If you apply to these remote jobs but aren't getting hired, that's a solvable problem too. Keep trying to learn more, self-improving and keep applying.

SomeCallMeTim 12y ago
> Keep trying to learn more, self-improving and keep applying. I think it's worthwhile to add "improve your job application strategy" to that list. There was just an article on the how bad resumes are at predicting success; the converse is that you can likely improve your resume if you're not getting offers. And write a cover letter. Probably one in 20 (or maybe one in a hundred) resumes come in with a cover letter. And make it relevant. Talk about what the company does and how you'd be a good fit. Paraphrase their requirements list as a list of your strengths, and explain how things you don't know can be overcome. When I do this I have almost always gotten an interview. [1] And when I get an interview I almost always get an offer. [2] The other strategy that works for me is to network. Go to MeetUps relevant to your field and interact with people. I don't care if you're an introvert; I am too. It's hard. But do it. It's worth it. Right now I have a remote job that pays well where I was recommended by a friend who I met because I was networking. [1] The only exception for me was the months following 9/11, when no one was hiring because the whole nation was in shock. [2] I really recommend "Cracking the Coding Interview" by Gayle Laakmann McDowell; if you can answer all of the questions relevant to your field, you should be golden.
- ZoFreX 12y ago
  Solid advice, but I have a question for you that's always been in my "too embarassed to ask" category: When you say cover letter, do you mean you attach a cover letter to the email as well as the CV, or does the email itself serve as the cover letter?
  - njs12345 12y ago
    The email serves at the cover letter, in my experience
  - SomeCallMeTim 12y ago
    You can go either way. It's more likely that they'll print a cover letter to go along with the resume if you attach it as a separate PDF, though. They might just ignore the email and print the resume, otherwise.
- BerislavLopac 12y ago
  In all honesty, if a company rejects me for a lack of a cover letter, I'd rather not work there.
  - SomeCallMeTim 12y ago
    The point of adding a cover letter is to stand out. If you don't, you're far more likely to end up ignored in the avalanche of resumes, especially considering how poor of a signal most resumes are. I'd rather have a chance to actually get the job, if it's one I'd find interesting, and writing a cover letter is easy. But you're free to be ignored if it makes you feel better.
    - BerislavLopac 12y ago
      I see your point, but it depends on the circumstances. I actually have a job, and get contacted by recruiters several times a week, so I can be picky.

rgbrgb 12y ago

I have been an enterprise Java dev. Of the things you mention us not doing, we did about half. We mocked external services for unit tests, used git, and did 2 week sprints. My boss had no say on the programming language we wrote services in, I just would have had to convince the rest of my dev team. I doubt that it looks very different at Google or other suitably modern enterprise Java companies. Enterprise doesn't mean shit, it means big.

emcrazyone 12y ago
I guess define Enterprise. The OS experience doesn't sound like "Enterprise" to me. Just install the JDK? Most enterprises I worked at, it was more like install WebSphere and it's clients. I did hardly any of these things and I worked at a Fortune-5 company for close to 10 years on a mix of technologies; java being one. Much of the Java there was of the IBM variety. We had WebSphere and their over priced crap. As an insider, many of the DEVs preferred C#. I think much of this had to do with the better development tooling: Visual Studio vs. IBM's version of Eclipse and its infinite list of bolt on and buggy tools. My last 4-5 years there, just about all new apps. were going to C#/.NET platform. I was an insider in an architect role where one of my responsibilities was sitting on a board that oversaw every app. coming into our data center to make sure it followed best practices from language, tools, and general infrastructure stuff like Oracle vs. MS-SQL, SAN or local disk storage. One of our major areas of problems was JMX Message queues and prioritizing them across load balanced clusters of WebSphere servers. It was extremely clunky where as the .NET had better alternatives. Since we were an Enterprise (Fortune-5) by a reasonable definition, GIT and open source version control wasn't use. We use IBM Synergy which is another mess. My last year working there we actually did a trial using subversion which gained a lot of traction. Another problem for Enterprises is single sign on. Especially when you have tons of vendors who want to vet user credentials against our backends. We looked at SAML, WS-Federation, and how much vendor support there was. Like many others at the time, we came up with a kluge based on shared cookies so both our Java apps and .NET apps could work. Largely these standards are too lose to begin with too. Enterprises with deep pockets are hard to work with if your small OEM who can't afford the same financial commitment. In short, most "Enterprises" have a separate group of people who manage the development environment. You don't typically see DEVs setting these things up. We had standard loads for our developers to install and we had the same for our servers. Yea, there were occasions where we would install more JDKs and JREs to test to see if there was a bug or performance difference in the libraries but for the most part, none of the developers had to really mess with the dev environment or the version control stuff.

cmiles74 12y ago

We use JRebel on my team, everyone has a license. We do continuous depolyments and are coming to the end of our current two week sprint. We use Java 8 and are actively leveraging lambdas for code that is more readable. For sure, we are not doing everything mentioned but I think we're pretty progressive and, on the whole, have a healthy attitude towards learning new things. Not every job has to be as suffocating as your example.

throwway222 12y ago

I work in a Enterprise Java shop in the midwest that employs 35k+, of which 5k+ are software engineers. We have 2 weeks sprints, daily scrums, retro and IPMs. We maintain legacy code that has been in production for more than 8 years and write new fully unit and integration-tested code in Groovy/Grails, Ruby/Rails, Java, and Angular. We use the latest tools and machines (both Win and Mac, paired with Intelli J). And our servers are all virutalized. No physical servers under our desk.

jshen 12y ago

"Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. Nor are they "mocking" amazon web services for ease of local developer testing." We do all of these things (minus play framework and i don't know what reactive development is) where I work and we're in the fortune 500.

username223 12y ago

> ... reactive development... Was that sarcastic? A quick search turned up [1], which suggests it was. Or is "Chinese fire drill" an accepted development methodology these days? [1] http://c2.com/cgi/wiki/CeeTwoProject?ReactiveDevelopment http://c2.com/cgi/wiki/CeeTwoProject?ReactiveDevelopment

vitalus 12y ago
I think he's talking about reactive programming: http://en.wikipedia.org/wiki/Reactive_programming http://en.wikipedia.org/wiki/Reactive_programming

ripb 12y ago

>Java enterprise shops are not using git and JRebel and Play Framework and continuous deployments and 2 week sprints and reactive development refactoring boilerplate into lambdas. This is plain wrong, as many have already pointed out. I would have thought that the audience here would have been smarter than to give upvotes to a very poor, ignorant generalization of those using the second most popular programming language [1] but then I suppose it is reflective of the massive circlejerk against Java that we tend to witness here. [1] http://langpop.com/ http://langpop.com/ >And a request to your boss to write the next services layer in "Kotlin" is likely to be met with the slap it deserves. If your "boss" can't stand a conversation surrounding a backed and reasoned suggestion then I feel very sorry for you for working in those conditions.

pron 12y ago

The following companies are Java shops (i.e. they use it for all/most/huge or very large part of their coding effort): Google, Amazon, IBM, Oracle, Twitter, Netflix, NASA, LinkedIn, Boeing, Raytheon, Twilio, Box and the list goes on and on and on. In fact, you'll be hard pressed to find companies working on large scale projects that don't use Java in any way (Microsoft, GitHub and Stack Exchange are notable examples -- there aren't too many more). Even Facebook, which isn't a Java shop, uses Java quite a lot for their analytics. Pretty much all air-traffic control and defense systems in the Western world are written in Java (those of them written in recent years). In fact, every piece of software you really rely on (probably without even knowing it), there's a very good chance it's written in Java. Hell, there's even embedded avionics software written in Java nowadays[1]. So you'll be surprised what many different kinds of tooling -- both modern, super-modern and less so -- is being used in Java shops. Some use hard realtime GCs, some use really advanced model checking (NASA has built an awesome Java model checker), and yeah, many use Git. And even if many of them don't -- the work they do is so important, that I could really care less whether their SCM is hip or not. [1]: http://www.atego.com/products/atego-perc/ http://www.atego.com/products/atego-perc/

pkinsky 12y ago
Twitter and LinkedIn are Scala shops, not Java shops.
- cgh 12y ago
  I worked on a large Java application at LinkedIn so in my experience, LinkedIn is certainly not Scala-only.
- pron 12y ago
  Twitter uses Java, too (and Clojure).
- edwinnathaniel 12y ago
  LinkedIN main web-app is in Java.
- jbooth 12y ago

cgh 12y ago

I'm in a 70,000+ person company ("enterprise") and we use most of the things in your list. My direct experience does not match your assumptions. And this is a company that is not considered leading-edge in softwawre development, believe me.