4 ms·

> I would not ever want to work with anyone from those types of teams. They are the kind of programmers who have a very narrow range of abilities, and whenever

by _pmf_ 5y ago

> I would not ever want to work with anyone from those types of teams. They are the kind of programmers who have a very narrow range of abilities, and whenever they see a problem outside those abilities, they get completely lost. The thing is, they are the ones least likely to cause difficult to debug build issues due to "very clever" features and using the latest version features of build tools in the first place.

marcellus23 5y ago
It’s true that clever code can only be written by knowledgeable engineers, but that doesn’t mean that knowledgeable engineers all write clever code.
kelnos 5y ago
They're also the kinds of people who will use the same version of their tools long after they've stopped being supported, and then when you need one of those new features, or run into a problem that you can't work around, you have to drag all that stuff into the present, which is always a huge pain in the ass. And the kind of developers who got you in that situation in the first place will be the least well-suited to help get you out. Regardless, I don't think "I don't want knowledgeable people because they might write something 'too clever' that causes problems in the future" is a particularly winning strategy. You're basically saying you want dumb people because they will never try to be too smart for their own good.
jdbernard 5y ago
They are absolutely the ones to create hard-to-debug issues because they layered a whole bunch of complex things incorrectly or unknowingly. For example, recently I spent more time than I'd like finding out that we linked two incompatible versions of a library. All the visible dependencies were correct, but at some point someone bundled an old version in a fat jar and that got included transitively via another dependency. If you understand the details you know why you don't distribute libraries as fat jars. But if you're just following some guide it's easier to fat jar it than correctly specify your dependency tree. If your education was really effective you recognize this is just the static/dynamic linking problem again in new clothes.

by _pmf_ 5y ago

marcellus23 5y ago

It’s true that clever code can only be written by knowledgeable engineers, but that doesn’t mean that knowledgeable engineers all write clever code.

kelnos 5y ago

They're also the kinds of people who will use the same version of their tools long after they've stopped being supported, and then when you need one of those new features, or run into a problem that you can't work around, you have to drag all that stuff into the present, which is always a huge pain in the ass. And the kind of developers who got you in that situation in the first place will be the least well-suited to help get you out. Regardless, I don't think "I don't want knowledgeable people because they might write something 'too clever' that causes problems in the future" is a particularly winning strategy. You're basically saying you want dumb people because they will never try to be too smart for their own good.

jdbernard 5y ago

They are absolutely the ones to create hard-to-debug issues because they layered a whole bunch of complex things incorrectly or unknowingly. For example, recently I spent more time than I'd like finding out that we linked two incompatible versions of a library. All the visible dependencies were correct, but at some point someone bundled an old version in a fat jar and that got included transitively via another dependency. If you understand the details you know why you don't distribute libraries as fat jars. But if you're just following some guide it's easier to fat jar it than correctly specify your dependency tree. If your education was really effective you recognize this is just the static/dynamic linking problem again in new clothes.