7 ms·

Unfortunately, many of us tend to run into the 99% of professional Java devs still stuck in the old, almost meme-level culture of pre-Java 8, where: * var is a

Unfortunately, many of us tend to run into the 99% of professional Java devs still stuck in the old, almost meme-level culture of pre-Java 8, where: * var is a sin (if the Java version is even high enough to utilize it) * Methods frequently have 3 arguments by default * Getters and setters are nigh-on useless and verbose, existing primarily because one doesn't trust the coder next to him * Names are atrociously long and laid out in a way auto-complete helps zilch (25+-char names are not uncommon even for local variables) * Methodology is still primarily stuck in its old GoF OOP AbstractCreatorFactoryFactory ways Java is doing good and making leaps to improve. I can't say the same for the culture, which is mostly due to it attracting tons of people who have no innate skill or desire to learn programming, mostly there to occupy a job that pays decently well and make zero effort to improve. Or worse, it used to attract those kinds of people, who now occupy senior/principal/lead positions and enforce the old way of programming under the guise of "consistency" (Consistency is important, but using it as an excuse to not adapt is simple abuse). That attitude is a lot less prevalent in Haskell communities, where the environment itself preselects for programmers with an innate interest.

hocuspocus 7y ago
Sometimes I wonder where the blame truly lies. Is it complacent developers? Or a decade of bad practices encouraged by big frameworks? Probably a bit of both and now we have a vicious circle. Unfortunately, there's real demand for poor software quality in our industry, for good and bad reasons. I moved to Scala as my main language on the job because I wanted to make sure I'd work with coworkers who are open to adapt and learn new things. But I cannot deny the churn has a real cost if you aren't careful.
- pjmlp 7y ago
  I used to think that would be the case, then I became aware of a couple of Scala projects delivered by Wipro.
- pron 7y ago
  I think the blame lies with those who fail to understand that you cannot compare the "culture" of an ecosystem the size of a university with the "culture" of an ecosystem the size of the country that contains it, and several others like it. Go to a Java shop that does robot control, sensor fusion, simulation, formal methods or spacecraft orbits, and I guarantee you that you'll find coworkers that are open to adapt and learn new things, things that are probably far more important, and interesting, than typeclasses and lenses.
  - hocuspocus 7y ago
    Surely, but I'm not in these fields. And it's like screening and interviewing candidates: I need to pick proxy metrics when I evaluate employers.
- BlargMcLarg 7y ago
  Its probably a bit of both, along with demand and financial pressure. I can at least give you following anecdote regarding where I work now. * We used to have rules that all code had to be written comment-first. I'd wager part of the reason was to mitigate language deficiencies (dominant language was not English, nor were the comments). Part of it was a misguided attempt to make things more clear without realizing the noise will quickly fill your brain. Comments included "if x is not null, do methodA. Otherwise, do methodB". Stuff like this should be obvious from the code, or your code is written poorly. We're not talking clever one-liners, either. * Most devs here don't care for coding outside the job. They are here to earn money, and a coding job is relatively easy on the body and easy to hold as long as you seem productive. I'm fairly certain this is also the default attitude of most employed software devs. * Complacent developers get promoted to roles where they no longer code, but still have significant influence over the code style. They don't get to experience the negatives any longer, and they won't see the benefits of change. This repeats every generation until you get lucky and enough developers move into senior roles, make a statement to change things around, aggressively push to achieve this and as a result, the culture within the company changes. Most developers care for a few years, until some kind of Stockholm syndrome kicks in where they no longer care, and even believe its for the better. Might as well be zombies. I've had seniors at the company for longer than myself (medior) ask me things that, for all intents and purposes, they should know. Instead, they spent a week resolving the issue I resolved in a few hours myself, even with instructions and guidance. * Java is relatively easy to get people productive in, as long as you don't have complex equations or mathematical concepts. As a result, we have tons of people employed that I wouldn't trust with making a big feature in my life. They get bite-sized features, super-accurately defined, after a few years of development, with thorough manual review and guidance. We don't make them manage dependencies. We don't make them set up applications from scratch. They only fill little pieces of what might as well be templates. They are something along the lines of code monkeys and human-Java code translators at best. The majority of these people might not even be able to write Fizzbuzz from scratch after a few years. Its crude and sounds dismissive, but they really are that bad of programmer material. It doesn't click, and it just won't click after a few years either. The same problem happens when you make your programming more math-like, even something as simple as making functions variables. They won't grasp it, and they now fail to understand the code. On the flipside, they believe a design pattern is some galaxy-brain concept. * Most work on the market is boring, repetitive, enterprise-laden, web-focused CRUD. There is very little interesting stuff, and the competition for these jobs is extremely fierce to the point some of them pay worse despite the requirements being much tougher (Gamedev comes to mind). It isn't just Java that suffers from this, but the aforementioned points along with Java's history doesn't help here, either. I'm sure C# has similar problems, though LINQ and EF alleviate a lot of this. Can't speak for other languages. Unfortunately, money talks. * With managers mostly looking no further than next month, there is little time to innovate, and thus automate, procedures that could be automated. This process continues ad-infinitum. So if there's a need to match deadlines, instead, we hire code monkeys who don't complain. Again, money talks. And I'll admit, part of it is enterprise, not just Java. But I don't use Java at home, and most job offers are, unfortunately for me, still Java (or C#, and I doubt enterprise .NET is much better). Disclaimer: Yes, I'm extremely jaded after having bureaucracy, recruiters and the entire job interview process suck out most of the fun for me. Yes, this is largely my own anecdote.
