[3036e4]

Sorry, but I don't think a preference for slow evolution is always because of laziness. What's wrong with wanting to keep improving on a skill instead of having to waste time relearning things every six months?

Software is rare among arts/crafts/whatever in that it is difficult to find nice areas of software to keep digging deeper into (as curious people do!) rather than having to move on to something new just when you start to be good something.

It's not even wanting to focus on depth instead of breadth, as the constant changes means you are barely able to keep using your older skills, so there is little actual breadth more like constantly moving between shallow pools of knowledge. Maybe it feels great to constantly be moving, but I do not see how it is productive or positive in any way for us.

[tombert]

I am arguing that they aren’t improving their skills in any regard, including how to properly use the tools they already pretend to know. They don’t go “deep” or “broad”, they don’t learn anything more than what they were taught in university.

I have had to debug a lot of concurrent Java, so my opinions are skewed towards that, but I have seen cases where “staff engineers” label every single function as `synchronized`, who genuinely don’t know why you would use a queue, have no concept of thread starvation or fairness, when to use an atomic instead of a mutex, and genuinely do not seem to understand that for network applications it’s generally more important to figure out how to reduce latency than trying to choose the optimal hashmap or sort implementation. These aren’t arcane details that require a PhD in category theory or require being constantly plugged into hacker news, these are extremely basic things that these Java engineers do not know.

I think most Java engineers, like more professionals in general, are very bad at their jobs. I think Java just selection-biases higher than other languages for people who are bad at their jobs.