With respect to hiring, I would say this is one of those things interviewers fail to analyze. When we look for technical prowess and attitude/behavior, the truth is those things are never expressed in the code base. Mental models, however, are exactly what is expressed in the code base. We are interviewing people and trying to see where on the normal distribution they land on the pure technical level, experience, and attitude, but rarely do those three things have an outsized impact on a generic codebase.
Instead, if you pull up someone’s GitHub and see wonderfully over abstracted code, boom, there’s your guy who is not in the middle of the normal distribution. In other words, they don’t write common code (which means they don’t write clearly, or with common sense, and certainly do not write simply).
Soon as you introduce someone like that into a code base, suddenly things that used to be simple are physically painful to touch. Jumping through files, following the wire to see where it leads, layers of abstraction, and so on. That is a codebase terrorist and one interviews for it. The fact that the entire team must now take on the mental model and enter the headspace of such a person is exhausting.
Hire commoners, and test for obtuse mental models (something that is easily missed in an isolated coding challenge and no way visible in the behavioral portion. But alas, this will fuck with your whole team more than anything else).
The problem with what you're saying is that it's meaningless without concrete examples?
What is "over abstracted code"? Perhaps we agree on this point, but I don't know because when people talk about these things no one has any idea of what they mean - we use "over-testing", "under-testing", "over-engineered", "sloppy", "too much abstraction", "simplicity", "complexity", and everyone has different takes on what these words mean but everyone agrees they're bad or good. It's a bit non-sensical.
What is the problem of jumping through files? Do you feel the same about jumping through functions? Is it better to have a soup that you can only test by setting up a new solar system? Is that why testing is considered "expensive"? And what is the solution when products need to be evolved, redesigned or pivoted? Re-write? Re-hire a team? Do the same crap again but with new tools? No tests? Or you simply don't like jumping?
Is it worth it to have bad api's, bad products, that offset millions of hours in work around to all developers (and non-developers as well) who have to use them because someone couldn't be bothered? Shouldn't the premium on salaries for developers conjure some real interest in doing things right? Is it normal that governmental institutions, public companies, banks, etc have awful interfaces, buggy behaviour, etc?
Isn't it normal that if you're commanding a very comfortable salary there should be an expectation of continuous improvement, research and learning for the work you choose to do?
Perhaps I agree with what you're saying, or perhaps I completely oppose it, but I can't tell.
This is why I don’t share my GitHub profile during the hiring process. Code is just too easy to criticize.
Write a 1 liner? Too terse and hard to understand.
Use multiple lines? Too verbose.
I don’t want to give the people who are going to be deciding my future a target to pick on. It only takes one guy to feel insecure about hiring me to say something like “he over abstracts his code”.
The only things I share are the finished products, it keeps the nitpickers quiet.
I will respond to the other comment in a second, but the things you are concerned with are not what I am advocating. The nit picky stuff doesn’t expose one’s mental model. It exposes some modicum of taste.
What I’m advocating is to probe how people structure the problem. There is a noticeable percentage of people that manage to have technical competence but map problems in a complicated way.
Instead, if you pull up someone’s GitHub and see wonderfully over abstracted code, boom, there’s your guy who is not in the middle of the normal distribution. In other words, they don’t write common code (which means they don’t write clearly, or with common sense, and certainly do not write simply).
Soon as you introduce someone like that into a code base, suddenly things that used to be simple are physically painful to touch. Jumping through files, following the wire to see where it leads, layers of abstraction, and so on. That is a codebase terrorist and one interviews for it. The fact that the entire team must now take on the mental model and enter the headspace of such a person is exhausting.
Hire commoners, and test for obtuse mental models (something that is easily missed in an isolated coding challenge and no way visible in the behavioral portion. But alas, this will fuck with your whole team more than anything else).