pron 7y ago
There is no one Java culture. It's impossible in a community of that size and it is indicative of maturity and success. If you spend your time in Cambridge, MA you get a very different view of "American culture" than you would if you spent your time in, say, Tampa, FL, and there are many more people in environments similar to the latter. It just doesn't make any sense to talk of a particular culture when the ecosystem is so big. There are small, perhaps hidden, niches of Java with their own culture that are ten times bigger than the entire Haskell community. Of course, if you pick a place at random you're more likely to hit a Tampa than a Cambridge. As someone who occasionally attends Haskell meetups I also very much disagree with your characterization of that community. I've seen people so bored out of their minds with the actual software they're writing that they spend their "interest" on language arcana and their time on re-writing bubble-sort using Free. Not to mention that it's hard to say anything about long term code practices in Haskell, because the number of large-scale projects, maintained over years by a changing group of people is vanishingly small, certainly too small to say anything about. For all we know, the practices employed by the average Haskeller are worse than those employed by the average Java programmer for long-lived software. The cries of anguish from companies with "legacy" Scala software (i.e. >7y.o.) that they struggle to maintain tell us that this is almost certainly the case when it comes to Scala developers. There are worse things, apparently, than useless getters and three-argument methods.
- BlargMcLarg 7y ago
  You say it doesn't make sense. I raise to you, enterprise software. To be a little more pedantic, yes, you are correct. There is no "the" culture. There are a variety of cultures. My hypothesis is there is a predominant culture within Java itself, closely tied to the premise of making software developers as cheap and risk-free as possible. Java made it incredibly easy to at least have a net gain on productivity compared to its competitors at the time, along with the other benefits it has always touted ("free", write once). This attracted tons of people who would at best be average programmers, settling in said enterprise companies, and slowly got promoted all the way to the top. Those people all spent years on the basic OOP/design-patterns/noun-based methods-style programming, which produced the atrocities of AbstractFactoryFactory patterns people dread to hear, and are now actively fighting changes. Partially because, justifiably, they are afraid the code requires a higher skill level to understand than the average guy on the local market has. Partially because they are so far from the nitty-bitty code process, they only do code review, make architecture designs or have technical discussions and analysis taking up the majority of their time. Partially, because that's the way they learned it, and people are stubborn and set in their ways. In turn, the next generation may be tutored to be just the same, the big money is still being paid, and nothing changes because "this is the way we did it, this is the way we guarantee money, so this is the way we will continue to do it", or progress goes at a snail's pace. Not only is there a lack of financial incentive, you're fighting the existing, pre-dominant culture and still trying to make things easy to understand for certain types of people. At the very least, I see this attitude a lot in Europe. Emphasis on memorizing / knowing concepts that, in reality, aren't that hard (e.g. design patterns, micro services, dependency injection), to the point where we even have internal recruiters reject you for not citing keywords from the dictionary or knowing itty-bitty details about Java which you'll never see in practice. Loads of people with zero programming affinity coming into an enterprise job, often Java, after a short bootcamp. Most of these guys wouldn't begin to imagine the idea of a function being treated like a variable, or the concept of lambda functions. And frankly, I just can't get myself to care for differentiating between Java sub-cultures at that point. If I spent time in them outside work, I'd just get annoyed not being able to use those cool, productive features at work, spend weeks searching for a job I'm unlikely to get just to go back to writing ancient Java code again for Bob to understand because he can't grasp var. If I don't, my only exposure is the Java culture at enterprises, which is likely to be the same given the statement of the parent of my first comment (your comment). Damned if you do, damned if you don't.
