4 ms·

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

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.

pron 7y ago
Then I don't understand your point. You think less of a language that has managed to scale software both in size and in time than languages that have not? On what metrics and based on what data would you think they are better? Also, I've been in this business for about 25 years now, and I have never seen a correlation between obsessing about code concepts and success. Those who tend to be more successful care about requirements, design, algorithm, and observability more than about lambdas or verbs vs. nouns. It is difficult to understate the importance of those things compared to most other software concerns. I'll take a programmer who is eager to understand what the customer actually needs or how to make a system observable or performant over one that can grasp higher-order subroutines any day.
- BlargMcLarg 7y ago
  If you don't understand, please don't make assumptions. Java itself is fine. The progress Java is making, is also fine. I'm sure you could give Java, Python, Ruby, C#, Javascript to a group of newbie programmers each, and satisfaction would be similar. The problem comes from a mental perspective combined with the problems of enterprise. If I use Java at home, I'll learn all these cool features that I have to push through 3, maybe 4 layers of management before I can use it at work. It'd just agitate me not being able to do it in the language I'm using at that point. I had the same issue with Unity, where I couldn't use half the features of modern C# because Unity Engine was still on C# 2.0 or something, but at least there I personally opted to use Unity. Besides that, I'm just not a fan of Java on a personal level. >I have never seen a correlation between obsessing about code concepts and success. Those who tend to be more successful care about requirements, design, algorithm, and observability more than about lambdas or verbs vs. nouns. It is difficult to understate the importance of those things compared to most other software concerns. These aren't mutual exclusive and frankly, dragging this into the discussion is a bit of a low blow. Yes, ultimately, what matters is the product and its future maintainability. What isn't trivial is deciding whether to introduce a system where a bug may be hidden in 3 layers of reflection, 5 layers of abstraction and requires you to read hundreds of lines only to understand what is going on, much less why, because everything is written 2-3 times (in code, in comments and sometimes even something else). Spending hours because Bob's great plan was to introduce another if-else statement, now nested 3-deep, inside a try-catch block, and you have no clue where the value was assigned anymore. That same thing happened at the place I work at now. They focused on immediate results more than long term code maintenance. They got amazing success. Now they have a massive technical debt, and people have trouble understanding what the code was supposed to do. No fancy tricks, no interesting algorithms or one-liners. Just old, verbose, imperative / OO Java code to power forms. The simplest of data manipulation. In the end, these things still end up at the skilled seniors anyway, because the juniors don't understand, the mediors don't have the required domain knowledge and everyone else doesn't have the skill to comprehend what is going on. And frankly, I have managers and deadlines to keep me from spending too much time. So far, those guys haven't complained, despite thinking about ways that the codebase could be improved.

pron 7y ago

Then I don't understand your point. You think less of a language that has managed to scale software both in size and in time than languages that have not? On what metrics and based on what data would you think they are better? Also, I've been in this business for about 25 years now, and I have never seen a correlation between obsessing about code concepts and success. Those who tend to be more successful care about requirements, design, algorithm, and observability more than about lambdas or verbs vs. nouns. It is difficult to understate the importance of those things compared to most other software concerns. I'll take a programmer who is eager to understand what the customer actually needs or how to make a system observable or performant over one that can grasp higher-order subroutines any day.

BlargMcLarg 7y ago
If you don't understand, please don't make assumptions. Java itself is fine. The progress Java is making, is also fine. I'm sure you could give Java, Python, Ruby, C#, Javascript to a group of newbie programmers each, and satisfaction would be similar. The problem comes from a mental perspective combined with the problems of enterprise. If I use Java at home, I'll learn all these cool features that I have to push through 3, maybe 4 layers of management before I can use it at work. It'd just agitate me not being able to do it in the language I'm using at that point. I had the same issue with Unity, where I couldn't use half the features of modern C# because Unity Engine was still on C# 2.0 or something, but at least there I personally opted to use Unity. Besides that, I'm just not a fan of Java on a personal level. >I have never seen a correlation between obsessing about code concepts and success. Those who tend to be more successful care about requirements, design, algorithm, and observability more than about lambdas or verbs vs. nouns. It is difficult to understate the importance of those things compared to most other software concerns. These aren't mutual exclusive and frankly, dragging this into the discussion is a bit of a low blow. Yes, ultimately, what matters is the product and its future maintainability. What isn't trivial is deciding whether to introduce a system where a bug may be hidden in 3 layers of reflection, 5 layers of abstraction and requires you to read hundreds of lines only to understand what is going on, much less why, because everything is written 2-3 times (in code, in comments and sometimes even something else). Spending hours because Bob's great plan was to introduce another if-else statement, now nested 3-deep, inside a try-catch block, and you have no clue where the value was assigned anymore. That same thing happened at the place I work at now. They focused on immediate results more than long term code maintenance. They got amazing success. Now they have a massive technical debt, and people have trouble understanding what the code was supposed to do. No fancy tricks, no interesting algorithms or one-liners. Just old, verbose, imperative / OO Java code to power forms. The simplest of data manipulation. In the end, these things still end up at the skilled seniors anyway, because the juniors don't understand, the mediors don't have the required domain knowledge and everyone else doesn't have the skill to comprehend what is going on. And frankly, I have managers and deadlines to keep me from spending too much time. So far, those guys haven't complained, despite thinking about ways that the codebase could be improved.