3 ms·

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 an

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.

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.