hibbelig 7y ago
I’m stuck in that old culture. I want to get out. Any advice? Books? Articles? Blogs?
- dunefox 7y ago
  Low hanging fruit would be to learn Kotlin.

hocuspocus 7y ago

Sometimes I wonder where the blame truly lies. Is it complacent developers? Or a decade of bad practices encouraged by big frameworks? Probably a bit of both and now we have a vicious circle. Unfortunately, there's real demand for poor software quality in our industry, for good and bad reasons. I moved to Scala as my main language on the job because I wanted to make sure I'd work with coworkers who are open to adapt and learn new things. But I cannot deny the churn has a real cost if you aren't careful.

pjmlp 7y ago
I used to think that would be the case, then I became aware of a couple of Scala projects delivered by Wipro.
pron 7y ago
I think the blame lies with those who fail to understand that you cannot compare the "culture" of an ecosystem the size of a university with the "culture" of an ecosystem the size of the country that contains it, and several others like it. Go to a Java shop that does robot control, sensor fusion, simulation, formal methods or spacecraft orbits, and I guarantee you that you'll find coworkers that are open to adapt and learn new things, things that are probably far more important, and interesting, than typeclasses and lenses.
- hocuspocus 7y ago
  Surely, but I'm not in these fields. And it's like screening and interviewing candidates: I need to pick proxy metrics when I evaluate employers.
BlargMcLarg 7y ago
Its probably a bit of both, along with demand and financial pressure. I can at least give you following anecdote regarding where I work now. * We used to have rules that all code had to be written comment-first. I'd wager part of the reason was to mitigate language deficiencies (dominant language was not English, nor were the comments). Part of it was a misguided attempt to make things more clear without realizing the noise will quickly fill your brain. Comments included "if x is not null, do methodA. Otherwise, do methodB". Stuff like this should be obvious from the code, or your code is written poorly. We're not talking clever one-liners, either. * Most devs here don't care for coding outside the job. They are here to earn money, and a coding job is relatively easy on the body and easy to hold as long as you seem productive. I'm fairly certain this is also the default attitude of most employed software devs. * Complacent developers get promoted to roles where they no longer code, but still have significant influence over the code style. They don't get to experience the negatives any longer, and they won't see the benefits of change. This repeats every generation until you get lucky and enough developers move into senior roles, make a statement to change things around, aggressively push to achieve this and as a result, the culture within the company changes. Most developers care for a few years, until some kind of Stockholm syndrome kicks in where they no longer care, and even believe its for the better. Might as well be zombies. I've had seniors at the company for longer than myself (medior) ask me things that, for all intents and purposes, they should know. Instead, they spent a week resolving the issue I resolved in a few hours myself, even with instructions and guidance. * Java is relatively easy to get people productive in, as long as you don't have complex equations or mathematical concepts. As a result, we have tons of people employed that I wouldn't trust with making a big feature in my life. They get bite-sized features, super-accurately defined, after a few years of development, with thorough manual review and guidance. We don't make them manage dependencies. We don't make them set up applications from scratch. They only fill little pieces of what might as well be templates. They are something along the lines of code monkeys and human-Java code translators at best. The majority of these people might not even be able to write Fizzbuzz from scratch after a few years. Its crude and sounds dismissive, but they really are that bad of programmer material. It doesn't click, and it just won't click after a few years either. The same problem happens when you make your programming more math-like, even something as simple as making functions variables. They won't grasp it, and they now fail to understand the code. On the flipside, they believe a design pattern is some galaxy-brain concept. * Most work on the market is boring, repetitive, enterprise-laden, web-focused CRUD. There is very little interesting stuff, and the competition for these jobs is extremely fierce to the point some of them pay worse despite the requirements being much tougher (Gamedev comes to mind). It isn't just Java that suffers from this, but the aforementioned points along with Java's history doesn't help here, either. I'm sure C# has similar problems, though LINQ and EF alleviate a lot of this. Can't speak for other languages. Unfortunately, money talks. * With managers mostly looking no further than next month, there is little time to innovate, and thus automate, procedures that could be automated. This process continues ad-infinitum. So if there's a need to match deadlines, instead, we hire code monkeys who don't complain. Again, money talks. And I'll admit, part of it is enterprise, not just Java. But I don't use Java at home, and most job offers are, unfortunately for me, still Java (or C#, and I doubt enterprise .NET is much better). Disclaimer: Yes, I'm extremely jaded after having bureaucracy, recruiters and the entire job interview process suck out most of the fun for me. Yes, this is largely my own anecdote.

