Ask HN: How do you train developer fundamentals?

I think code review is the way to do it, making sure you communicate the general principle rather than just the specific change.

I don’t think having a CS background makes any difference here, but I have found that some people pick this stuff up quickly and others don’t. Going forwards you should make sure you’re filtering for this as part of your hiring process.

I've had success with two techniques, though they require patience.

First is setting a few short, firm rules about the specific implementations in a project's code. For example, one of my commandments is, "Do not log from library classes that query the database." Its main purpose is to maintain separation of concerns, but its secondary purpose is to get developers to ask why.

The other is similar, just more general, and that is (in the absence of formal coding conventions) picking two or three minor, common coding mistakes and being a dictator about them: declaring a local variable that's only read once, returning true or false in an if-then-else block instead of returning the evaluated expression directly, that kind of thing. Look for them first in code reviews and require changes on the spot. It gets folks to slow down a little and consider what they're doing, which makes a lot of difference in the long term.

I'm going to add a code design course to: https://platform.intervee.io/courses

with challenges that very similar to the problems you described. But it will take a few weeks to be ready.

For your question: Maybe they undervalue a well design code because it's hard to be measured. At the end of the day, you judge them based on their tasks and not quality. Try to give them a motivation to think like architects. What would happen if you ask them to be reviewed by a team member, before pushing it to your review?

1) Devs doesn´t even need to think like architects. You (or the project manager, project owner, whatever) must provide a (good) specification.

2) You can also bring general standards into practice. But do not try to solve everything at once.

3) Leave code review comments on a helpful way. There are some good articles, how to mastering that.

4) Force they to refactor, and leave time for that. You can sit together with the developer, and refactor one part of his/her code. Next time sit together again, and let him/her to refactor. Next time just let him/her to do that, and review code.

A book I’d recommend: “A Philosophy of Software Design” by John Ousterhout