pron 7y ago

There is no one Java culture. It's impossible in a community of that size and it is indicative of maturity and success. If you spend your time in Cambridge, MA you get a very different view of "American culture" than you would if you spent your time in, say, Tampa, FL, and there are many more people in environments similar to the latter. It just doesn't make any sense to talk of a particular culture when the ecosystem is so big. There are small, perhaps hidden, niches of Java with their own culture that are ten times bigger than the entire Haskell community. Of course, if you pick a place at random you're more likely to hit a Tampa than a Cambridge. As someone who occasionally attends Haskell meetups I also very much disagree with your characterization of that community. I've seen people so bored out of their minds with the actual software they're writing that they spend their "interest" on language arcana and their time on re-writing bubble-sort using Free. Not to mention that it's hard to say anything about long term code practices in Haskell, because the number of large-scale projects, maintained over years by a changing group of people is vanishingly small, certainly too small to say anything about. For all we know, the practices employed by the average Haskeller are worse than those employed by the average Java programmer for long-lived software. The cries of anguish from companies with "legacy" Scala software (i.e. >7y.o.) that they struggle to maintain tell us that this is almost certainly the case when it comes to Scala developers. There are worse things, apparently, than useless getters and three-argument methods.

BlargMcLarg 7y ago
You say it doesn't make sense. I raise to you, enterprise software. To be a little more pedantic, yes, you are correct. There is no "the" culture. There are a variety of cultures. My hypothesis is there is a predominant culture within Java itself, closely tied to the premise of making software developers as cheap and risk-free as possible. Java made it incredibly easy to at least have a net gain on productivity compared to its competitors at the time, along with the other benefits it has always touted ("free", write once). This attracted tons of people who would at best be average programmers, settling in said enterprise companies, and slowly got promoted all the way to the top. Those people all spent years on the basic OOP/design-patterns/noun-based methods-style programming, which produced the atrocities of AbstractFactoryFactory patterns people dread to hear, and are now actively fighting changes. Partially because, justifiably, they are afraid the code requires a higher skill level to understand than the average guy on the local market has. Partially because they are so far from the nitty-bitty code process, they only do code review, make architecture designs or have technical discussions and analysis taking up the majority of their time. Partially, because that's the way they learned it, and people are stubborn and set in their ways. In turn, the next generation may be tutored to be just the same, the big money is still being paid, and nothing changes because "this is the way we did it, this is the way we guarantee money, so this is the way we will continue to do it", or progress goes at a snail's pace. Not only is there a lack of financial incentive, you're fighting the existing, pre-dominant culture and still trying to make things easy to understand for certain types of people. At the very least, I see this attitude a lot in Europe. Emphasis on memorizing / knowing concepts that, in reality, aren't that hard (e.g. design patterns, micro services, dependency injection), to the point where we even have internal recruiters reject you for not citing keywords from the dictionary or knowing itty-bitty details about Java which you'll never see in practice. Loads of people with zero programming affinity coming into an enterprise job, often Java, after a short bootcamp. Most of these guys wouldn't begin to imagine the idea of a function being treated like a variable, or the concept of lambda functions. And frankly, I just can't get myself to care for differentiating between Java sub-cultures at that point. If I spent time in them outside work, I'd just get annoyed not being able to use those cool, productive features at work, spend weeks searching for a job I'm unlikely to get just to go back to writing ancient Java code again for Bob to understand because he can't grasp var. If I don't, my only exposure is the Java culture at enterprises, which is likely to be the same given the statement of the parent of my first comment (your comment). Damned if you do, damned if you don't.

hibbelig 7y ago

I’m stuck in that old culture. I want to get out. Any advice? Books? Articles? Blogs?

dunefox 7y ago
Low hanging fruit would be to learn Kotlin.